Multiple rules in a mapping is not working with type: "local" attribute

[Shivakumar M]

We have a requirement in which we want to setup an external Identity provider with keystone federation for SSO.
I have added two rules in a mapping which will match to below criteria and added this mapping to OS_FEDERATION identity provider.
Rule 1. If user already exists in keystone, it should not create a new ephemeral user.
Rule 2. If user is not found in keystone, it should create a new user in SSO federated domain.

Problem:
If user is not present already, it should match second rule and new user should be created. But its throwing Unauthorized Error.
I think, with type:"local" specified, it will throw Unauthorized error even if there are multiple rules for a given mapping.
With multiple rules specified, it should try to match the a rule in an order which is not working as expected

Have attached mapping object for reference.

[Colleen Murphy (krinkle)]

Unfortunately the "local" type within the "local" section is not a matching rule. Only the keys in the "remote" section are matched, then they are mapped to attributes in the "local" section. If the user doesn't exist already in keystone, but still matches the remote rule '"type": "HTTP_GROUPS","any_one_of": [ "consumers" ]', it will be mapped to the first case, and then expect there to already be a local user. The matching can only be done based on remote attributes, not on local attributes.

[Sonu (sonu-sudhakaran)]

Will this be valid proposal if we were to have have multiple Local mapping definitions that could match a remote rule?

Based on incoming remote attributes, if proper local mapping definition can be loaded dynamically (ephemeral type, or local), it would be easy to achieve what we want. And if there is a local mapping with typ:local, its given the higher priority.

for e.g.

  "mapping": {
    "id": "IDP1_mapping",
    "rules": [
            {
        "remote": [
          {
            "type": "HTTP_FIRSTNAME"
          },
          {
            "type": "HTTP_LASTNAME"
          },
          {
            "type": "HTTP_EMAIL"
          },
          {
            "type": "HTTP_GROUPS",
            "any_one_of": [
              "consumers"
            ]
          }
        ],
        "local": [
          {
            "user": {
              "name": "{2}",
              "email": "{2}",
              "type": "local",
              "domain": {
                "id": "default"
              }
            }
          },
          {
            "user": {
              "name": "{2}",
              "email": "{2}"
            },
            "group": {
              "domain": {
                "name": "Default"
              },
              "name": "consumers"
            }
          }
        ]
      },

Or else,

Would you know how we can achieve the following use case, which I think is a common case,

1) Day0 : Openstack setup is made up and running in production, And few local admin / member users are on-boarded.
... Openstack system gets consumed by local users
2) DayN : Organization decides to configure SSO.

Once SSO on-boarding is completed and is rolled out for Users to login using their directory accounts, what happens to the project assignments, deployments that User had.

Shouldn't we have option to map SSO users to existing local users? However, there may be few users who are logging in for the first time using SSO.

Looking forward to your suggestion.

[Colleen Murphy (krinkle)]

I don't think it will work to have two local rules for one remote rule.

One possibility is to use the any_one_of condition in the remote rules to match particular user names, since you know which users are already local:

https://docs.openstack.org/keystone/latest/admin/federation/mapping_combinations.html#mapping-conditions

Then you could have the first rule match on those usernames, and the second rule be a catch-all for the rest. Would that work for you?