I've been working on a bunch of changes to the Seam Security API in preparation for the next round of new features in our next major release. Before I start committing any of this stuff I'd like to run through some of the changes first and get some feedback. I believe that once these changes are implemented then Seam will have the most powerful set of security features in existence, even beating specialised security frameworks like Acegi. It would probably be easiest to explain everything in list form, so here we go with a list of new features in no particular order: 1) Strongly typed annotation-based permission checks. Based on Gavin's ideas back in October, the SecurityInterceptor will now perform permission checks for methods annotated like this: @Update(Customer.class) public void updateCustomer() { ... } We can possibly deprecate the @Restrict annotation in favour of this, but the point is that the new annotations are typesafe (as opposed to @Restrict which is not typesafe) and easily extensible. For example, say we want to define a new customer permission called "approve" - it would be as simple as creating a new annotation: @PermissionAction("approve") public @interface Approve { Class value(); } Which is then used like this: @Approve(Customer.class) public void approveCustomer() { ... } We will provide a standard set of annotations for CRUD permissions (although we already have a @Create so perhaps we need to think of some other name for it - maybe @Insert?) and developers can easily define their own. 2) A more sensible permission API Currently when we want to perform a permission check for an instance of a domain class, we write the permission check like this: Identity.instance().checkPermission("customer", "update", customerObject); This doesn't really make a lot of sense. The real target of our permission check is the customer instance (customerObject), not some arbitrary string. While still supporting this API (although it will probably be deprecated) the new API deals more directly with the actual target of the permission, like so: Identity.instance().checkPermission(customerObject, "update"); We can probably even use our @Update annotation in place of the String param: Identity.instance().checkPermission(customerObject, Update.class); The crux of this point is that instead of thinking of permissions as being a combination of [name:action], they should instead be thought of in terms of [target:action]. I.e. am *I* allowed to perform [action] on [target of the action]. The target of the action can still be defined in terms of an arbitrary string value, however it's scope has really been expanded to include things such as object instances, object classes, etc where previously in our rule-based security the permission name was _always_ a string. Similarly, the s:hasPermission() EL function has been updated also. In so many places I see it being used like this: s:hasPermission("customer", "insert", null) The third param in most of the cases I see is specified as null. In the actual API it is a varargs but we don't support vararg params in EL, so it is implemented as an Object param and therefore it is required. The new EL function will look more like the checkPermission() method: s:hasPermission("customer", "insert") or for an instance-based permission check: s:hasPermission(selectedCustomer, "update") So that we don't break backwards compatibility, we need to extend our EL implementation to support method overloading - this is not supported by the spec, although it is quite trivial to implement. I'm still waiting to hear back from Norman about getting this done. 3) Pluggable permission resolvers While Drools has been a great foundation for resolving logic-based security permissions, it is not a silver bullet and cannot easily deal with things such as ACL security or role->permission mappings defined at runtime. I also see people overriding Identity.hasPermission() to provide their own permission logic (Christian even does this in the Seam wiki). The new API provides a mechanism for "plugging-in" permission resolvers, offering a much more elegant solution than overriding the Identity component. This is how a permission resolver is defined: @Name("org.jboss.seam.security.ruleBasedPermissionResolver") @Scope(SESSION) @BypassInterceptors @Install(precedence=FRAMEWORK, classDependencies="org.drools.WorkingMemory") @Startup public class RuleBasedPermissionResolver implements PermissionResolver { Seam will provide the following permission resolvers out of the box: RuleBasedPermissionResolver - replaces RuleBasedIdentity, and provides support for the same type of Drools rule-based permissions. AclPermissionResolver - provides ACL security, for permission checks against object instances. This particular feature is in hot demand. The default implementation will use JPA to store object permissions in a database table, and will use some kind of nifty caching system to speed up permission checks. DynamicPermissionResolver - provides role->permission mapping permission checks. Like AclPermissionResolver, the default implementation will store its permissions in a database table. We will provide screens for the management of permissions and the roles/users that they are assigned to, similar to the identity management screens. GroovyPermissionResolver - this is more of an afterthought than anything, but it might be nice to allow people to define their permissions in Groovy. Permission resolvers can also be mixed and matched, giving developers the flexibility to use one type of permission check for certain operations, and another type of permission check for others. They can even be chained together, using a policy similar to a JAAS configuration, requiring that either one or all permission resolvers must allow a permission for it to be granted. These resolver chains are named, and domain classes can be configured to use certain resolver chains for specific permission checks. Configuration can either be annotation-based, like this: @Permissions({ @Permission(action = "update", resolverChain = "default"), @Permission(action = "delete", resolverChain = "other")}) @Entity public class Customer implements Serializable { or defined in components.xml, probably like this: <!-- Resolver chains defined here --> <security:resolver-chain name="default" require="any"> <security:resolver>ruleBasedPermissionResolver</security:resolver> </security:resolver-chain> <security:resolver-chain name="other" require="any"> <security:resolver>aclPermissionResolver</security:resolver> <security:resolver>customPermissionResolver</security:resolver> </security:resolver-chain> <!-- Permissions mapped to resolver chains here --> <security:permission-mapper default-resolver-chain="default"> <security:permission target="com.acme.model.Customer" action="update" resolver-chain="other"/> <security:permission target="com.acme.model.Customer" action="delete" resolver-chain="default"/> </security:permission-mapper> If no configuration is provided, then a default ResolverChain is created containing all PermissionResolvers that have been deployed in the Seam application. Permission checks are then resolved using this default ResolverChain, with the permission passing if any of the resolvers return true for their hasPermission() check. This provides a sensible default security policy without requiring any configuration. 4) ACL Security Expanding a little further on the last point in regards to ACL security, in a similar way it will also be configured via annotations: @AclFlags({ @AclFlag(mask = 1, action = "read"), @AclFlag(mask = 2, action = "update"), @AclFlag(mask = 4, action = "delete"), @AclFlag(mask = 8, action = "approve"), @AclFlag(mask = 16, action = "foo") }) @Entity public class Customer implements Serializable { The @AclFlag values define a bit-mask, along with a permission action. The permissions are stored in a database table with the following structure: ACL_PERMISSION -------------- OBJECT_ID IDENTIFIER ACCOUNT_ID FLAGS OBJECT_ID - used to identify the type of object, e.g. a customer. IDENTIFIER - identifies the instance of that object. In the case of an entity, it would be the primary key ACCOUNT_ID - the granted permissions are assigned to this account/role. FLAGS - the actual permissions granted. Based on the above example, a FLAGS value of 11 would mean the user has read, update and approve permissions for this object (read(1) + update(2) + approve(8)). It is extremely easy to add new permission types, and if the flag is based on a 64-bit long, that gives a total of 64 distinct permissions allowable for each object type. 5) Authentication - SSO, LDAP A number of outstanding JIRA issues will be included also - support for JBoss SSO, an LdapIdentityStore for connecting to LDAP with the Identity Management API, plus (hopefully) better container integration, at least with JBoss AS. That just about covers it - I'd really like some feedback on points 2) and 3) if possible, followed by a lesser extent points 1) and 4). Shane