-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
keycloak auth initial implementation #371
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: greg pereira <[email protected]>
Signed-off-by: greg pereira <[email protected]>
908896e
to
6664a9d
Compare
Ive been suggested to reach out to @tonyjames to ask if there are any features in particular that you wanted with this keycloak integration. |
@Gregory-Pereira - While testing with Keycloak is useful due to the fact that I envision it being a common identity solution, I wonder if it might be possible to also support other OIDC solutions which would also include Keycloak rather than specifically targeting Keycloak? One other solution that comes to mind is Microsoft AD FS. Thoughts? |
The module we use for authentication is next auth. While im not sure about the providers that are backed against Keycloak, the module does support a plethora of other providers out of the box including Microsoft AD. They also enable support for custom providers if the built in ones dont suffice. In the background I am also trying to work with the RHEL-AI team to figure out how we can fit our authentication into their auth system. I have heard that on the RHEL-AI box they utilize Keycloak for user authentication, and I was hoping to see if we can hook into that for the UI rather than a separate Keycloak instance for UI auth which is included in the current state of this PR. Another potential implementation is that I know @sabre-1041 has worked on the group-sync-operator, which might fit well here. We could deploy the operator to map Azure AD groups to openshift groups, and leverage those openshift groups for authentication. Therefore it seems there are certainly options available to us, I would love to hear your thoughts on these. |
@Gregory-Pereira - I'm familiar with the group-sync-operator but it seems limited to syncing groups from LDAP backends. Not sure we can count on LDAP access being available as I've been seeing a lot of migrations to oauth providers. Looking at the available next-auth providers it appears that there is a generic oauth provider available which could be interesting for non-Keycloak use cases. As for groups, Keycloak can be configured to include a user's group information from the backend provider in the access token. That information can then be used by InstructLab UI to allow/disallow functionality based on a user's group membership. |
Great point, I forgot that was LDAP only ... I can definitely look into the generic Oauth provider. I can also try to extend this keycloak example to work with groups. |
Addresses: #354
Tested with demo here: https://drive.google.com/file/d/17dUK0EA3-eOp40B714vg6bYnvKze9kPj/view?usp=sharing.
The only thing that didn't get tested here is kind deployment / integration. Also this currently only allows for existing users, there is no way to request a keycloak user from the UI. That being said I think this is ready and we can always test
kind
and or expand the feature set in follow on PRs.cc @vishnoianil @nerdalert