Les - thank you much for the detailed explanation. That was a tremendous help. I started digging into ModularRealmAuthorizer but your response answered a lot of questions that followed the exercise.
Thanks. On Fri, Sep 20, 2013 at 2:15 PM, Les Hazlewood <[email protected]>wrote: > 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. >> >> >> >
