We want to integrate Keycloak 18 in our platform to replace a self-implemented solution in the future. The first step was to implement an own user provider to keep our existing tables where users, roles and permissions are stored. This was pretty easy. So the old and new way can co-exist for a step-by-step replacement.
Now we also want to provide integrations for other user providers, like LDAP, Kerberos etc.
Is there a way to load the roles from our external db table after a user was authenticated by a random user provider?
e.g.:
User sends auth request to keycloak
User has been successfully authenticated by the ldap user provider
lookup external db to get the roles for the username and add them to the user model
thank you for your help
Related
I have a working KeyCloak installation, and a Laravel backend that uses this to authenticate Users.
The KeyCloack server is already configured with some external ("social") identity providers.
Now I want to create, from PHP backend, new "social" Users on KeyCloak via REST API before they attempt to login the first time.
My goal is to create new Users on backend database with their all profile data, in order to have all the user set-up already done once the user will first login on my app.
Is there a way to do this?
Have I to create the user firsty on KeyCloak and then link it to a social provider in some way?
Or something other?
Thanks
There are essentially two steps required:
You have to create a login-flow, that maps the SAML-User to the local user.
This must contain the "Detect Existing Broker User" and the "Automatically Set Existing User" Execution as Required.
Your Identity Providermust use this as login flow.
Then you have to configure your SAML Identity-Provider to identify the SANL-Atrribute to match the user. Feal free to ask if you need further help for this.
We're using Keycloak 12 for authentication in our portal and there are two different types of users:
Internal users (read from our internal LDAP)
External users (stored in Keycloak but without being synced with the LDAP)
We'd now like to use the "Forget Password" feature provided by Keycloak. After having configured the feature and the mail server, this works fine out-of-the-box.
However we'd like to restrict the "Forget Password" feature to all users which belong to (2), i.e. the internal users. These users are not allowed updating their password via Keycloak as this is done by another mechanism.
I couldn't find any information in the documentation so far if this is possible at all?
The Keycloak Forgot Password feature is applied at the Realm level, hence applied to all the users belonging to the Realm. For Keycloak, the LDAP is just an external storage with users to authenticate against. Consequently, out of the box, there is no way (as far as I know) for the Forgot Password to only be enabled to certain users within the Realm.
Even if it would be possible IMO it would not be a very user-friendly feature, since when one activates such a feature a new link will be shown to the users on the login page in case they have forgotten their passwords. So if a user from the LDAP would click on it, it would display an error or something?!
Alternatively, you can configure the LDAP of the so-called internal users in another Realm than the one with the Forgot Password enabled. And then configure the newly created realm to be an external Identity Provider, which the users could explicitly authenticate against it. So in practice, the users would lend in the normal login page, the external users could login normally, and would have the Forgot Password option enabled. The internal users would explicitly click on the external IDP to authenticate themselves. Log in using the external IDP would be a similar user-experience as log in to the normal login page, however, the Forgot Password option would not be shown.
You can see an example such configuration here.
I am building a SPA with a spring on the backend. I am working on signing in with Google, most of it is working already: got the id_token with the implicit flow in the frontend and I sent it and verified it on the backend.
I want to have users with roles and manage that locally (so, no adding info in the oidc provider). What are the options to go from the id_token to having an authenticated user in spring? I did not find any example doing that link manually (id_token-spring_sec_user).
I have checked several sources like the Spring Security 5 presentation at SpringOne https://www.youtube.com/watch?v=WhrOCurxFWU, several SO questions and posts on okta's and auth0's blogs but I am still missing the link.
You will have to create your own (application) specific roles.
Use these steps :
Get authenticated from Google
Access the profile section from google (username, name etc )
Use your own user table to store this info
Create admin APIs in your own system and assign your app-specific roles to the user.
When you login again you will authenticate against google login/password and roles specific to your application .
Create an account or session with the id_token
Check if the user is already in your user database. If so, establish an authenticated session for the user. If the user isn't yet in your user database, create a new user record with default role from the information in the ID token payload, and establish a session for the user. You can prompt the user for any additional profile information you require when you detect a newly created user in your app.
I have a Catalyst application that I recently created. I based the original authentication model on the example given in the Catalyst example using "SimpleDB". I am also using the Authorization::Roles module to permission users in specific application roles.
Now I need to move to LDAP authentication. I need to use LDAP to authenticate the user, but the user should still have a row in the User table to validate that the user is allowed to use the application. Also, the application should still lookup the User Roles from the Role table to determine what roles the user is allowed.
My question is: I have read that dropping in the Catalyst LDAP authentication module is pretty much Plug-N-Play, but will the application still use the User/Role tables that are already defined in the application?
We are a service provider. Suppose in our application, we originally have our own user/role management. Different users with different roles are allowed to use different features. So that when a user login we need to know which roles this user has, and prepare appropriate UI. We have administrator role, users with this role can assign roles to other users.
We are thinking of enabling SAML SSO for our application, now the problem is how do we setup roles for each user.
Solution 1, we relies on IdP to provide role information for each login user, the role information may come along with Assertion, but this may not work for all the IdPs.
Solution 2, we only retrieve user from the IdP, and manage the roles in our own application. For example, when we get an Assertion, we retrieve the username(or email address), and match with a record in our DB, if it doesn't exist we automatically create one for this new user. Then we rely on users with administrator role to assign correct role for this new user.
Now the questions is where is the first administrator coming from? Our customer gets our application, and turns on SAML SSO, now there is no users in the DB yet, then how can we resolve such bootstrapping issue? Is there any kinds of standard way? We have come up with different options but not sure which is better and what are the concerns for each options.
Option 1, have a default built-in administrator user. There is a regular native login page that built-in users can login without going through IdP(there is an option to turn it on/off if SAML SSO is enabled)
Option 2, during SAML SSO setup, ask for the administrator user name, so that we automatically create this user in our DB with administrator role. Then when this user login through IdP we could match him in our DB.
What are the other options?
For your first question about who should handle the roles. As I understand every customer has your One of your service provider software. And it connects to a central IDP that you own. If this is the case, it feels like its to complex letting the administrators handle roles on your IDP. I would go for number two.
About question number two. I have been in the same situation I can not remember that I have seen a obvious standard solution for this.
What we did was option 2. It works fine but it adds some complexity to the install procedure. We choose it because we would not have a native login page.
I thing maybe I would be better to go with option 1.
You can get the roles from the different directories of your IDP using your authorization layer. It removes the constraints on SAML and gives the same results as your solution 1.