Roles only set on first login

[JuanPTM]

If you change roles in federated IAM, they are not updated in openstack on the next login.

Observation: If you delete a federated user in openstack, change his roles in federated IAM and then re-login, keystone assigns the identical user-id to it again, but the user has all the roles are updated.

[reqa]

Maybe this behaves differently when roles are assigned indirectly via groups? That's what I recall from Kristi's 2020 talk.

I think we should document the current status regarding access lifecycle behavior first to be transparent and then in the next step try to address/fix/workaround them one by one. It would be even better if OpenStack has this documented, but AFAIK the information is spread out across conference talks (https://www.youtube.com/watch?v=GiLcKjuTyi0 and the 2020 talk https://www.youtube.com/watch?v=GBRhXBWFpRY) and probably github issues like this and #359. I see a series of somehow related topics here:

• Missing cleanup of roles (?), which would probably be contrary to expectations of federation and self service and kind of a deal-breaker.
• Group memberships only represented in Keystone tokens but not in Keystone database and thus not visible via openstack-cli
• Behavior of application credentials in combination with ephemeral federated users
• Lifetimes of granted access permissions (logon/logoff? user deleted+re-added?)

This could go to https://github.com/SovereignCloudStack/standards/tree/main/Drafts/IAM-federation (which used to be "Design-Docs") and if there are things that need to be publicly transparently documented (like warnings) it could go to https://github.com/SovereignCloudStack/docs/tree/main/operations/iam (and link from somewhere).

After that we can think about how to address them technically to improve user experience to an acceptable level.

[JuanPTM]

As It's explained on both videos linked by Arvid:

• It is necessary a provisioning tool to create groups and roles, and make the assignment between then on the openstack layer BEFORE the federation.
• All access should be granted using groups (with the right roles assigned). This is done this way because groups doesn't persist on the DB for ephemeral users, so no cleanup is necessary.
• Avoid assigning users to projects using mappings, as we don't want to assign users forever to a project. The intended way to assign users to projects is to assign Roles to groups that grants access to projects.
• There is a way to make ephemeral users group membership persist for a short time to allow the usage of app credentials. default_authorization_ttl=0 on Keystone.conf
• It is up to the administrator to keep the right roles assigned to groups. In case a permissions changes is needed.

This is a brief summary of what we discover on the videos.

[JuanPTM]

I had try to set up a federation following our ADR regarding naming. I had encounter some problems on the keystone side regarding domains and roles.

Basically I was using the following mapping rules to federate the users:

[
   {
        "local": [
            {
                "user": {
                    "name": "{0}",
                    "email": "{1}",
                    "domain": {
                        "name": "{4}"
                    }
                },
                "domain": {
                        "name": "{4}"
                    },
                "groups": "{3}",
                "projects": [
                    {
                        "name": "{2}",
                        "roles": [{"name":"d000001-member"}]
                    }
                ]

            }
        ],
        "remote": [
            {
                "type": "OIDC-preferred_username"
            },
            {
                "type": "OIDC-email"
            },
            {
                "type": "OIDC-openstack-default-project"
            },
            {
                "type": "OIDC-groups"
            },
            {
                "type": "OIDC-domain"
            }
        ]
    }
]

But then I get this error on the browser: {"error":{"code":403,"message":"role: d000001-member must be within the same domain as the identity provider: keycloak.","title":"Forbidden"}}

This is due to the role d000001-member only existing on the domain d000001. I'm not sure why the configuration of the identity provider on openstack ( OS_CLOUD=admin openstack identity provider show keycloak ) its bonded to the Keycloak domain. The role d000001-member only existing on the domain d000001 cause this error.

To try and find a temporary workaround I created the role d000001-member on the Keycloak domain. That generates another error.

The solution to that was to set the attribute domain on the IdP user to "keycloak".

This makes the login to work, but I got a error message regarding no permissions to see the project. (Probably due to roles policy /configuration) If I use the regular member role instead of d000001-member the login works and I can see the project.

Also, there is something that concerns me, the identity provider on openstack is bind to a domain in openstack, in our case Keycloak. I'll investigate this.

[garloff]

This needs to be documented well, because it's a surprise which can lead to a security trap. Create a documentation user story, so we can close this one.

[garloff]

To workaround the problem, we could create a set of standard groups whenever a project is created. GROUP-$PRJ-$ROLE and tell users to not assign users directly to roles. Could even tell keystone to disallow this. Or fix upstream to make role assignments being cleaned up for the federated case.

[garloff]

I don't find this limitation documented yet at https://docs.scs.community/docs/iam/

[JuanPTM]

New MR that describes the limitation in https://docs.scs.community/docs/iam/

[JuanPTM]

New MR that describes the limitation in https://docs.scs.community/docs/iam/

Merged.

[JuanPTM]

An upstream blueprint has been created to draw attention to the issue.

https://blueprints.launchpad.net/keystoneauth/+spec/roles-only-set-on-first-login