Public bug reported:
Problem Description
=================
Currently, Keystone identity provider (IdP) attribute mapping schema only uses
the "domain" attribute mapping as a default configuration for the domain of
groups being mapped; groups can override the default attribute mapping domain
by setting their specific domain. However, there are other "elements" such as
user and project that can also have a domain to define their location in
OpenStack.
An operator when reading the attribute mapping section and seeing the
schema for the attribute mapping definition, can be led to think that
the domain defined in the mapping will also apply to users and projects.
However, that is not what happens.
Proposed Change
===============
First of all, to facilitate the development and extension concerning attribute
mappings for IdPs, we changed the way the attribute mapping schema is handled.
We introduce a new configuration `federation_attribute_mapping_schema_version`,
which defaults to "1.0". This attribute mapping schema version will then be
used to control the validation of attribute mapping, and also the rule
processors used to process the attributes that come from the IdP. So far, with
this PR, we introduce the attribute mapping schema "1.1", which enables
operators to also define a domain for the projects they want to assign users.
If no domain is defined either in the project or in the global domain
definition for the attribute mapping, we take the IdP domain as the default.
Moreover, we propose to extend Keystone identity provider (IdP)
attribute mapping schema to make Keystone honor the `domain`
configuration that we have on it. Currently, that configuration is only
used to define a default domain for groups (and then each group there,
could override it). It is interesting to expand this configuration (as
long as it is in the root of the attribute mapping) to be also applied
for users and projects.
** Affects: keystone
Importance: Undecided
Assignee: Rafael Weingartner (rafaelweingartner)
Status: In Progress
** Changed in: keystone
Assignee: (unassigned) => Rafael Weingartner (rafaelweingartner)
** Changed in: keystone
Status: New => In Progress
--
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/1887515
Title:
[RFE] Keystone to honor the "domain" attribute mapping rules
Status in OpenStack Identity (keystone):
In Progress
Bug description:
Problem Description
=================
Currently, Keystone identity provider (IdP) attribute mapping schema only
uses the "domain" attribute mapping as a default configuration for the domain
of groups being mapped; groups can override the default attribute mapping
domain by setting their specific domain. However, there are other "elements"
such as user and project that can also have a domain to define their location
in OpenStack.
An operator when reading the attribute mapping section and seeing the
schema for the attribute mapping definition, can be led to think that
the domain defined in the mapping will also apply to users and
projects. However, that is not what happens.
Proposed Change
===============
First of all, to facilitate the development and extension concerning
attribute mappings for IdPs, we changed the way the attribute mapping schema is
handled. We introduce a new configuration
`federation_attribute_mapping_schema_version`, which defaults to "1.0". This
attribute mapping schema version will then be used to control the validation of
attribute mapping, and also the rule processors used to process the attributes
that come from the IdP. So far, with this PR, we introduce the attribute
mapping schema "1.1", which enables operators to also define a domain for the
projects they want to assign users. If no domain is defined either in the
project or in the global domain definition for the attribute mapping, we take
the IdP domain as the default.
Moreover, we propose to extend Keystone identity provider (IdP)
attribute mapping schema to make Keystone honor the `domain`
configuration that we have on it. Currently, that configuration is
only used to define a default domain for groups (and then each group
there, could override it). It is interesting to expand this
configuration (as long as it is in the root of the attribute mapping)
to be also applied for users and projects.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1887515/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
