Actually ACL object defines a notion of domain, so 1/ is not very relevant. "julien(a)jboss.com" wrote : it looks indeed simple. | | we need to solve issues like : | | 1/ notion of domain that contains a set of permissions and a set of resources | | 2/ what are the different kind of permissions available for a given domain, describe relationships between permissions (i.e Permission A implies Permission B for instance) | | 3/ describe resources in a better way and also the relationship between resources, i.e Resource A is related to Resource B using XYZ relationship. | | "sguilhen(a)redhat.com" wrote : After taking a look at the Acegi and Sun ACL APIs, Anil and I discussed some points and we came up with a first version of the design for the JBoss ACL, which can be found at http://www.ime.usp.br/~sneusatz/acl. The goal is to start with a simple API, and leverage it as the requirements become clearer. | | | | The concepts shown are fairly simple: an ACL contains a set of entries, and each entry associates a set of permissions to an identity. The resource being protected by the ACL is represented by the Resource interface, which provides translation between the application-specific resource objects and what is used by the ACL API. An ACLProvider instance is responsible for managing the ACLs (create, search, update, and delete ACLs), probably interacting with a ACL repo (like a DB). | | | | This is, of course, just an initial sketch. The plan is to use Sun's API as a starting point, enhance it, and provide a fast CRUD implementation based on that API. This will allow us to see if it fits our needs or if we need to define our own API. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103872#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...