Support config for different identity managers

[michaelsauter]

trafficstars

Is your feature request related to a problem? At the moment, the ConfigMap application.properties hardcodes Crowd as identity manager: provision.auth.provider=crowd. If users want to use Azure as provider, they need to change the ConfigMap manually, which stops the resource from being comparable with Tailor.

Describe the solution you'd like The identity manager should be configurable in ods-core.env, and the resources should be comparable with Tailor. To achieve this, we add a new param to ods-core.env, e.g. named PROV_APP_AUTH_PROVIDER, which defaults to crowd. Further, we add two new config maps, idmanager-azure.properties and idmanager-crowd.properties, which both define some properties (with values being params filled from ods-core.env). When we apply changes via make, the value of the PROV_APP_AUTH_PROVIDER param is read. Depending on its value, we pass a different --exclude param to Tailor. E.g. if the auth provider is azure, then we exclude idmanager-crowd.properties (which means it won't be created or updated).

Describe alternatives you've considered Marking the additional config maps as preserve, but this has the downside that they are not compared.

Additional context ods-core.env will contain params for both auth providers. Users will only need to fill out params for one provider, and can leave the params belonging to the other provider with the default values. This is not ideal, but acceptable I think.

FYI @clemensutschig @stitakis @renedupont

[michaelsauter]

Related to this, https://www.opendevstack.org/ods-documentation/opendevstack/3.x/provisioning-app/configuration.html#_authentication_configuration also talks about Keycloak, and we need to take this into account. I'm asking myself:

• Is Keycloak working right now with the prov app?
• Couldn't Keycloak be used to connect to Azure?

@stefanlack @gerardcl @oalyman @stitakis Maybe you have more insight on this?!

[gerardcl]

Hi, I want to add some information about current state of the art regarding the Keycloak project.

Keycloak provides Identity Brokering: "Through Identity Brokering it's easy to allow users to authenticate to Keycloak using external Identity Providers or Social Networks. We have built-in support for OpenID Connect and SAML 2.0 as well as a number of social networks such as Google, GitHub, Facebook and Twitter."

Within Keycloak 11 one can setup the following providers:

Which basically means that we could just provide Keycloak support in order to brokering with other IdPs such AzureAD... The nice thing of using Keycloak is that within OpenShift 3.11 one can provide an OpenShift template to deploy a HA Keycloak and for OpenShift 4 there is the Operator option.

[gerardcl]

If you want to test Keycloak I have a fully working HA Keycloak OpenShift template I just created for another project :)

[stitakis]

@michaelsauter

to answer your questions...

Is Keycloak working right now with the prov app?

• I'm not aware of any reported bug related to this... but since we don't have an integration test nor a live installation of prov-app that uses Keycloak, I can't say if it is working right. ProvApp supports OAuth OICD and current OAuth OIDC Azure AD configuration works fine so far.

• Couldn't Keycloak be used to connect to Azure? Probably yes if Keycloak is used as IDP brocker (same scenario as Crowd-AzureAD)

btw... the release 3.1.0 needs to be ready in the next 2 weeks... should we move this item to ODS 4.x instead?

[michaelsauter]

I would be OK with this. However keep in mind that the verification tests will show a diff for the installation. Please check with @segator @borja44 if this is OK for 3.1.

[stitakis]

@michaelsauter I'm not sure what this means "verification tests will show a diff for the installation", I'm not aware of verification test, are this kind of integration test? can you please shed some light on this?

[michaelsauter]

@stitakis Yes, please see https://github.com/opendevstack/ods-core/tree/master/tests.

[stitakis]

@michaelsauter oh, thanks... I know what you mean now... are any plans to port these "verification tests" to 3.x?

[michaelsauter]

They are already part of 3.x.

[stitakis]

@michaelsauter excellent! Regarding the idea above, I propose to move to ODS 4.x and we take a look again once we are done with the release of ODS 3.1.0, sounds good?

[michaelsauter]

@stitakis Please check with @borja44 and @segator.

[stitakis]

@michaelsauter I'm not sure what should I discuss with @borja44 and @segator, can you please give me a call?

[michaelsauter]

Actually - for the cluster in question we're not using Azure, so there will be no diff. Sorry. So yes we just move to 4.0 then.

[segator]

If I understood correctly what we expect as PR in this issue is to allow identity manager provider parameters in ods-core.env and tailor can render prov-app application.properties configmap based on this values, right?

Right now we use crowd, but if we can switch to azure i don't see any inconvenient, in the worst case we will need to move some SA crowd local to azure, as simple we can keep the system ,better :)