Comment 3 for bug 1823847

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.