I installed a vault and configured OIDC with gsuite, that was already an adventure in itself as the documentation is limited and even wrong at more than one place.
Finally I have a working authentication with my google accounts and I began to create roles, and there I saw a huge issue. How do you restrict google users from using a role. Let's say I create a gsuite-admin role that has access to all of vault administration, any user entering the role before login can assume it.
I tried to use the different claims but those seems to be only for vault created groups or other things.
Does anyone has a solution for that?
Thank you in advance.
EDIT:
The configuration I'm using whith group claims:
{
“allowed_redirect_uris”: “https://URL/ui/vault/auth/oidc/oidc/callback,http://localhost:8250/oidc/callback”,
“user_claim”: “sub”,
“policies”: “vault_admin”,
“ttl”: “24h”,
“groups_claim”: “devops”,
“oidc_scopes”: “profile”,
“bound_claims”: {
“group”: [“devops”]
}
}
That configuration only provides a lock of the role that can't be used anymore by anyone. From what I could see the JWT doesn't have any informations and that is why we used the config with the fetchgroup option in the oidc configuration.
I found a solution for this problem. Firstly, we need to ensure that a user is part of a G Suite group. Then mapping the G Suite group with Vault group (that has a policy assigned) ensures that the user is bound to the Vault policy.
This article contains some example steps and might be helpful.
Related
I'm quite new to the entire auth design and am still trying to understand how to use keycloak for authentication and authorisation.
Currently from what I understand in order to have authorisation enabled for a client you will need to have it in confidential.
After which I am kind of stuck in terms of how to set which policy for which permission.
I have a few types resources but currently placing them all under a single client for simplicity sake.
For my use case I have a workspace for users. So each workspace can have multiple users with different roles of owner,editor,viewer. And within the workspace there are artifacts. So it is some what like designing an authorisation for Google drive.
Would like some advice on how best to design it.
One way I have thought of is using groups and each workspace is a group. Using it to assign users to each group as a way to use the group policy for permission.
The other is really by creating multiple policy and permission for each artifact/resource and adding user to each policy for each workspace.
Would like any advice on authorisation design or even where to begin reading.
After some research I have come to these conclusion.
Yes these can be done by keycloak though most likely shouldn't be done in keycloak itself for its design.
Keycloak itself will most likely be more suitable in terms of authenticating/authorising on services or infra level. So this use case of having user be able to access workspaces or artifacts will be better done in application level having a separated service to handle the permission itself.
That being said if it really needs to be done in keycloak the design that I thought of that is not so scalable is as follow.
Create a policy/user and each workspace/artifact as a single resource. Depending on how many types of access/fine grain control is needed for each type of resource create the scope for each (e.g workspace:view, workspace:edit...). Then create a permission for each resource&scope. This allows fine grain access of basically assigning user to permission of each resource through the user policy.
But of course this design has its flaws of the need of too many policies, permissions and resources so it is better to have keycloak just handle the authentication part and authorisation is just giving users the role to be able to access a service and through the service check if the user is authorised for a certain action.
I want to create role-based access control system using Keycloak's authorizaion system.
I'm using OAuth 2.0 in microservice architecture and faced the following problem: I have records with unique IDs (they are rooted to other entities) and what I want to achieve is that only certain users or a group of users can see (modify) entries with these IDs.
And I would like to be able to explicitly bind users (or groups) to these IDs (and it is possible to receive them in JWT for example).
How could this problem be solved using Keycloak and what best practices to do this?
Perhaps I misunderstood something and this problem can be solved in another way?
Thanks in advance!
There are 2 ways to handle this:
1. Using Client roles:
i) ie. create some set of pre-defined roles (viewer, admin, editor, etc).
ii) Now whenever your IDs are generated, then generate one client in keycloak and assign any of above roles.
iii) in JWT, it will be visible in path :
"resource_access" --> <CLIENT_IDs> --> "roles": [your defined roles]
Then, in service layer can autorised using granted Authority or by roles-group.
2. Using Realm roles:
i) in JWT: this will be fetched from path: "realm_access"-> "roles":[your defined roles].
If you have only 2 roles (eg: admin and viewer), then 2nd option would be preferred.
Let me know if this helps. :)
Suppose that I have a web application. Consider it like a Black-Box for now. I want to use a backend system to limit what a user can view/do on the app.
i.e. Sample users can only do three functions, Premium users can do 10 functions and see more pictures.
What is the best way to do it?
I'm trying to using WSO2 Identity Server, but it doesn't offer this functionality. So I've thought that maybe I can integrate it with the WSO2 API Manager and make an API that limits users' access to a certain resource. But really I cannot find if it's possible do it. Anyone know it?
Please refer to : https://docs.wso2.com/display/IS530/Access+Control+Concepts
1) WSO2IS can act as a coarse grained access manager. Your application will act as a fine grained access mnager.
It means that roles can be defined in WSO2IS, managed and assigned to user. From there Roles assigned to one user can be provided as clains with the identity token generated by WSO2IS and sent to the application.
The application, on the other side, will manage roles to permissions links.
Access control is then done at each request by the application, based on the roles presented in the Identity Token by the user and the Permissions grid based on roles in the application.
2) The access control at the application is a business logic you must implement (or at least configure if it a COTS). It is possible to outsource this logic to WSO2IS as policies on attribute (with Workflows).
Please look at : https://docs.wso2.com/display/IS530/XACML+Architecture
Jeff
I'm new to wso2 and there are many new concepts to me ... I'm looking for a yes/no answer to the following question:
With wso2is, is it possible to authenticate users using one secondary user store (AD / LDAP) and authorize them using another secondary user store (JDBC, a database with only user and role tables)?
If the answer to the question is "yes", can you please provide me some links to some related examples or documents?
Any suggestions?
Thanks.
Yes, its possible. we can use different user stores.
Please refer
https://docs.wso2.com/display/IS530/Architecture
https://docs.wso2.com/display/IS530/Configuring+Single+Sign-On
Yes!! it is possible. Write your own custom UserStore and overwrite the method getting claims from user store.
Google it and you will find steps to do that.
Laravel 5.1.11 already has been updated with Authorization. Zizaco's Entrust has been around for a while now. Which should we use in authorising users?
I use both. I find policies are helpful for limiting user access to models that they "own", while entrust is helpful for defining roles and permissions for users in general. Sometimes I combine the two by returning true for a policy if the user has a certain role.