Realms do not implement the RolePermissionResolver but most most realms extend AuthorizingRealm which implements RolePermissionResolverAware.
So basically all you do to use a RolePermissionResolver (or a PermissionResolver) is: authorizer = new ModularRealmAuthorizer(); authorizer.setRolePermissionResolver( <your object> ); defaultSecurityManager.setAuthenticator( authorizer ); I am pretty sure this is made much easier with the the object factory in Shiro. So you just need to set the correct properties. There is some doc on that somewhere ( take a look at that as it would be easier to configure ) Anyway, with a RolePermissionResolver implementation should be pretty simple for a given role, you return all the permissions, or all the permissions in the nested / inherited roles. So all you need to do is implement RolePermissionResolver, configure your securityManager and any AuthorizingRealm will be able to use it. My use case is similar. A given realm knows only its roles, but my application understands the mapping of roles to permissions (or nested roles). I have a single RolePermissionResolver that ties permissions to roles. The result is less code to manage! Example: My security Manager: https://github.com/sonatype/security/blob/master/security-system/src/main/java/org/sonatype/security/DefaultRealmSecurityManager.java#L63 (as I mentioned above, this code should go away once we tie the factory into guice for dependency injection ) My RolePermissionResolver https://github.com/sonatype/security/blob/master/security-realms/security-xml-realm/src/main/java/org/sonatype/security/realms/XmlRolePermissionResolver.java#L47 On Tue, Dec 21, 2010 at 5:41 PM, Jared Bunting <[email protected]> wrote: > I have attempted to search the archives but have been unable to find > anything on this subject. If it¹s been discussed before, can anybody clue > me into search terms? > > I¹ve noticed that it does not appear that any of the built-in realms in > Shiro support the concept of role inheritance roleA inherits permissions > from roleB. I can see situations in where this would be valuable, > particularly in combining multiple realms in an authorization scheme. I am > curious as to whether this sort of functionality has been considered before, > and what are the thoughts on it? Would contributions to this effect be > welcomed? > > In particular, I am considering a situation where an application defines > fine-grained permissions but also defines a set of roles (admin, reader, > writer) that have a default set of permissions. An organizational ldap > schema might define users and their organizational-oriented groups > (developer, tester, sysadmin, manager, etc). Being able to map > organizational roles to the default application roles could make integrating > an application into an existing infrastructure considerably easier. Are > there other solutions for doing this sort of thing? > > This also brings me to a related question. Is there any reason that the > default realms don¹t implement / support the RolePermissionResolver > interface? Again, this seems like it could be useful in combining > application-specific configuration with organization-specific configuration. > > I seek your thoughts and comments. > > Thank you, > Jared >
