Keystone2Keystone federation

[gtema]

Since federation is being reworked in this project there is also interest on implementing Keystone to Keystone federation.
Ideally we get rid of all intermediate software components (mellon, shibboleth, mod_auth_openid, etc) to slim down the stack.

[dmsimard]

Hi,

We'd rather not have to deal with mellon or shibboleth but they are options in the current docs:

• https://docs.openstack.org/keystone/latest/admin/federation/configure_federation.html#mellon
• https://docs.openstack.org/keystone/latest/admin/federation/configure_federation.html#setting-up-shibboleth

We use OIDC for some other things and it works ¯\(ツ)/¯

The CI jobs for k2k go with shibboleth:

• https://zuul.opendev.org/t/openstack/builds?job_name=keystone-dsvm-py3-functional-federation-ubuntu-jammy-k2k
• https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_265/openstack/2650a80f367340db91edaaf7b2edf4a3/controller/logs/shibboleth/index.html

Anyway, the idea is to have the ability for N different keystones to federate/trust each other.
We are particularly interested in federating the user and project ids in addition to the existing mapping properties to facilitate tracking, accounting and billing -- it's much easier if they're all the same everywhere.
Putting the user and project in domains (where they're from, basically), allows to avoid UUID collisions and scope particular restrictions/role/endpoint groups/policies based on their domains as well.
Without going into details, this can have considerations for reducing blast radius or single points of failure, security, performance, legal or geopolitical reasons, too.

Users would authenticate against a local keystone (because that's where their user/project/creds might be) and go to another "service provider" (in k2k federation terms) to obtain the catalog, endpoints and things.
We could argue that we are introducing a bit of latency by ping-ponging requests around for auth but figure that this needs to occur once, then we can use a cached token to avoid incurring the penalty more than once.

An example: there can be more than two but pretend we have keystone A and keystone B.
0) k2k federation is setup (both keystones trust each other, there's a mapping, etc.)

1. User authenticates against their local keystone (A) with OS_SERVICE_PROVIDER=B for the first time
2. <whatever saml oauth trust wizardry goes here>
3. B creates domain A if it doesn't exist
4. per the mapping, B creates the project, creates a user in it, both in domain A, probably assigns some roles
5. Returns the appropriate token with a catalog of endpoints returned by B (also, B becomes the identity endpoint)
6. something (maybe ceilometer) collects billing/acounting from around the world based on these user/project IDs
7. ???
8. profit

[gtema]

We need to get rid of everything saml related

There are certain similarities to the oidc and/or oauth2 token exchange. In your description there is however one thing that doesn't look like it is/can be implemented currently: the idp knows nothing of service provider side, so it can't push data or include any information about SP side.

When the user manually goes to the IDP side first we can grant it an oauth2 token that could be exchanged for SP regular token as oauth2 token exchange. Alternatively the user goes directly to SP Keystone and a regular oidc redirect happens to the IDP side and then it is just like normal oidc flow. In such case on the SP side we need to configure federation to IDP side(s)

Next thing is synchronization of the domain/project/user data. Users can be synced with SCIM. That requires the IDP side to know the existence of SP and push the data. SCIM does not have the concept of domains, so for every domain we need a dedicated connection, which maybe is even good since it allows you to only allow certain domains to "roam" and be precise to where. For projects we could implement the similar mechanism to push the data together with the user data. But how do you want to manage role assignments?

In general I would prefer us trying to build up a solution using the oidc concepts since saml is dead on governance and security fixes. Alternatively, if we find oidc to be too overwhelming for the case (too many connections to configure) we may decide to do it very differently. In any way the question: what if customers want to add their own external IDP over oidc or also LDAP? Do we want to enable this possibility?