Feature/federation mapping enhancements #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
msherman64
force-pushed
the
feature/federation-mapping-enhancements
branch
2 times, most recently
from
daca3e1 to
6415228
Compare
msherman64
force-pushed
the
wip/chameleoncloud/xena
branch
from
b76e269 to
bede4b2
Compare
This adds support for direct-mapping auto-provisioned projects and roles, similarly to how the existing groups functionality works. Note: if mapping role names, the roles must already exist in the federated domain for the mapping to succeed, as roles are not automatically provisioned in the same way that projects are. Change-Id: I390a26ab3d87480cb82c603e3b8712a9c8132e1b Closes-Bug: #1878496 Conflicts: keystone/federation/utils.py keystone/tests/unit/contrib/federation/test_utils.py These conflicts are from an additional change to the groups parsing does not yet exist on the Train branch.
Deployments that use federation mappings containing a "projects" rule will automatically provision projects and role assignments for the federated user within the federated IdP domain. However, users would never lose these assignments, even if the federated IdP's representation of the user's groups/roles changed--auto-provisioned assignments are only additive. This commit adds a new ``remove_dangling_assignments`` configuration option, which defaults to ``False``. When set to ``True``, an incoming user's assignments will be checked against the assignments returned by the mapping rules. Any assignments that exist within the federated domain for the user which are NOT returned by the mapping rules will be removed. This does not affect any assignments on other domains. Change-Id: Iea14bd0b417ce0c12ef13fac785be6fdcf43acbb Closes-Bug: #1888029
Some federation assertion libraries, notably mod_auth_openidc, support passing the entire set of assertions as a JSON-encoded payload inside an environment variable. This adds support for parsing such an environment variable as JSON, if present. A new 'assertion_payload' configuration option in the 'federation' group can be set to the full name of the environment variable in which to search for such a JSON payload. Change-Id: I7ae0da35b4fe0f94d59484fc8c92377f9a346443
Before, only the entire value of the remote assertion value could be
filtered against. This adds support for a way to filter on sub-props of
an assertion, like this:
{
"type": "projects",
"blacklist": {
"name": ["not-allowed-name"]
}
}
Regex is supported:
{
"type": "projects",
"blacklist": {
"name": ["not-allowed.*"]
}
"regex": true
}
Change-Id: Ia64fa4a94d2bcafed5cfcd6ec65efcec6adea41c
During project auto-provisioning, support attaching custom properties via the "extra" capability supported by Projects. If a project already exists during federated login, we always sync the project metadata to the current value of the additional properties. For safety, it is not possible to update the "name" or the "domain_id" value. Change-Id: I2ba20de32b16d14a7050dd1e664269c43e4cf3c8
This makes a lot of interesting things possible, namely expressing
direct-maps as "{0[key]}", meaning "For each value of the 0th remote
value, get the item at key 'key'".
Change-Id: I15d7a871477af9594b68241804b91ee8e7490fd1
There's an issue where when something should be interpreted as a list of possible values (like projects), if the list has length = 1, then the first value of the mapping ONLY is added to the direct maps. See __getitem__ in DirectMaps. The output of expand_listlike is assumed to be a list in several places; just ensure that is the case by additionally wrapping the output of the ast.literal_eval. The issue is that the string "None" gets evaluated to a valid literal of `None`, and so it doesn't trigger the fallback behavior to nest inside a list. Change-Id: I6aafd075b7f85f7649ea4f63cc8c71882db5ecb2
This adds a new 'optional' directive, which can be used on any type of
remote mapping declaration. It defaults to false, reflecting past
behavior, where all remote values were required to be set. If set to
true, and there is no assertion value for the requested requirement, the
mapped value of the requirement will effectively be an empty list.
This is helpful when mapping assertions into "many"-valued local
entities, like groups or projects. For example, consider a local mapping
that maps a user and perhaps creates projects and adds memberships for
them.
{
"user": {
"name": "{0}"
}
},
{
"projects": [
{
"name": "{1}",
"roles": [
{
"name": "member"
}
]
}
]
}
And consider that the remote part of the mapping is defined as:
{
"type": "OIDC-preferred_username"
},
{
"type": "OIDC-groups",
"optional": true
}
A user in no groups will now pass the verification phase of the mapping,
and their shadow user will be created, but the list of groups will be
empty, and so no projects will be auto-provisioned, and they will
effectively be in no projects. Currently such a user gets a generic
authorization error in Keystone. Making such mappings optional supports
better messaging to the user about the state of their account.
Change-Id: I5fc1ebc406cc1a2887ab1725d35132e1f35046a0
Our modification to handle "extra" project properties during mapping caused the "extra" parameter to be added in all cases, even when empty, breaking existing unit-tests. This is a simple refactor to avoid adding the property when it is otherwise unused, preserving the upstream unit-tests, as well as a new unit-test to specifically exercise the "extra" feature.
msherman64
force-pushed
the
feature/federation-mapping-enhancements
branch
from
6415228 to
b67f9c0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.