[RFE] Keystone to honor the "domain" attribute mapping rules

Bug #1887515 reported by Rafael Weingartner
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Undecided
Rafael Weingartner

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.

Changed in keystone:
assignee: nobody → Rafael Weingartner (rafaelweingartner)
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

Reviewed: https://review.opendev.org/c/openstack/keystone/+/739966
Committed: https://opendev.org/openstack/keystone/commit/14ac08431f22705a242073ffe2c362b3aa5d9b71
Submitter: "Zuul (22348)"
Branch: master

commit 14ac08431f22705a242073ffe2c362b3aa5d9b71
Author: Rafael Weingärtner <email address hidden>
Date: Tue Dec 12 16:59:37 2023 -0300

    Keystone to honor the "domain" attribute mapping rules.

    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.

    Moreover, 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 "2.0", 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.

    Change-Id: Ia9583a254336fad7b302430a38b538c84338d13d
    Implements: https://bugs.launchpad.net/keystone/+bug/1887515
    Closes-Bug: #1887515

Changed in keystone:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to keystone (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/keystone/+/907121

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to keystone (master)

Reviewed: https://review.opendev.org/c/openstack/keystone/+/907121
Committed: https://opendev.org/openstack/keystone/commit/04fc88a56ccf0cbdbf3f48e2fae8052dd61a82d8
Submitter: "Zuul (22348)"
Branch: master

commit 04fc88a56ccf0cbdbf3f48e2fae8052dd61a82d8
Author: Juan Pedro Torres <email address hidden>
Date: Mon Jan 29 19:45:00 2024 +0100

    Allow assignment of domain specific role to federated users

    Ater the patch "Keystone to honor the "domain" attribute mapping rules."
    It's not possible to assign domain specific roles to federated users
    when the user domain is specify on the claim.

    This patch aims to fix this, allowing to map non domain specific roles
    and domain specific, if the domain is the specify on the claim.

    Depends-on: https://review.opendev.org/#/c/739966/
    related-Bug: #1887515
    Change-Id: Ie3d7585cb9143686a93e4a19843698274475eaf6
    Signed-off-by: Juan Pedro Torres Muñoz <email address hidden>

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/keystone 25.0.0.0rc1

This issue was fixed in the openstack/keystone 25.0.0.0rc1 release candidate.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.