I don't know that there is an existing example, but Shiro was specifically
designed to allow for this use case: Authentication and Authorization are
orthogonal concerns and so they don't need to be coupled. And, you don't
need a SecurityManager; a SecurityManager 'sits higher up' in the
architecture. You can just drop down to the Authorizer level and you'll be
good to go.
My recommendation is to just use the ModularRealmAuthorizer as the 'top
level' component you deal with. Yes, this requires configuring at least
one Realm, but I don't know why you would be discouraged to do that:
writing a trivial Realm to talk to whatever data source you have is
trivial. It doesn't even have to talk to a data store directly - you could
just have it interact with one of your application's business objects.
One benefit of Shiro's Realm implementations (or your own if you subclass
AuthorizingRealm) is that they have a caching mechanism to ensure role and
permission checks remain fast.
If this were my environment, I'd do the following:
1. Subclass AuthorizingRealm and
a) override doGetAuthorizationInfo to talk to whatever services (or data
stores) you wish to acquire authz data (roles and permissions).
b) override doGetAuthenticationInfo and return null since you won't be
doing authc.
2. Configure your AuthorizingRealm instances with a CacheManager to ensure
fast role/permission checks:
authorizingRealmInstance.setCacheManager(aCacheManager);
3. Define a ModularRealmAuthorizer and configure it with one or more of
your Realms. Have your app access it by the Authorizer interface so it
doesn't 'know' the implementation, e.g.
PrincipalCollection principals = //get or create a PrincipalCollection
instance that represents your user
boolean isPermitted = authorizer.isPermitted(principals,
"some:permission:here");
I would probably even create an application-specific AuthorizationService
interface that mirrors Shiro's Authorizer interface, but instead accepts
whatever your applications user ID type is, so callers don't need to know
about the PrincipalCollection concept (in fact, they wouldn't even know
Shiro existed). For example, if you identified users by an long primary
key:
public interface AuthorizationService {
boolean isPermitted(long userId, String permission);
... etc ...
}
The AuthorizationService implementation would:
- create a PrincipalCollection instance that wraps the userId
- delegate the call to the Shiro Authorizer instance w/ the constructed
instance.
Short and sweet, and your app components don't even know Shiro exists
because all they see is your AuthorizationService :)
HTH!
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Fri, Sep 20, 2013 at 9:20 AM, Toadie <[email protected]> wrote:
> I am looking for a light-weight Authorization framework for our
> application without an explicit requirement for Authentication. I have
> spent the last few days looking at the docs/samples and tutorial in SHIRO
> but am not able to find a simple solution without having to include either
> a full blown SecurityManager and/or Realms.
>
> Basically, i am very much interested in the WildCardPermission scheme.
> Our application is machine-to-machine communication. The authentication is
> already hardwired and can't be changed.
>
> The permission model is also already defined but can be modified to export
> permissions in WildCardPermission scheme. I only have access to the
> User/Machine Login ID and Roles so I can't really leverage
> authentication.
>
> Are there any examples within the community that illustrates that?
>
> Thanks in advance.
>
>
>
