Seam Security 3.0 and PicketLink
shane.bryzak May 24, 2010 10:36 PMI've been discussing with Anil our plans for the Seam Security 3.0 release, in regards to integration with PicketLink IDM. We are adopting the API model defined by PicketLink in Seam, and I'm currently in the process of refactoring Seam's identity management features.
We have identified a number of requirements for the Seam 3 release that are currently not provided by PicketLink. To facilitate a timely release, our plan is to address these requirements in the 3.0 release itself, and then deprecate them in Seam as they are (hopefully) implemented in PicketLink. Here's a non-exhaustive summary of the requirements that we have identified so far:
1) IdentityStore implementation for JPA. I'm currently working on this - we have an implementation in Seam 2.x but I'm rewriting it again based on PicketLink's SPI model. We could potentially port this to PicketLink with minimal difficulty.
2) Support for raising CDI events in response to certain operations. For example, when an entity is created for a new user, group, etc, a pre and post event should be raised to give the user a chance to modify the entity before it is persisted, or to establish additional references to it from other entities after it is persisted. This could be achieved via some kind of callback mechanism.
3) Annotations for configuring entities to be used for identity management.
4) A simplified API for identity management. In PicketLink there are multiple APIs for this - PersistenceManager, RelationshipManager, RoleManager, etc. In Seam we have a single interface, IdentityManager which provides all identity management operations.
5) Authorization for identity management operations. In Seam we perform an additional security check when a user tries to create a user, role, group etc or grant or revoke privileges to ensure they have the necessary privileges to execute such an operation.
6) Ability to plug in a cache for role and group memberships for users. It is our plan to use Infinispan in Seam to enable this.
We have some authorization-related requirements also:
7) Unified authorization architecture - in Seam, authorization checks are performed in a singular manner. The Identity.hasPermission() method allows for a permission check to be carried out for the current user against multiple PermissionResolver implementations. We have implementations for Drools (rule-based) and for persistent permissions (ACL-based). A single permission check will invoke all registered PermissionResolver implementations to determine whether a user has the necessary privileges to execute a secured operation. This contrasts to PicketBox which requires that you create a specific provider for the type of permission check required, e.g. ACLProvider. Our strategy for addressing this requirement will be to provide a PermissionResolver implementation for each of the providers offered by PicketBox, which can then be plugged into Seam's unified permission framework. One particular drawback that we have identified with the ACL support in PicketBox is the requirement for "resource" classes to implement the Resource interface. In Seam we use an IdentifierPolicy API which alleviates this requirement and allows any class to be assigned permissions, even String literals.
8) We require the ability to assign more than just the basic CRUD (create, read, update, delete) permissions to objects (this may be possibly already).
9) It should be possible to store ACL permissions in a database via JPA.
There is probably much more to discuss in terms of authorization, however in the interests of brevity I'll cut it short here. I would however like to see a unification of the two ACL-based solutions that we have independently developed, as it would be in our best interest to not have to continue maintaining two competing solutions.
Looking forward to hearing some feedback on these ideas.