A first version of the ACL SPI, and an associated simple implementation, are now available: SPI: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-spi/tru... Impl: http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-s... There are a few implementation tests that can serve as examples of ACL usage. The key to this impl was to keep things as simple as possible, and we realize that things will have to be added in order for the ACL SPI to be useful for all projects. We wanted, however, to have something simple out to start discussing enhancements/changes. Known TODOS and issues: - The ACLProviderImpl is not yet saving the ACLs to a backend DB (it generates the ACLs and keeps them in memory), which makes it no good for any production environments. This will be one of our priorities in the ACL project. - Julien: after developing a few tests I've understood the need to somehow describe relationships between resources. The current implementation doesn't take this into consideration, but I now think that we will need something to allow for resource navigation. For example, when looking up the ACL for a resource, the ACLProvider simply returns null if no ACL was found for that resource. However, apps may have a policy (very reasonable to assume this) that says that when a resource has no associated ACL, then the ACL of the "parent" resource can be used instead. This is like "inheriting" permissions from another resource, such as a file resource "inheriting" the permissions from it's immediate directory resource. However, this kind of resource navigation depends on the specific implementation, and somehow the ACLProvider must be informed of the "strategy" it should use to lookup resources (as a resource does not necessarily need to inherit from another resource for us to have a parent-child relationship between them). You will also notice that the ACLProvider does not provide query methods to find out the resources that have an associated ACL (or those that don't). This is also due to the lack of resource navigation, so it is currently not possible for the ACLProvider to perform such queries. - The current implementation only checks if an identity has "any" of the permissions specified in the ACL.isGranted method. I think it would be nice to at least provide a way for users to ask if an identity has "all" of the specified permissions. More complex permission combinations would require some sort of permission policy (see bellow). - It was also mentioned that it would be nice to have relationships between resources. I don't see the need for this kind of thing when you use basic CRUD-like permissions. However, if applications need more complex permissions (and permission resolution stategies), we can think of adding something like a PermissionPolicy, that describes how permissions relate (e.g, "if user has PermA and PermB, then it also has PermC", or "an user cannot hold both PermA and PermB at same time"). The ACL, when determining the set of permissions associated with an identity, would use this PermissionPolicy to come to the final permission set associated with the identity. - Performance: the current permission implementation is based on bitmasks, so determining if an identity has one of the supplied permissions is a very fast operation. Assuming that the ACL for a given resource is already cached by the ACLProvider, the cost for determining if an identity has or has not a given permission is O(1). Of course, adding stuff like permission policies and resource navigation strategies can impact the performance of the ACL layer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116385#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...