On Wed, Jan 25, 2012 at 10:49 PM, vdzhuvinov <[email protected]> wrote: > Hi guys, > > I'm working on a platform for a SaaS app to allow third party add-ons and > mini-apps to coexist alongside the main app (itself a collection of JSON web > services tied together by a pluggable web UI). > > At present we have a simple JSON web service to provide SSO and shared > session mgmt to the platform. This service doesn't handle clustering and > authorization queries, so I consider migrating it to a framework that does. > Last night I had a look at the Shiro docs and API and it looks very > promising. I actually was very delighted :) > > I have three questions: > > 1. I suppose there is no problem attaching a map of attributes to Subject? > We use the Json2Ldap web service for authentication and on success we also > retrieve a bunch of selected LDAP user attributes.
Nope, no problem - you'd just store that as an element in the PrincipalCollection returned from a Realm. However, I would caution that, if using sessions, the PrincipalCollection is stored in the session. For clustering reasons, the smaller the session the better, so people often only put one or two 'pointers' (e.g. IDs) into the PrincipalCollection and use that at runtime to look up additional information (where data caching strategies can be better leveraged). > 2. Is there an API to the session store to allow monitoring and stats, e.g. > to be able to see who's online and track the number of current sessions? No, if only because at the moment, that data is a reflection of the session data store itself (i.e. whether or not you can query the data store for that information). I suppose Shiro could keep a running tab of this information and store that state itself, but would 1) require a decent amount of work and 2) introduce complexities in a clustered environment (i.e. do you aggregate the numbers across each application instance's SessionManager instances? how do you do that cleanly?) For these reasons, it has always been easiest to just query the underlying session store directly if possible. > > 3. How easy it is to plug in an IdP or IdC flow into Shiro, e.g. to allow > the service to act as an OpenID Connect provider or relying party? This is pretty easy actually - the 'openid4j' module in the Shiro trunk is one example (not released - just in trunk development). It has a Realm that delegates to an IdP and a Filter to plug into Shiro's config to handle protocol-specific web requests. So you'll basically need a new Realm and maybe a Filter instance (plus whatever supporting components you need), and that's pretty much it. HTH, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
