I want to add additional info when I register a new JHipster User with Keycloak. I already created an ExtendedUser entity with an one-to-one Relationship to the default User. Now i want to "extend" the registration form provided by Keycloak (adress, city,etc.) and safe these values in the ExtendedUser. is this possible? I cant seem to find any info on this. Also the registration form itself isn't in the gateway (like the default), but on the "keycloak-side", so i dont know if i can access the added values. My first guess would be to add the additional fields to the registration form, and then add the values to the token claims, which i could use to create an ExtendedUser in the background.
I´m using the default Keycloak implementation provided by JHipster (docker).
If this is not possible are there any other ways this could work (maybe switching to the JWT security implementation)? I also tried using the UAA server, but this isn't working for me because of other reasons.
Related
I have used spring security in the past and understand that most of the features of keycloak can be achieved by using spring security ( ldap integration etc ).
Apart from easy social media login validation, are there any other unique features in key cloak which cannot be done using spring security?
With spring-security you would have to create Spring authentication server and explicitly configure/code certain things for integration with LDAP, OAuth2/OIDC providers.
Keycloak is already OAuth2/OIDC/SAMPL compliant IAM provider. It provides features like User Federation with options like LDAP, integration with other OIDC provider etc.
Keycloak provides SPI integration points where you can customize the request flow, use OTP, perform two factor authentication, add google CAPTCHA, or even your CAPTCHA. It provides role based authorization too if you need.
It also provides event handling integration points for events like Login, logout, refresh token, etc.
Keycloak Community will keep adding new features or keep supporting it w.r.t. changes in OAuth2, OIDC, SAML. You don't need to worry about updating your code time to time. Along with this, security updates will be there.
There are many more features.
Most importantly, why reinvent the wheel, if you get these many features and good support.
Keycloak allows you:
to use multiple user storage and get users from multiple LDAP/AD or Kerberos or use without any LDAP.
to login once (SSO) and forget about to login from another application with GUI;
to use one authorization server for multiple application by separation them by realms. One thing should be noted: keycloak could be installed on multiple nodes for better reliability; This also could helpful when application become big and once you decide to separate it on multiple.
to add user additional attributes and fields during get user info without coding (trivial example - set phone number) or specific roles (on realm or even client level) or groups and use all this on the top of an AD attributes;
to configure password rules like password expiration, e-mail validation and so on;
to set up 2-factor authorization with SMS or Email.
These things I think could be implemented using Spring Security, but it takes more time than Keycloak installation and configuration. Personally, I am using Keycloak in multiple commercial projects and could claim that Keycloak is good.
I have a single realm with 3 single-page applications and a shared backend. I want to restrict the access to one of the SPAs so that users without a specific role can't log in.
But once you create a user in the realm, he can log in to every SPA client. I can restrict the endpoints of the backend but I don't want to programmatically reject the user in the specific SPA but automatically on the login page.
I tried to use client roles which don't seem to have an effect in this case. The only solution I have found so far is to create separate realms which I think is conceptually the correct way but unfortunately brings up some practical issues, e.g. the administrators of one realm must be able to manage (CRUD) users of another realm which seems fairly unintuitive.
users without a specific role can't log in - it isn't good requirement. How system will known if user has a specific role without log in (authentication)? Keycloak provides Open ID Connect SSO protocol, which is designated for authentication. After successful OIDC authentication is token generated, which may contains also user role. So only then authorization can be applied. So let's change requirement to: users without a specific role can't access SPA, which better fits into OIDC concept.
The mature OIDC SPA libraries offer authorization guard (name can differs, it is some kind of post login function), where authorization can be implemented. Authorization requires to have a specific role in the token usually, otherwise user is redirected to the custom route, e.g./unauthorized. That's the page, where you can say a reason for denying access. Common use case is also customization of the app based on the user roles. For example users with admin role will see more items in the menu than standard users - that's also kind of authorization. Random example of SPA library with authorization guard (I'm not saying that's a best implementation) - https://github.com/damienbod/angular-auth-oidc-client/issues/441
Keep in mind that SPA is not "secure" - user may tamper code/data in the browser, so in theory user may skip any authorization in the browser. He may get access to SPA, so it's is important to have proper authorization also on the backend (API) side. Attacker may have an access to SPA, but it will be useless if API denies his requests.
BTW: You can find hackish advices on the internet how to add authorization to the Keycloak client with custom scripting (e.g. custom scripted mapper, which will test role presence). That is terrible architecture approach - it is solving authorization in the authentication process. It won't be clear why user can't log in - if it is because credentials are wrong or because something requires some role in the authentication process.
You should indeed not create multiple realms, since that is besides the point of SSO systems. Two approaches are possible in your - presumably - OAuth 2.0 based setup:
restrict access at the so-called Resource Server i.e your backend
use a per-SPA "scope" for each SPA that is sent in the authentication request
The first is architecturally sound but perhaps less preferred in some use cases as you seem to indicate. The second approach is something that OAuth 2.0 scopes were designed for. However, due to the nature of SPAs it is considered less secure since easier to spoof.
I was able to restrict users access to application using following approach:
I've created to clients in my default realm (master) i called my clients test_client1 and test_client2 both of them are OIDC clients with confidential access by secret
I've created a role for each of them, i.e. i have role test_client1_login_role for test_client1 and test_client2_login_role for test_client2.
I've created a two users - user1 and user2 and assign them to client 1 and client2 role. But to restrict access to client1 i have to delete default roles:
That did the trick, when i am logging with user2 i see test_client2 and not test_client1 as available application:
But i did n't delete roles from user1 and therefore i could see both clients when i am log in with user1:
Therefore you should use different clients for your applications, assign to each of a client specific role and remove from users default roles and add one releted to specific application.
I'm in the process of trying to set up a server for a personal project. I'm using ServiceStack.Core with a Neo4j graph database as my persistence layer.
I would like to set up user authentication using my graph database as the user auth repository. There is no existing implementation of IUserAuthRepository for Neo4j as far as I can tell, meaning that I will have to create my own. Unfortunately, I have found very little documentation on this interface and how to correctly implement it.
So, I have a few questions:
Does there exist any kind of tutorial or other documentation on how to correctly implement my own IUserAuthRepository?
The CreateUserAuth method is supposed to take a password. What if a user logged in using Facebook or some other service and does not have a password?
Would it make more sense to just use Redis for authentication (with RedisAuthRepository), using the userAuthId to look up users in my graph db? Are there any major pitfalls to doing something like this? If I do go this route, how do I hook into the registration process to ensure that I create a user in the graph DB whenever a new user is registered?
There aren't any docs on implementing IUserAuthRepository, it's an interface with a lot of reference implementations. Easiest way would be to follow the implementation that works similar to neo4j.
The IUserAuthRepository stores 2 tables, UserAuth master table and UserAuthDetails child table which is where all OAuth providers like Facebook maintain info received when authenticating with them. The password field is used for CredentialsAuthProvider.
You can handle different events during registration and authentication with the Session and Auth Events.
I am using spring security core plugin in my grails application. but now I have a custom requirement.
I need to re-authenticate the user for some secret screens each time before opening these, even user is signed in already.
On re-authentication auth screen, I also want to add a secret pin code after username and password.
What will be the best way to implement this or is there any plugin available with this functionality ?
As far as I know there isn't any plugin that would address this for you. However, Glen Smith posted a few years ago how to implement your own custom authentication for specific URIs using the Grails Spring Security core plugin.
What he outlines there is very similar to what you will need to do:
Create a custom authentication object to hold the request.
Create a custom authentication provider to authenticate the request.
Create a custom security filter to apply to your URIs.
You should also note Burt's comment on the mentioned post about how to register custom authentication filters. This eliminates some of the code Glen provided.
Your implementation will be slightly more complex since you will need an additional filter to catch an authentication failure and route the user to the special login page. This is where things get quite tricky, but with the information above you should be able to get started and ask questions as you hit roadblocks.
I am using Spring security core & Spring security UI in my project. I have a requirement in which i need to create 2 different type of users: Sellers and Buyers. When user goto home page he can select what type of account he wants to create either buyer or seller.
What i have to do it make it work with spring security UI plugin. Do i have to create different Registration pages for different type of users. But then how i can assign roles at the time of registration.
I checked various questions posted before posting this question and could not find the right answer. I am new to Grails and will appreciate if Grails experts can help me with this issue.
I hope I have understood your question, I was a bit confused about mixing login with registration in your question.
Once you have created your user create UserRole based on the selected role, either ROLE_BUYER or ROLE_SELLER. This can be done in UserController create method.
As for login you don't need to have two different logins, you can always create a filter, interceptor, or any aspect oriented technique to intercept the request and redirect user to the proper section of your site. This way you're authorization is loosely coupled. Imho, there is no need to use Spring Security UI for authorization specific goals. Spring Security Core does much better job wrt url mapping/annotations.