Hi all. Can you advise if there is any mechanism in the Keycloak that will limit SSO access to certain users or groups of users?
For example, I have client1 and client2,
Client1 should be accessible via SSO by all users, client2 should be accessible only by users with admin role.
This is not really something that is done in Keycloak itself for a single realm. The assumption is that the client will make an access decision based on the content of the token.
I’ve seen that discussed before here and on StackOverflow. The script authenticator can restrict access via the login flow, but once you have a token, it’s not going to do what you want it to do. Say you have a client for a backend service where your frontend calls that backend service using the Bearer header. Assuming you want to restrict access to that service for a different set of users than the frontend where the user initially authenticated, you will have to implement that authorization decision in the backend service.
So, yes, technically that recommendation can restrict access to the “front door”, but once you’re in, you will still have to authorize each user on a per client basis, as it doesn’t go through that flow.
@xgp, @mbonn Thank you very much for your suggestions
Of course, an authenticator is not sufficient to catch all use cases and it is always better to do the authorisation at the client side. But there exist clients with no client-side option to restrict access based on user properties. For such clients a user-blocking at authenticator-level could be a solution…
It also has the problem of introducing specific requirements around how your Authentication flows are built.
In the case of 2 clients that are frontend only, a user may be authenticated and “pass” the script authenticator for client1. Even though they shouldn’t “pass” it for client2, the normal browser flow which has the Cookie Authenticator in position 1 would allow them through and issue a token once it has been issued for client1.
I agree that this “could” be a solution, but there are a whole lot of gotchas, and I would not recommend doing it.
I know you have to change the browser flow to execute your custom authenticator always, especially after a successfull cookie auth. But this is possible with keycloak. And yes, you have to make sure your custom authenticator is executed also in a post broker login flow, (in case you have brokered authentications).
What do you recommend instead?
There was no alternate recommendation beyond doing it in the client. I wanted to make sure it’s documented here that the script authenticator method is fraught, so that if others accept the suggestion, they need to understand exactly what risks and responsibilities they are taking on.
(I gave the suggestion using a custom authenticator because we (German University) have lots of clients where we have no other option than blocking the auth flow, and it works good…)
It’s certainly provoking me to think about that use case. I’ve also encountered clients/applications that I have no control over, and I wonder what the best solution is (and if Keycloak is actually the place to do it). What about putting a proxy in front of the applications you don’t control? There are examples out there of oauth2/oidc proxies that allow you do do this kind of user filtering, and also pass the token on to the application that it is protecting. Just a thought.
We are using proxies, too. Whenever the client service can work with an auth proxy, the proxy’s filter options are flexible enough and when the operating person of the client service is willing to operate an additional proxy…then we use a proxy…
For client2, you need an authentication flow with an execution of type “Condition - User Role” and “admin” as the role. This can be the last authentication step.
Use this authentication flow as browser flow override for client2.
How can I configure Condition - User Role with login with Identity Provider(IdP) per client level?
When user logins with Keycloak users, deny access works. When users login with an IdP, deny access doesn’t work and user login successfully although not having this role.
We do not want to block users in IdP flow (Post Login Flow). Only some clients will deny access to Users ( no matter if they are Keycloak users or IdP users) based on User role.
You can override the default flows for a client. Take a look at the bottom of the client configuration page.
That allows you to have flow variations per client.
I know it. The problem is that client authorization flow is not working with Identity Provider login. After Identity provider login, client flow is not continuing.
I too am experiencing this.
I have overridden the authorisation flow for my SAML client. The client redirects to an IDP. Users authenticate successfully with IDP but the “Conditional Access - User Roles” and “Deny Access” are being ignored.
Which means authentication is successful even if the role defined in the conditional access is not present.