Repository navigation
Replies: 2 comments 1 reply
|
I could not quite understand your use case. In the first paragraph you mention that the client (application, I assume, not organization) uses LDAP, and you would add the Keycloak integration using OIDC / SAML to allow users to authenticate through an SSO. However, later you mention two federations, which would at least imply two user databases (or LDAP connections) that Keycloak itself is connected to, without anything to do with the client applications themselves. Please clarify how you would use Keycloak in your case. For the application integrations, you need to check how the application matches its users. In GitLab's case, you must define the As far as GitLab is concerned, the Keycloak connection, like other OIDC federations (e.g. Google, Microsoft, etc.), is basically considered a third party login - you can also see this on GitLab site's sign-in page. Because of how SSO services work, the Keycloak integration is displayed as a separate button, and the regular username / password should be disabled for most users. This approach is common across most services, since the user authentication is performed on a different domain, and the process uses browser redirects to go back and forth between the SSO and the client application, instead of handing the user credentials to the service itself. |
|
Thanks for your comment @darius-m . About last two paragraphs: The OIDC for gitlab appears to have the same parameters like the Nextcloud Social Login. So basically we already tried all those steps for Nextcloud. I did not try your mentioned gitlab OIDC integration. Do you know if defining ''the And as I said, we're still considering whether keycloak really is the solution to our problems. |
|
I think I understand your scenario better. It does make sense that you may have multiple user databases in your organization, but as far as I can tell, you are indeed correct that Keycloak will only consider the first possible match when multiple user federation sources are defined. This makes sense from a performance standpoint, since querying multiple databases requires a number of additional operations, and also from a security standpoint, as having multiple passwords could increase the attack surface. That being said, Keycloak is modular, so I believe that you can use an SPI that would allow you to query all federation sources for a match. For group memberships, it depends how you expect manage and need them. Since they are basically values in a LDAP/AD database, you can add mappers for the user federation to extract the group information and add it in Keycloak as user attributes, and then export the values to the clients. I have not configured Keycloak as a authorization endpoint, although I think it is also capable for it, so I cannot say if there is a better approach. For the GitLab integration, I could not find a clear explanation of the |
Uh oh!
There was an error while loading. Please reload this page.
We have been wondering what kind of use case keycloak should have if an existing client (like nextcloud or gitlab) already has hundreds or thousands of users set up with an existing ldap connection for login instead of keycloak.
Using keycloak for login does not link existing accounts with keycloak accounts, even though they might have the same ldap connection and the same usernames.
Furthermore the login password is dependent of the user federation priority. E.g.: if two user federations have the same login username, but different passwords, keycloak will only check the first user federation with the given login name and check its password. The second user federation with potentially matching login credentials will not be checked. So the user does not even have the advantage of just using any possible credentials which are present in the realm.
Last but not least, keycloak does not import groups of user federations. They all have to be added manually again, even though they are defined on an Active Directory or IPA.
Maybe I missed some information or I am wrong, but I could not figure out how to use it effectively in our scenario.
Using keycloak with several user federations is only reasonably if we would setup a new client with a blank database, isn't it?
Migrating the files/permissions/groups from existing users to new keycloak users is not easy or safe to do.
Can someone share some ideas or experience with keycloak for this case?
All reactions