it looks like I got stuck and I need some help on solving this authentication/authorization problem.
I have an Okta installation, outside of my control, which supports OIDC but doesn't allow to easily manage roles and also does not support the token exchange flow.
I was hoping to use Keycloak as sort of sidecar/federated system to store users' roles, but I still need to perform the authentication against Okta, simply because that's the one storing the user credentials and I cannot have direct access to those.
Also, I cannot expose Keycloak to the end users, due to security constraints.
In other words, the client can only reach Okta and must authenticate on Okta, but since I can't store user roles on Okta I wish to use Keycloak for that and query Keycloak from my backend application to query for user roles, all of that without using the token exchange flow....
Any ideas how can I achieve that, if possible at all?
Thank you in advance.
Related
For our applications we have a setup where an application admin user can define its own roles and assign certain application privileges to those roles.
We are now looking for a centralized auth system and my eyes fell for Keycloak.
The overall concept is great where I can login my client application with OIDC towards Keycloak which it will relay it to a list of possible IDPs.
The problem however kicks in how to handle all the privileges. Overall there will be around 40 of those for each user which means that I can not out them in the JWT token itself due its size.
For the client application it actually would not even matter since it holds its own api and only needs to identify the user. However when that client application calls one of the microservices that service should know if the user holds the desired privileges to make the call or not.
Hope someone can guide me through this process.
Best,
Pim
Hi I'm using Keycloak and I would like to know what is the best way to get User Role. I'm using a SPA written in ReactJS and it needs to know the user's role. Is there a Keycloak API to get this? or should I get it from the JWT token. Either way, what is the option that I should go with. Thank you.
If you assigned role to a user, then this role is a claim inside JWT access token provided by Keycloak.
A user would have to be authenticated before seeing some application content.
After successful authentication, access token would be given to client (can be application gateway or ui application) and then role can be extracted from it and used.
Yes, rest API is there to get user roles
GET /auth/admin/realms/{realm}/users/{user-uuid}/role-mappings/clients/{client-uuid}
you can find all the rest api of keycloak here:
https://www.keycloak.org/docs-api/5.0/rest-api/index.html
I have a set of REST services on IBM cloud. Ingress is integrated with Appid for authentication. Ingress adds the token id & access id to the authorization header.
Now on the API side (springboot) do I need to validate the user again on every request ? will this be redundant ? If no, which appid api can be used to authorize the user. Any reference to similar example
Already gone through the example on IBM cloud site. One is about ingress & appid integration, but does not talk about REST services layer how to handle the authorization tokens there.
Another is only about spring and Appid, (does not talk about ingress)
Authentication versus Authorization is where the line is drawn. The Ingress integration with App ID does the authentication for you and your REST service (application) can be assured that the request if it comes through is authenticated. Now just because the user exists in your system and has provided the right credential does not mean that he is allowed to access the service he is trying to access or view the data he's trying to view which is where the authorization comes into play - the REST service can use the authorization tokens to figure out if the user has the right access to use the service.
Here's a good article that talks about the use of Roles - https://cloud.ibm.com/docs/services/appid?topic=appid-tutorial-roles
In any application - REST, UI or otherwise - multiple levels of security may be necessary depending on your requirements. Authentication verifies the user is who they claim to be, authorization checks what permissions the user might have. Each application might have its own rules for what the user can access.
In your case, you have authenticated the user facilitated via Ingress with AppID, which supplies a user principal (identity) to your application. However, should every user have access to all of your application endpoints? If the answer is no, then you will need an authorization model, for which a common approach is RBAC (role-based access control).
Even without an RBAC requirement, it is still wise the validate the user's principal in some form for each request. For example, perhaps the user belongs to a domain that you might not expect, or should no longer have access to this specific REST application. Your application server may have features that assist you with a simple authorization feature, or you can custom build your own validation.
At present, as the identity provider, AppID can be the store of the user's role for RBAC. However your application or application server must decide what to do with that role.
If you are looking for a Cloud-centric authorization solution, you may want to consider exploring Istio's authorization policies:
https://istio.io/docs/concepts/security/#authorization-policy
https://cloud.ibm.com/docs/containers?topic=containers-istio
I have a question regarding Keycloak and obtaining an Access Token.
Our setup is as follows:
· users are created and maintained in Keycloak
· resources, policies and permissions are also maintained in Keycloak
Our use case is:
As a third party application, I want to obtain authorization information (e.g. resource- and scope-based permissions) for a specific user by only providing the username to Keycloak, so I can allow or prohibit further actions.
To be more specific:
In our application the need to validate each request to other services based on the access token.But we have only the user name with us.
The question is now:
> How can we obtain an access token for the user by only knowing the username ?
>
Is there a solution to obtain an access token for such a user?
You don't specify in your question if the current user is logged in. Are you validating user specific actions, or you want to retrieve user roles for the application instead?
The user is logged in and he is performing some action
I suppose you're using some keycloak adapter. Then just retrieve the session object and you should have the extra info somewhere in there.
If not, you can just parse the request yourself. When using OpenId Connect, the access token is always sent for each of the requests, in the Authorization header. The token is base64 encoded, you can decode the token yourself.
The application is performing some action for some registered user, without him logged in
User access tokens are meant to provide permissions for users. As you say in your question: As a third party application, I want... so here you are not acting as a logged user, but as an application, so you need to go with client credentials instead. Just give the client permissions to list all the users and their roles (probably it's enough with the view-users role, see the link below) and log in with client credentials grant. Then you can handle fine grained permissions in your application business logic.
See also:
Keycloak Client Credentials Flow Clarification
Keycloak spring security client credential grant
How to get Keycloak users via REST without admin account
For those who really needs to impersonate a user from a client, there is a new RFC for this : token-echange.
Keycloak loosely implement it at the time of this answer
See particularly https://www.keycloak.org/docs/latest/securing_apps/#direct-naked-impersonation
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.