yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #89287
[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