Saturday, 3 October 2009

Key limitations of Seam's IdentityManager and IdentityStore implementation

There are a couple of key limitations imposed by the implementation of the Seam IdentityManager and IdentityStore classes. The IdentityManager is supposed to be the main component for managing all Users and Roles. To create a User, you should call IdentityManager.createUser(). To enable/disable a User, or add/remove Roles, again call the appropriate IdentityManager functions.

The IdentityManager then uses an IdentityStore to manage the interface to a database or external data source (e.g. LDAP). The JpaIdentityStore class assumes storage in a series of database tables in the application's DataSource. To make this work there are a series of annotations that identify the User and Role entities, and specific fields on them (e.g. user login, password, etc).

And in case there are other attributes on the User entity (secret question, date of birth, etc), there is a PrePersistUser event raised by JpaIdentityStore, which you can hook into and set these other fields.

But therein lies the problem. The IdentityManager doesn't provide any means to Update a user after it's been created. So there is no clear way to save changes to a User through the IdentityManager.

So far, I've ended up side-stepping the IdentityManager completely. Instead, a customised UserManager component which started life as an EntityHome. Then a custom Authenticator to use the User entity to validate user name and password.

While this does tie you into a custom User and Group/Role implementation (which means switching to LDAP, etc is more difficult), it bypasses the limitations of the current IdentityManager and IdentityStore interfaces. Until the IdentityStore interface is expanded to include additional User attributes, it really doesn't look like it will cut it in an enterprise-level environment. Of course in an enterprise environment you're probably more likely to be dealing with custom integration to the organisation's existing security framework, so this is probably not a big deal.

No comments:

Post a Comment