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.
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 have a user, community and post type where a community can have multiple users and posts. The posts has an attribute called "visibility", if the visibility value is "private" only the users of that community can see the posts. If the visibility is "public" every user can see the post. Is possible to accomplish this using amplify and cognito? How?
Cognito has groups. You can create groups and add users into these groups. When your user authenticates they get a token, and the claims on that token can be used to confirm which groups they belong to.
Cognito Groups are really useful for controlling access to things like admin apis with an 'admin' group. However, if you're creating lots of groups of adding users in and out regularly, I would recommend implementing an application level feature (i.e. manage this in your database).
Cognito isn't as scalable as your application persistence is likely to be. It can be a bit slow and it doesn't come with nice features for managing your groups.
So yes, its possible to manage in Cognito, but I would recommend doing it with a database of some sort.
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.
I'm using Thinktecture Identity Server for SSO with some apps. The idea is that account information will be stored on the server in the claims information. So groups user membership and other hierarchies can exist on the SSO server. Then when some one authenticates they would get their membership and rights passed down through claims.
My question is how can my authentication subscriber perform a user.memberOf(x) kind of lookup? I can't imagine that the whole permission hierarchy gets passed down in a users claims. I imagine that additional queries would be performed against the sign on server like LDAP. How does this work for Thinktecture? Would it be the same generally for other SSO servers? If so what's the patterns name?
A general pattern is that, yes, you pass all roles in claims. This causes issues if there is too many groups but if this is so then it could be that the role model should be revisited.
Switching to oauth2-style authorization solves the issue: you don't pass claims in roles but then the relying party queries roles with an extra call. The drawback is that if the STS is further feredated with yet another STS, such extra calls become tricky as the call would require another internal call which would possibly require yet another call etc. Passing roles in claims means that there is no need for this extra call.
Yet another idea is switching to a custom STS that would issue claim roles filtered depending on the relying party or other user attributes. This could work as usually a single RP is not interested in all roles but rather a subset that makes sense there. Your filter is then implemented at the custom STS side.
Well - IdSrv is a custom STS. You can issue claims per RP - check this article (especially the part about IClaimsRepository):
http://leastprivilege.com/2013/05/17/customizing-identityserver/
How do I configure a Shiro to use Active Directory Authentication, but in addition I want to map the usernames to custom roles. I can't seem to find any information on this. Can anyone give me any pointers?
To do Active Directory Authentication use the JndiLdapRealm
For the authorization override the method queryForAuthorizationInfo
Be aware that you probably get group from your AD so you have to provide your own mapping (group to role).
About this shiro reference manual say :
A RolePermissionResolver can be used by a Realm internally when needing to translate a role name into a concrete set of Permission instances.
This is a particularly useful feature for supporting legacy or inflexible data sources that may have no notion of permissions.
For example, many LDAP directories store role names (or group names) but do not support association of role names to concrete permissions because they have no 'permission' concept. A Shiro-based application can use the role names stored in LDAP, but implement a RolePermissionResolver to convert the LDAP name into a set of explicit permissions to perform preferred explicit access control. The permission associations would be stored in
another data store, probably a local database.
Hope this will help
I'm working on doing the same thing, but I'm pretty sure you have to write a custom AuthenticationStrategy. I wanted to authenticate against AD but use the INI to define roles, but I could not get it to behave properly enough to not accept authentication against either (even utilizing FirstSuccessfulStrategy). I didn't get to look into it too much, so maybe one of the Shiro guys who floats around can correct this, but i hit these issues today.