Integrate GitLab with IDAM

[corang]

IDAM manages user credentialing, authentication, and access policies for GitLab

This is dependent on the IDAM package being done and ready for use.

[corang]

We need to have IDAM refactored to follow the pattern of a capability @rjferguson21 This will allow us to follow a consistent pattern and use the "interface" for the database keycloak requires

[zachariahmiller]

@corang @anthonywendt @Michael-Kruggel Has this work actually been started or did this get put in progress and then halted because of the dependency? Asking as Rob reached out to me on this and wanted to get an understanding where we are at from SWF perspective.

[anthonywendt]

@zachariahmiller We did start it. We have a branch in which we are importing the IDAM package components and can get it to deploy and attempt to create accounts. We are not quite sure where we need to go with this though as it relates to SWF.

• Is this how we should be trying to bring IDAM into SWF? I don't really know, but its what we have so far.
• Is there a different path for IDAM integration? Context we may be missing?
• How do we intend on supporting use cases where Keycloak is provided externally and they only want to connect to that instance. i.e. a platform using our software factory wants to use the platform one keycloak.

[jacobbmay]

Are we planning this only around the free tier of GitLab? I ask because you can configure OIDC or SAML for authentication and new user creation, but neither of those auth methods provide a way to control user groups and permissions unless you have an enterprise GitLab license. And even with a license, only SAML provides a way to map user roles/groups from the IdP to GitLab group membership and permissions.

It looks like they have started to add some group features for the OIDC auth method as of version 15.10, but the features they have added are also locked behind a premium license and they are more limited than the SAML auth method.

Free version can federate to an LDAP provider to enable assigning user permissions based on LDAP roles/groups, but that doesn't help us since we are integrating with Keycloak.

[Michael-Kruggel]

Done