← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1981365] [NEW] Do not allow updating ephemeral users attributes via API

 

Public bug reported:

Problem description
===================


Today an operator is allowed to update ephemeral (federated) users' attributes via REST API. This can generate misunderstandings for operator; this can happen because the ephemeral users' attributes are updated in every login process, which will download/use the user's attributes from the Identity Provider and update them in Keystone, based on the configured attribute mappings.

Therefore, if an operator updates an ephemeral user's attributes in
Keystone directly, and the user executes the federated login process,
all  data updated by the operator will be overwriten by the Identity
Provider user's attributes.


Proposal
========

To prevent operator's misunderstandings and guide them to update
ephemeral users correctly, we propose to add a validation in the "update
user" API.

The validation will check if the user is ephemeral and will deny the
update in these cases and guide the operator to update the user's
attributes directly in the Identity Provider instead of doing it in
Keystone.

The operator's must still be able to enable/disable these users in
Keystone; if the only updated attribute in the request is the "enabled"
attribute, then the user must be updated. This allows operators on the
service provider (SP) end to enable/disable federated users directly on
OpenStack.

** Affects: keystone
     Importance: Undecided
         Status: New


** Tags: rfe

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1981365

Title:
  Do not allow updating ephemeral users attributes via API

Status in OpenStack Identity (keystone):
  New

Bug description:
  Problem description
  ===================

  
  Today an operator is allowed to update ephemeral (federated) users' attributes via REST API. This can generate misunderstandings for operator; this can happen because the ephemeral users' attributes are updated in every login process, which will download/use the user's attributes from the Identity Provider and update them in Keystone, based on the configured attribute mappings.

  Therefore, if an operator updates an ephemeral user's attributes in
  Keystone directly, and the user executes the federated login process,
  all  data updated by the operator will be overwriten by the Identity
  Provider user's attributes.

  
  Proposal
  ========

  To prevent operator's misunderstandings and guide them to update
  ephemeral users correctly, we propose to add a validation in the
  "update user" API.

  The validation will check if the user is ephemeral and will deny the
  update in these cases and guide the operator to update the user's
  attributes directly in the Identity Provider instead of doing it in
  Keystone.

  The operator's must still be able to enable/disable these users in
  Keystone; if the only updated attribute in the request is the
  "enabled" attribute, then the user must be updated. This allows
  operators on the service provider (SP) end to enable/disable federated
  users directly on OpenStack.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1981365/+subscriptions