search

SovereignCloudStack / issues

This repository is used for issues that are cross-repository or not bound to a specific repository.
https://github.com/orgs/SovereignCloudStack/projects/6
2 stars 1 forks source link

Spike: Re-configuring keystone OIDC federation for additional customer realms #314

Closed reqa closed 11 months ago

reqa commented 1 year ago

We need to find out if we can re-configure keystone without downtime to serve additional per customer endpoints for federation.

The endpoints look like this for OIDC (containing <CUSTOMERREALM> in OIDCDiscoverURL):

<LocationMatch /v3/auth/OS-FEDERATION/identity_providers/<IDPNAME>/protocols/openid/websso>
  OIDCDiscoverURL https://api.testbed.osism.xyz:5000/redirect_uri?iss=https%3A//keycloak.testbed.osism.xyz/auth/realms/<CUSTOMERREALM>
  Require valid-user
  AuthType openid-connect
</LocationMatch>

and like this for plain OAuth 2.0 (containing <CUSTOMERREALM> in OAuth2TokenVerify):

<LocationMatch /v3/OS-FEDERATION/identity_providers/<IDPNAME>/protocols/openid/auth>
  Require valid-user
  AuthType oauth2
  OIDCUnAuthAction pass
  OAuth2TokenVerify jwks_uri https://keycloak.testbed.osism.xyz/auth/realms/<CUSTOMERREALM>/protocol/openid-connect/certs jwks_uri.ssl_verify=false
  OAuth2TargetPass prefix=OIDC-
</LocationMatch>

We currently have only a single global

OIDCProviderMetadataURL https://keycloak.testbed.osism.xyz/auth/realms/<CUSTOMERREALM>/.well-known/openid-configuration

for the whole keystone. Maybe we need:

Context

The larger user story here is: As a SCS operator, I want be able to onboard an additional SCS customer so that OIDC can be used to federate from Keystone to the SCS internal IdP. From there it shall be possible to use IdP federation to consume identities from an external, customer managed IAM.

Our current picture is that each new SCS customer will have a specific "realm" (or "organisation") in the SCS internal IdP.

There are two levels here:

  1. The pure technical question, if the apache2 in the keystone container can be made to reload the wsgi-keystone.conf in case new endpoints need to be added.
  2. The broader question how we would make user experience for Login at Horizon work for an SCS operator. E.g. the user should not need to see a dropdown with the realms of all other customers of the SCS operator.

For the scope of this issue we should focus on the first point, to find out our current technical constraints and how to handle them.

Definition of Ready:

Definition of Done:

reqa commented 1 year ago

The keystone container runs apache with option -DFOREGROUND and apparently that breaks apache reloads (via apache2ctl or SIGUSR1).

I tested with

docker exec -it keystone apache2ctl graceful; sleep 12; docker exec -it keystone ls

and it seems more like 12 seconds than 2 in the gx-scs testbed at PS.

garloff commented 1 year ago

Trying to workaround by having files that we hoped would be re-read does not work. (Files are only reread on restart/reload.)

reqa commented 1 year ago

Update: According to discussion in the friday hacksession we are now experimenting with the Home IdP Discovery extension for Keycloak which would shift the realm selection towards Keycloak and it would be based on email addresses (1:1 relation between realm and domain name).

JuanPTM commented 1 year ago

Update: According to discussion in the friday hacksession we are now experimenting with the Home IdP Discovery extension for Keycloak which would shift the realm selection towards Keycloak and it would be based on email addresses (1:1 relation between realm and domain name).

Relationship is 1:N bewtween realms and domains name. Not sure about how big is the N

JuanPTM commented 1 year ago

Once the IdP discovery extension is configure and federation is working the next problem in line is mapping the federated users into Keystone.

This is done by using a rules files in Keystone. At the moment, we can create ephemereal users but groups and roles mapping are still not working properly.

garloff commented 1 year ago

Proxy realm has email domain to map to real realm. Next step is to test this in testbed. Then cfg-generics.

Open: (keystone-extension)[https://github.com/sventorben/keycloak-home-idp-discovery] needed ... understand maintenance plan (AI @reqa).

reqa commented 1 year ago

FYI: The author of keycloak-home-idp-discovery responded today with a positive reaction. The email was in german but I think it's fair to translate and sumarize as: He likes that we use the project and he wants to maintain in in a best effort way trying to be backward-compatible with Keycloak releases but promising nothing as Keycloak sometimes doesn't allow that. The author will not maintain older releases of the extension or backport features. I think that's a reasonable take.

reqa commented 1 year ago

Information from @knikolla regarding the question where the shadow accounts are created (if mapping type is ephemeral) or expected to exist, pre-created by external tooling (if mapping type is local):

The proxy approach however, will be putting all users in the same domain, which may not work for your use case.

There are two specs that were proposed a while ago to allow specifying the domain for the user in the mapping https://review.opendev.org/c/openstack/keystone-specs/+/748042, and allowing for project definitions as JSON https://review.opendev.org/c/openstack/keystone-specs/+/748748. It looks like these 2 specs would go a long way towards helping your use case UX. However, these specifications were implemented by introducing schema versioning for mappings and as I don't think that's the direction the keystone team wants to go, I'll try to reestablish a channel of communication with the proposer to remove that requirement.

From https://docs.opendev.org/opendev/infra-manual/latest/developers.html#rebasing-a-commit I learned that I could checkout that feature branch locally by running:

reqa:~/repos/openstack/keystone# git review -d 739966

which then left me in a local branch called review/rafael_weingartner/bug/1887515.

JuanPTM commented 1 year ago

I've work on configuring the plugging using the CLI. I still not figure it out how to ship the jar. Or we haven't agree on how to ship it.

For the moment this is how to configure it using the CLI kcadm.sh.

## Creating the flow

./bin/kcadm.sh create authentication/flows/ -r osism -f auth-flow.json -x

./bin/kcadm.sh create authentication/flows/IdP-discovery-flow/executions/execution -r osism -s provider=auth-cookie -x
./bin/kcadm.sh create authentication/flows/IdP-discovery-flow/executions/execution -r osism -s provider=home-idp-discovery -x

./bin/kcadm.sh create authentication/flows/IdP-discovery-flow/executions/flow -r osism -f subflow.json -x  (subflow)

./bin/kcadm.sh create authentication/flows/my-subflow-alias/executions/execution -r osism -s provider=auth-username-password-form -x  (subflow execution)

## Set everything to REQUIRED or ALTERNATIVE

./bin/kcadm.sh update authentication/flows/IdP-discovery-flow/executions -r osism -f flow-enabled.json -x

./bin/kcadm.sh update authentication/flows/IdP-discovery-flow/executions -r osism -f cookie-enabled.json -x

./bin/kcadm.sh update authentication/flows/IdP-discovery-flow/executions -r osism -f home-idp-enabled.json -x

This commands create the authentication flow to use the plugging. The only problem are that the JSON must have the id of the correspondent resource to work. Which is generated and shown after the creation of the resource.

So, maybe this should be scripting on a bash script or something.

JuanPTM commented 1 year ago

Created MR adding the installation of the IdP discovery jar in the playbook.

https://github.com/osism/testbed/pull/1775

JuanPTM commented 11 months ago

Created MR adding the installation of the IdP discovery jar in the playbook.

osism/testbed#1775

The objective has shifted to prepare a SCS/container-images repository to be able to build nice overlay container images.

garloff commented 11 months ago

Done, followup work to create the overlay image.