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...