A few questions about Shiro use

[John Vines <vi...@apache.org>]

I'm working on a piece of back end software and I think Shiro is a good fit
for it. We have a wide user base and we want to accommodate integrating
into whatever their security systems architecture is. However, there are
two issues which I haven't seem to resolve in my playing with Shiro that I
hope you can help me with.

The first one is an easy one- I need to be able to get a given user's
roles. Not check if they have one, but just list what they have. Is this
hidden somewhere in the SecurityManager api, or do I need to have specific
hooks for the realms in order to get this functionality working. I know in
the worst case, I can require all roles to be provided ahead of time and
then iteratively check them, but that seems awful and clumsy for the person
setting the system up.

Second is a bit trickier, though I may have it open in a tab (there's still
a lot of material I need to read through, but I'm facing some deadlines).
What is the best practice for simply being a negotiator for authenticating
remote users and grabbing their roles/permissions? Right now I'm pretty
sure I'm doing it wrong, as I'm keeping a userString->PrincipalCollection
map, while rechecking if they're still authenticated (and doing login if
they're not).

Thanks
John

Re: A few questions about Shiro use

[Les Hazlewood <lh...@apache.org>]

Hi John,

Please see inline below:

> The first one is an easy one- I need to be able to get a given user's roles.
> Not check if they have one, but just list what they have. Is this hidden
> somewhere in the SecurityManager api, or do I need to have specific hooks
> for the realms in order to get this functionality working.

If your realm subclasses AuthorizingRealm, your doGetAuthorizationInfo
method can return all of the Roles for a particular account.

However, instead of asking Shiro for this data from your Realm
directly (and tying you to an Shiro-specific implementation class),
what I do in cases like this is create a RoleDao (or something
similar) that can do the lookup.

I then use the same RoleDao within my doGetAuthorizationInfo
implementation to satisfy that method's needs.  This way I can
leverage the Dao's functionality in two places - one for my needs, one
for Shiro's needs.

> What is the best practice for simply being a negotiator for authenticating
> remote users and grabbing their roles/permissions? Right now I'm pretty sure
> I'm doing it wrong, as I'm keeping a userString->PrincipalCollection map,
> while rechecking if they're still authenticated (and doing login if they're
> not).

I'm not sure if this addresses your issue or not, but Shiro already
provides similar functionality in most Realms by using a Cache to
cache authorization information (and maybe authentication info if you
want it).

As indicated above, most people subclass AuthorizingRealm when writing
their Realm.  Then, if you configure a CacheManager on Shiro's
securityManager, the AuthorizingRealm will automatically cache
AuthorizationInfo for authenticated users.  The cache is automatically
purged during user logout, and if they don't logout, then the cache is
free to purge the entry based on TTL or whatever other criteria your
cache uses.

For example, with shiro.ini:

cacheManager = com.whatever.my.CacheManager
...
securityManager.cacheManager = $cacheManager

There are a number of CacheManager implementations out there - you can
use the Ehcache-based CacheManager implementation we have (you'll need
the shiro-ehcache .jar dependency):

cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager
# optional custom config:
# cacheManager.cacheManagerConfigFile = classpath:ehcache.xml

Or, I recently published Hazelcast integration, that I'm particularly
happy with:

https://github.com/stormpath/shiro-hazelcast-web-sample
(usage example:
https://github.com/stormpath/shiro-hazelcast-web-sample/blob/master/src/main/webapp/WEB-INF/shiro.ini#L31)

Of course, you could provide your own CacheManager implementation too
- Shiro's CacheManager API is extremely simple.

HTH!

Best regards,

Les