I want to use Keycloak for my application. Since our current data model expects a user name, password and the abbreviation of a company, I would like to know if there is a way to add an additional parameter to the login screen in Keycloak where the abbreviation of the company has to be specified. During the authentication process it should be checked whether the user belongs to this company and if so, the token which is created should contain the company's abbreviation.
So far I manged to modify the login theme like this:
Login screen
I know it is possible to add additional information to a token via client scopes and attribute mappers, but as far as I know, this is only possible for single users.
Also I'd like to know, which is the best way to administrate companies in keycloak.
Thanks in advance.
Related
I want to secure my user registration page with keycloak but couldn't think of any approaches while reading the docs. The best option for me:
New user register, but his account is unavailable.
When ADMIN accept this new account, user can log in.
Is it possible do it in keycloak ? Or any similar solution ?
Sure you can do it. The easiest way is to give a default role to newly registred users. The default role would give only minimal privileges. Then ADMIN can promote the user to the more appropriate group or role.
Probably to "automate" or smoothen the second part of this flow you might need some flow customization. Cf. https://www.keycloak.org/docs/latest/server_development/#required-action-walkthrough and related.
Another solution is to give to the default minimal role the possibility to request acceptation, or make the request automatically at first logging (eg. mail sent to ADMIN).
EDIT
Programmatically it is also possible to make calls to the Keycloak Admin API (through native Admin Client). For example, you can write some logic (and associated UI or whatever) that will assign or remove groups from a user.
See. Admin REST API
I'm using Keycloak for Identity Brokering through Google, Microsoft, etc. But Keycloak only allows one email per user. So the user can be authenticated only through one of the social login options (Google if gmail is added as user's email address, etc.). Is there any way to include more than one email per user, or any other workaround?
EDIT: (Editing based on comments to make scenario more clear)
In my scenario, I'm using a federated user store which contains a large number of users and and I need Keycloak to access all the emails linked to a user when that user is logging in using Google,Azure,etc. because Keycloak is using the email as the unique identifier for the authentication response from the social login provider. Without having the required email as the main email, Keycloak won't allow that user to log in through social IdP
Although, Keycloak emphasises on keeping a unique email,but there are certain scenarios where you may want to keep , say, secondary email.
This can be achieved in a couple of steps:
1. Add a custom attribute for secondary email in user like this:
2. Next , in your client create attribute mapper like this:
When I generated the token after above configuration, the new attribute was avialble in token. You can use this attribute in your app as you desire.
Parsed JWT:
I figured out the best way to deal with this is through the custom user provider (federated user store). Even though we can't add multiple emails per user through the Keycloak admin console, we can write the user provider in such a way that it can get all the emails linked to a user from our database and assign them to the email attribute of each user. Once this is done, all the emails will appear on the admin console as well.
For the social login to recognize those emails, we have to get all the emails linked to a user in the provider to an array and iterate through it until the authentication is complete. This would help to create the social login link to the user through First Login Broker authentication flow.
This is a crude way to approach this, but nevertheless it works!
We have an existing web application which works with its own users, stored in a local SQL server database and each user has specific rights to access specific content.
A new customer is interested in using this application, but their requirement was that it should have SAML 2.0 integrated.
Now, I'm new to SSO, but I assume they want this so all user management is done at their place and that their users can log on at any of their services, using the same credentials.
The user rights defined at our web application however, are application specific; they have no meaning outside our application. So I assume these fields should remain stored and managed at our end, instead of managed at the identity provider?
But what would be the best way initiate this? I could create an empty user record locally whenever the user logons for first time, but he would literally not be able to do anything without proper rights. I could give him default right settings, but there should be at least 1 administrator to distribute the rights of the remaining users. Is it common to ask additional fields at the identity provider to initiate users for a specific service?
This can be done using entitlements sent in a SAML2 attribute. e.g. if you have a normal user profile for your application, you can ask the IdP to release an attribute such as eduPersonEntitlement or urn:oid:1.3.6.1.4.1.5923.1.1.1.7 as it's known in SAML2. If the IdP owner agrees to release this attribute you can agree a controlled vocabulary with them for the value of the attribute.
So when a normal user logs in to your application using SAML2 and their attributes arrive in an AttributeStatement with a collection of SAML2 Attribute instances you can look for urn:oid:1.3.6.1.4.1.5923.1.1.1.7. If it has a value of, perhaps, https://yourapp.com/entitlement/user you can set them up with a normal user account. If they have a value of, perhaps, https://yourapp.com/entitlement/admin, you can set them up with admin rights.
Just be careful to compare what they already have (if anything) with their incoming SAML2 entitlement, in case they longer are an admin. The IdP decides who is a normal user and who is an admin but that's up to them to work that out. All you care about is the value of urn:oid:1.3.6.1.4.1.5923.1.1.1.7
The full set of eduPerson attributes is here
I have come across a number of articles that discuss a similar matter but I cannot find a definitive answer.
My company would like to begin using Identity Server 3, however one of the requirements is to be able to authenticate an external user without them having to manually enter their credentials.
This must be capable of providing single sign on capabilities also as we have 3 different systems and our users should only have to sign in once.
Essentially, the external user has their own CRM.
The CRM holds their username and password for our software.
They then click a button in their CRM to launch our application
This redirects them to our website with a payload containing their credentials
We call a web service to authenticate the user
It is fundamental that we do not change this process for our partners.
Can I implement a custom service provider to provide the authentication or is there some other way of achieving this? If so, could you point me in the right direction for how this can be done?
Many thanks
Craig
I would assume that you'd create a mechanism for their CRM to get a token at the time the client logs into their site and then have them send that token via url to your callback page. This would use the machine-to-machine type grant, or the client-credentials flow. Then that page could validate the token and log the user in. There would have to be some sort of unique identifier between the two systems like email or something. Just an idea.
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.