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.
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 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.
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
In our application based on Symfony2 we would like to create a list of which of the users in the system that has permissions for a given domain object. We are using ACL and our immediate instinct was to look in the ACL-object returned from the ACLProvider of the domain object in question, for methods that could return the users (or at least SecurityIdentities) that has permissions, but I could not find such methods.
We are certain that this functionality is available through the API, but we cannot find where these methods are hidden.
EDIT An alternative would be to look up these connections in the acl-tables directly and finding out that way, but it would not be very pretty and we would probably be reinventing the wheel.
By default, the Authorization are specified in the file app/config/security.yml. It describe if a Role is allowed or not to access some modules.
There are some differences between Authorization and Permissions.
Permission are not managed by default by Symfony but through specific development (or bundles...)
When implementing an RBAC model using an LDAP store (I'm using Apache Directory 1.0.2 as a testbed), some of the actors are obviously mappable to specific objectClasses:
Resources - I don't see a clear mapping for this one. applictionEntity seems only tangentially intended for this purposePermissions - a Permission can be viewed as a single-purpose Role; obviously I'm not thinking of an LDAP permission, as they govern access to LDAP objects and attributes rather than an RBAC permission to a ResourceRoles - maps fairly directly to groupOfNames or groupOfUniqueNames, right?Users - person
In the past I've seen models where a Resource isn't dealt with in the directory in any fashion, and Permissions and Roles were mapped to Active Directory Groups.
Is there a better way to represent these actors? How about a document discussing good mappings and intents of the schema?
RBAC is not RBAC is not RBAC and RBAC on paper is difficult, but nearly impossible to implement in a real-life.
Everyone has their own "idea" of RBAC and most everyone uses different terms for every thing associated with RBAC. Generally from an LDAP implementation perspective you seldom have all the "pieces parts" to do a proper implementation within LDAP.
The "pieces parts" in simple terms are:
S = Subject = A person or automated agent or Users
P = Permissions = An approval of a mode of access to a Target Resource
T = Target Resources = The Object to which you want to assign permissions
The Role, at minimum, needs to associate a Permission and a User.
The Target Resource could be outside of LDAP entirely. So it could be an Application on a Tomcat server or simply the right to read "other" entries within the LDAP Server.
So typically the best you will do within LDAP is to setup an object which has a list of users and if there are some resources that are within LDAP, assigne the proper directory permissions for those target resources.
Then there is the little problem implementation.
We have now need a Policy for implementation of our Role. So our role, we will call it USER-READ-ONLY, is not useful without a policy on how it is to be used.
In our case, we could just say the USER-READ-ONLY Role can read anything in our Organization.
So we now have a Policy. Where is this policy stored? The Digital representation of a Policy is stored in the "Policy information Point" or PIP.
How do we interpret the Policy Supplied from the PIP? Policies are interpreted by the Policy Decision Point (PDP).
Who decides if a Subject (user) can access a resource? The Policy Enforcement Points (PEP).
Putting all this policy stuff together we end up with the digital representation of the Policy is provided by the policy Information Point to the policy Decision Point which then passes the decision to the Policy Enforcement Point where the access is permitted or denied.
So in our RBAC story, where is the PIP, the PDP, and the PEP?
Well if the Target Resource is in the LDAP directory, then it is the LDAP directory that is the PIP (which we probably hardcoded and is not abstracted, the PIP likewise and the PEP too, and that was easy.
But if it is our Tomcat Application, it MUST be a method within the Tomcat Application that can interrupt knows must use a method to say "I have this Subject (user) and he wants access to this Target Resource (inventory) to perform this Permission (READ-ONLY)".
Sure there are some standards for all this stuff. (Google XAML, RFC3198, ISO10181-3, NIST) but they are Standards with wide gaps for practical implementations.
So keep in mind REAL implementations of RBAC is hard.
Sure IMHO, we should know about RBAC, study the papers and make it a strategic direction, but the real life implementation across a broad base of vendors and applications, well we are just not there yet.
-jim
Check out Fortress which is a real-life, open source implementation of ANSI RBAC (INCITS 359) that uses LDAP. http://iamfortress.org/
and yes it was fairly difficult to implement but we've been working on this problem for over 10 years. ;-)