I might be missing something, but here's my take: You have LDAPRealm and CustomRealm. First of all, I haven't used it yet, but from what I can tell looking at the documentation, JndiLdapRealm doesn't support groups - so I'm assuming you've extended it or implemented your own.
That being said, we can take two approaches: LDAP groups are treated as roles, or LDAP groups are treated as principals. Neither one seems less valid to me, but the solution changes depending on which one we pick. For resolving permissions, shiro recognizes these mappings: PrincipalCollection->Roles (AuthorizingRealm) PrincipalCollection->Permissions (AuthorizingRealm) Role->Permissions (RolePermissionResolver) (As you can see above, Roles are not treated as Principals by default - and they are neither Principals nor Permissions, they are their own concept - although they can be used in a permission-type capacity.) 1. LDAP groups are treated as roles I'm starting with this one because it's how I would have implemented it and what I based my previous response to you on. The premise here is that the LDAPRealm does the first 2 mappings, and the CustomRealm does the third. CustomRealm implements RolePermissionResolver (this doesn't really even have to be a realm...it could only implement RolePermissionResolver). The "resolvePermissionsInRole" method should expect a string that represents an LDAP group. It should then return a set of permissions based on this group. How it does this internally is an implementation detail - if you use roles to apply a set of permissions to certain groups, Shiro doesn't really care. Next you will set the CustomRealm as the RolePermissionResolver for the LDAPRealm. LDAPRealm ldapRealm = new LDAPRealm(); ldapRealm.setRolePermissionResolver(new CustomRealm()); 2. LDAP groups are treated as principals I hadn't considered doing this before, but I like it. This method lets us avoid the RolePermissionResolver and simply implement CustomRealm. CustomRealm extends AuthorizingRealm but does not do any authentication. Instead, in its doGetAuthorizationInfo method (I think) it will pull any ldap groups out of the PrincipalCollection and lookup permissions for those. Again, how it maps those groups to permissions is an internal detail. Using this method, your returned AuthorizationInfo object can contain all of the roles for the principals as well as all of the permissions. So, in conclusion, I'm not sure if I've answered your question or not, but I've taken a stab at it. Let me know what I can clarify. -Jared On 03/18/2011 09:03 AM, Philippe Laflamme wrote: > I've added a RolePermissionResolver to my realm, but I still can't get > another realm's roles to resolve the permissions. > > Seems like the RolePermissionResolver will resolve permissions for the roles > provided by the realm itself: > > AuthorizingRealm#resolveRolePermission() is the method that invokes the > RolePermissionResolver. It is private and takes a AuthorizationInfo as an > argument. > > The AuthorizationInfo instance is built by the realm itself from the > PrincipalsCollection. So in fact, it will never contain roles from other > realms. > > I don't see any way of looking up permissions in a custom realm for roles > defined in another. I'm fairly confident that my use-case is valid: LDAP > authenticates users and provides principals (usernames and groups); users > and groups are provided permissions in my custom realm. I thought I could > map groups to roles in Shiro and lookup permissions based on these, but > Shiro treats roles as authorization tokens, not as principals (is this > correct?) > > Is a role a principal or a permission? I would think it's a principal since > the use of a role is to provide permissions: either through ACL or through a > containment check: isUserInRole(). > > Thanks, > Philippe > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Multiple-realms-and-roles-tp6178792p6184615.html > Sent from the Shiro User mailing list archive at Nabble.com.
signature.asc
Description: OpenPGP digital signature
