I'm reading the shiro documentation and never found any signs that shiro supports user groups concept on API level.
I would have expected that Subject.java would have such methods as getUserGroups, but it doesn't. For example, if I write some application which aims to work with numerous authentication systems, when the user creates some object, I would like to make it visible for all users in the object creator's groups, and to do it in an authentication provider agnostic way, using some facade API, like shiro Subject.
But it's looks like I can't doing this using shiro api, is this correct?
How do you support user groups concept in multi-auth applications ?
Should I write some UserGroupAwareSubject extension ?
Shiro as of 1.2 does not have a Group concept in its API - it has the notion of Roles and Permissions.
This is not a problem if you have only Roles or you can use your Group names as what Shiro calls Roles (i.e. realm.hasRole(roleIdentifier, authzInfo) uses your Group name as the 'roleIdentifier').
If you have both Role and Group concepts in your application, you will probably not easily be able to use subject.hasRole for checking both. If you'd like this as a feature, please open a feature request.
Two options for this though if you want to make it work is:
Have one Realm where realm.hasRole calls check against your Roles and another Realm where realm.hasRole calls checks against your Groups.
Use one Realm to perform both and just prefix the strings you use for group checks with a recognizable token, e.g.:
subject.hasRole("group:myGroupName");
Then your realm can check to see if has that prefix, and if so, do a group check, and if not, do a role check.
These options aside, what many people do in this case is ignore Role and Group checks entirely and instead rely on (the more powerful) permission checks in code:
subject.isPermitted("document:1234:read");
Then your Realm can check both the Subject and any of its assigned Groups or Roles to see if they imply that permission. If so, then you don't need any Group or Role checks at all because your code relies on permissions instead of the (potentially volatile and numerous) Groups/Roles concept.
There are some good reasons why permissions are probably better than Role or Group checks, but if you feel otherwise and would still like Groups represented in the Subject API any, please do open a feature request.
Regards,
Les
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'm developing a Grails 3 web-app powered with Spring Security plugin, which already makes large use of #Secured annotations to protect controllers and actions according to the privileges of single logged-in users.
The login is currently managed via the usual username/password pair.
Now a new requirement came up, involving a custom request header, having as value a sort of 'authorization token':
this token identifies a group of users (let's call it team)
if this token is recognized as valid, matching against DB, then the whole application should behave as a predefined user (let's call it John, part of the team) was logged-in. In this sense it should act as a pre-authentication. This user will have his own roles, so the application will respond accordingly, as if John would had logged in with his own username/password.
if the token is not recognized, 401 status must be returned.
if the token is not passed, the application must have its current behavior, to the token management should be considered optional must not impact the current implementation at all.
I considered defining a custom filter (I also took a look at this post, which however has different requirements), but I cannot even determine:
the feasibility of this task
whether or not filters are the best approach (but I guess so as Interceptors are triggered too late, and I need some additional logic to be evaluated before Spring Security comes into play)
possibly, the best filter to extend
So any suggestion is welcome! Thanks in advance
Not an expert on this, but I would implement a custom UserDetailsService and set the authorities based on the token condition. You might also be able to do it in an AuthenticationSuccessListener.
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/
I'm working on a project where I've multiple ressources and multiple users, what I need to do is to associate different access rignts to every user depending on the ressource he wants to access to
The problem is that a simple LDAP server can't implement this kind of situation,
An idea is to use multiple LDAP servers, one for each ressource, then how could I manage them all?
Or is there another authentication process I can use in this case?
Spring Security has a special ACL module to handle such situations. The basic idea is that each domain object / ressource may have separate access control list. You need to fill this list with appropriate permissions and add corresponding checks in your code. You can have parent -> child relations between the objects to reduce number of permissions. Check it out.
If you have logic behind the access to the resources, you may want to use a rules authorization language such as XACML.
If the assignment of resources to users is arbitrary then the use of ACLs with Spring Security's ACL module is good enough.
The problem is that a simple LDAP server can't implement this kind of situation
Mine does. You use LDAP to define the roles associated with each user, then you use web.xml to associate the resources with the roles that are required to access them, then you configure/write your login module such that it looks up the roles of each user when you login. Container-managed security can do all that.
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.