I'm having some problems to configure a keycloak server. I created two roles, two groups (one per role) and two users (one in each group). Now I'm trying to give the authorization to access to a specific path (e.g http://localhost:8080/api/private/premium) only to one of my groups.
I created (under Authorization tab) a resource with the URI that I want to protect, a policy (type group) and a permission. I also use the Evaluate tab to test this configuration and I get the correct result: result DENY for the user in the group NOT associated with the policy, result PERMIT for the user in the other group. So I tried to test the configuration using POSTMAN:
1_ get the access tokens of my two users (http://localhost:7070/auth/realms/REST_realm/protocol/openid-connect/token).
2_ get the protected resource (http://localhost:8080/api/private/premium), first with the unauthorized user, then with the authorized.
The problem is that I get the resource correctly in both cases (I was expecting an error message for the call with the authentication token of the unauthorized user).
Any suggestion?
Related
I have a KC instance where I have some clients with the Authorization option enabled. All works well, but, acting as a client, I need this specific information: Given a certain resource with specific scopes I want the list of users who have accesse to this resource.
I've explored the available APIs multiple times without success. Is there a way to obtain this information or do I necessary need to extends KC capabilities with a dedicated SPI ?
It is possible by Admin rest-API for finding a specific resource's all of user.
This steps
I am using Keycloak v18.0.2 (if use v19/v20, just remove auth in API endpoint)
#1 Get specific client uuid
GET {keycloak_url}/auth/admin/realms/{realm}/clients/{client-uuid}
#2 Get specific resource uuid
GET {keycloak_url}/auth/admin/realms/{realm}/clients/{client-uuid}/authz/resource-server/resource/{resource-uuid}
#3 Get specific permission of #2
GET {keycloak_url}/auth/admin/realms/{realm}/clients/{client-uuid}/authz/resource-server/resource/{resource-uuid}/permissions
#4 Get policy of #3
Get policy and permission list
GET {keycloak_url}/auth/admin/realms/{realm}/clients/{client-uuid}/authz/resource-server/policy
Get policy of specific permission
GET {keycloak_url}/auth/admin/realms/{realm}/clients/{client-uuid}/authz/resource-server/policy/{permission-uuid}/associatedPolicies
#5 Get user list of #4
GET {keycloak_url}/auth/admin/realms/{realm}/clients/{client-uuid}/authz/resource-server/policy/{policy-uuid}
The user list will return in body of response
{
"id": {policy-uuid},
"name": {policy-name},
"config": {
"users": "[array of {user-uuid}]"
}
}
Demo by UI
I will find all of user in resource1 of my-test client.
It assosicated permission1
permissions1 apply policy1
policy's user two users
Demo by API
Same step by APIs
Find client uuid
Find a specific resource uuid
Get specific resource
Get permission and policy list
Get associated policy for permission
Get user list for policy
That user uuid matched user list
So you can find resource1's user are user1 and user3
Unfortunately, you cannot. Keycloak authorization mechanism examines only when it has input. Here your input is User.
To do that, you have to ask for all users. This is not practical bcz there might be thousand of users.
Resource servers (applications or services serving protected resources) usually rely on some kind of information to decide if access should be granted to a protected resource. For RESTful-based resource servers, that information is usually obtained from a security token, usually sent as a bearer token on every request to the server. For web applications that rely on a session to authenticate users, that information is usually stored in a user’s session and retrieved from there for each request
I have two realms, a public webapp and an extranet where only employees can access.
I have tried setting group policies.
When I try to connect with an non-employee user, keycloak still returns the access token.
What did I miss?
EDIT.
I made a mistake, I only have 2 clients.
You have to limit the access granted to your access token to achieve this. There are three ways to do it (that I know of)
Audience: Allows listing the resource providers that should accept an access token.
Roles: Through controlling what roles a client has access to, it is
possible to control what roles an application can access on behalf
of the user.
Scope: In Keycloak, scopes are created through client scopes, and an
application can only have access to a specific list of scopes.
You can look at this example which explains the flow on how to achieve this using role based method. You can refer this as well.
I am trying to understand the use of access tokens to authorize an API fronted by API Gateway.
My current understanding of the process is as follows:
After setting up a Cognito User Pool, I can define a resource server and associated scopes (e.g. https://wibble-api.com/read, https://wibble-api.com/full).
Then, I can select the allowed custom scopes for a user pool app client.
In AWS Gateway, I can create a Cognito Authorizer to authorize incoming requests.
For each AWS Gateway resource, I can go into the Method Request and select the Cognito Authorizer and determine which OAuth scopes are necessary in order to be able to execute the API method e.g. I can enter https://wibble-api.com/read, https://wibble-api.com/full to indicate that either of those two scopes are sufficient to be allowed to execute the API resource.
When using the hosted UI, the scope parameter will include all of the allowed scopes configured for that app client, and the returned access token (if using implicit grant) will contain those scopes as part of the JWT.
What I don't understand is, I have what must be a very common scenario where I want to be able to give the read-only scope to, say, a user that hasn't paid for the service, and the full scope to a user that has paid. Yet it looks like I would need to have two separate app clients if I'm going to be using the Hosted UI, because there doesn't seem to be a way to return different scopes depending on, say, what group the user has been assigned, or some other metadata in their user profile such as department, etc. I won't know what sort of user they are until after they have been authenticated, but I still need to enter the exact scope when I am authenticating. Is there a solution for this, please?
I'm cant GET Feeds of a Public Group where I'm the Admin.
The result is "(#200) Permissions error".
If I use an USER Access Token, The GET Work Ok, and obtain the list of feeds.
Please help me !!!!
The v2.12 update currently requires an admin user access token to read the group/feed endpoint among others. This is temporary and in the coming weeks it will return to allowing non-Admin permissions but restricting the amount of user information returned.
source: https://developers.facebook.com/docs/graph-api/changelog/version2.12#gapi-90-groups
GET /group — GET operations on the following fields and edges now require an access token of an Admin of the Group:
[...]
GET /feed*
[...]
In the coming weeks, edges marked with an asterisk (*) will once again allow requests from non-Admin Group members. However, responses will not include User information unless the request is made with an access token of an Admin of the Group.
I was told that it is possible to give information about group membership during a SAML authentication request. We have to connect to an application that does use SAML (we are at the end that is creating the SAML answer XML). Authenticating a user works fine but I can't find a way to specify a "member of" or similar attribute.
Can you explain to me how to pass group memberships in SAML during authentication or have an example ?
I know there is a possibility to take care of authorization in SAML at a socalled Policy Decision Point. But this would mean that a SAML flow would happen for each or some (if batched) entities we want to check authorization for.
Let me give you an example what we are trying to do. This example is made up but shows the problem we want to solve.
Let's assume you have a hard drive with lots of directories and files on it. We use SAML to authenticate the person that tries to access that drive. Members of the group "admin" are allowed to read and write and members of group "user" are only given read permission.
Because of this we want to send the group memberships of a user when he or she authenticates. Because otherwise it would mean that the application has to check for every file if the user is in the necessary group. If it was clear from the beginning (after authentication took place) that someone is a member of a specific group the application can cache that in memory.
As with most things in SAML, this depends on the identity provider as well as the application.
Many identity providers have access control to allow or deny specific users or groups to access an application. Sign-on is then denied by the IdP after authentication based on the ID of the application (from the SAML request) and access control configured in the IdP. If you just want to control who has access to the application, then this is all you need, and most, if not all, identity providers should have you covered.
Sometimes you also want different users or groups to have different permissions inside the application, or you want memberships in certain groups on the IdP to be mapped to membership in groups inside the app's own user and group database (or other application-specific group-like concepts). There is no standard for this, but some identity providers allow the definition of attribute mapping rules based on group membership. For example, in ADFS, you can create a claim rule that sets a specific SAML attribute to a specific value if and only if the user is a member of a specific group in AD. You would then set up such a rule and set a SAML attribute that your application understands to a value it understands.
Alternatively, if an application supports configuration of multiple IdPs, then you can configure one app / IdP mapping per group, and for each group add an attribute mapping rule with a hard-coded group name in an attribute that your application understands.