Hi I'm pretty new with Keycloak and I don't understand some basic things about authorization. I have a REST API that exposes some resources and I want the users to have different roles depending on that resources. For example: I have users, cars and two roles (roleA, roleB). I want to assign roleA to userA for carA. Can I do this in Keycloak? How?
Thanks!
Yes, That can be done. This can be easily done via the admin console of KEYCLOAK.
Create a realm
Create a client in the realm for your application
Create roles (either realm roles or client roles)
Create resources
Create role based policies by selecting the relevant role
Create permissions by associating the created resources and the created policies
The question is a bit vague, but yes, you can do this in Keycloak.
Out of the box, Keycloak supports users and roles. It provides apis and UIs to manage these. If your app is configured to use Keycloak as a source of identity, you can access Keycloak user and role information in your app.
I'm not totally clear on how your "car" concept relates to users and roles, or where you want to manage it. But you have a couple of options:
Turn your app into an OAuth resource server and have Keycloak provide identity information via tokens. Do your cars business logic in your app. You'll want to read up on how OAuth works if you're not familiar with it.
It is possible to extend Keycloak to add custom domain objects, such as Car. More on how to do that here.
Related
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.
I've become very frustrated with the landscape of API creation and authentication/authorization. I would like to find a solution that doesn't require lots of additional complexity (creating new services myself, standing up and maintaining an instance of Keycloak, and so forth) – ideally a managed service (like Auth0 ... but Auth0 doesn't meet my requirements) – that centralizes the management of users and permissions, and allows me to add attributes to users.
Some context:
Suppose you have an API that has a variety of routes:
GET /customers
GET/POST/DELETE /customers/{id}
GET /customers/{id}/orders
GET/POST/DELETE /customers/{id}/orders
You can imagine that you have a case where you have users that have read-only access, and others that can read, create and delete customers and orders. You can also imagine that you may have the need to programmatically access the API, via a service account or access token (such as with Github PATs).
This could be set up with FastAPI or some other framework, such that when a route is accessed it checks that the user, or the access token – or in essence the credentials being used to access the API – has the necessary permissions.
What would be ideal, then, is to have a system that allows me to create users, and from that system the users can – provided they have the permissions in the identity management system to do so – create machine credentials (again, like with Github PATs, but perhaps something that can generate a JWT for consistency of credentials). Users can be added to groups that provide them with roles, and therefore permissions, or they can be assigned roles directly. Ultimately, it's a system that:
Allows user creation and management
Allows users to be grouped, groups can have roles that cascade to users
Allows users to be assigned to roles directly
Allow users to create credentials for programmatic access
Does not make management of users, roles, and so forth, onerous
Allows services (such as a REST API) using these identities for authentication to get the permissions and other information associated with credentials. In the case of other information, this could be included as claims in a JWT – this would require a system that allows claims to be added programmatically to the ID token/JWT.
In my experience, the closest thing to this is Keycloak. Unfortunately, it is a decent amount of work to maintain a Keycloak instance. Still, Keycloak does not provide number 4 in the list above. Does anyone else have experience addressing this issue? I would like to avoid have to manage users and permissions myself, because I have limited resources and that isn't my area of expertise.
Similar solutions:
Keycloak – hits most of the points, except for allowing users to create machine credentials. I'd like to avoid having to set up and maintain a Keycloak instance. Not sure if I can add attributes (claims or something else) to a machine/service account JWT.
Auth0 – Hits some of these, but doesn't allow me to add attributes to machine/service account JWTs, although it will add permissions to them (but that isn't enough).
I've just setup my first Keycloak server to offer SSO between two applications. These are not Java applications, and one is connected with SAML-2 and the other with OpenID Connect.
So in Keycloak I have Realm-1, and then Client-1(application1) and Client-2(application2) and user-1 and user-2.
Now I want user-1 to only be allowed access to Client-1, and user-2 to be allowed access to both Client-1 and Client-2. Should be simple enough.
I have tried to read up on Roles and Authorization, but I find the documentation(or maybe just the topic) very confusing. I have been playing around with it with no success. I was expecting an interface to just map a group to a Client, and restrict access to the Clients by adding/removing users from groups.
If you are using SAML:
Create a new role in Keycloak.
Assign this role to the group.
Create new authentication script in Keycloak. Configure which role is allowed upon login (e.g. user.hasRole(realm.getRole("yourRoleName")) ).
In client setting, under "Authentication Flow overrides" choose the created authentication(from step 3).
If you are using openid, look at the comment in this thread
Making first steps with Dreamfactory and followed the tutorial I am not finding, how could I apply role to the user, when I want user to access some service (and not app).
Here
http://wiki.dreamfactory.com/DreamFactory/Tutorials/Accessing_SQL_tables
is described, how to create such role, but on User-tab there is no place to apply roles for services, there is only list of apps.
How could I achieve it?
I'll do my best to explain
Access to services is always controlled by Roles. You can have as many or as few Roles as you like.
Apps (API Keys) can have a default Role, but it is not required.
If the app has a default Role, then no JWT is needed to access. The call is made with API Key only, and the default Role is used to allow or deny access to services.
If the app does NOT have a default Role, then a user session (JWT) needs to be included in the call, in which case the User and App are correlated to a Role, and that Role is used to allow or deny access to services. A User may have a different Role for each App.
Assigning the user to app to role relationship is done via the User management tab.
So with that in mind, you need to create a role that defines access to your desired services. Then you need to assign that role to the user for a particular app (api key.) Then when you make your api calls you will make them with the user's session and the api key included, and the role will allow or deny access to services as you defined it.
What are best practices for maintaining roles (e.g., a user-provisioning role) in a Web application that uses OAuth 2.0 authentication against a Google App domain? These are roles that are tied to a specific Web application, rather than to the domain as a whole.
Is role management at the application level typically done using the application's backend database, once the OAuth Web flow authorization has been completed? I was thinking of using a Google App group to stand in for each role and then verify membership in the group using the Directory API before allowing an action to be carried out. Is this a suitable approach? This requires either a service account with a group-membership privilege or the assigning of such a privilege to each user in the domain with that role, which are steps that would be nice to avoid.
Is there an API to read information about Google App's native domain-level roles for this? Should custom properties on the user's profile be used? If the latter, is there a straightforward way for a domain admin to set these up when provisioning a new user in the domain, or will a separate UI need to be built out? I've noticed that in the user profile information there is a isDelegatedAdmin field, but that field is a boolean, and I have not found anything with more granular information on the roles delegated to the user account.