Role "Nesting" or "Inheriting" and RolePermissionResolvers

[Jared Bunting <ja...@digitalreasoning.com>]

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

Re: Role "Nesting" or "Inheriting" and RolePermissionResolvers

[Brian Demers <br...@gmail.com>]

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
<ja...@digitalreasoning.com> 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
>