[tom.baeyens]

in that case it would be wiser if we only go for what was the *initial* requirement that started this thread : something that provides ACL based authorization.

we leave the identity part out of it, if it does not fit all.

Portal already has a use case driven Identity component, so Julian's requirements and code should be taken into account.

the current layering of the portal identity component is a no go for jbpm.

Julien, correct me if I'm wrong.

The problem is not in the model of the data. I think we can easily find a common datamodel. The problem is in the pluggability layer of the portal component.

...

At a minimum, we should have a common DB schema for our identity data. Also I think that we should be able to leverage a common set of classes + hibernate mappings that accommodate for the persistence to that database schema.

1) Our data models for identity are almost... well... identical :-)
2) We both have a configuration in which we use hibernate to go to a relational DB

That is what we definitely should try to do together.

What we don't want to reuse from each other are the interfaces. Your pluggability interfaces are too far from mine and vice versa.

[soshah]

n that case it would be wiser if we only go for what was the *initial* requirement that started this thread : something that provides ACL based authorization.

we leave the identity part out of it, if it does not fit all.

Yes, for common ACL layer to be re-used across all the projects, it needs to be Identity Framework (Identity model/Identity schema) agnostic.

As a separate topic of discussion, it would also be nice to standardize an Identity Framework (Identity model/Identity schema) for re-use across different JBoss projects just like the ACL layer being discussed here

Thanks

[bdaw]

I can't imagine how we could agree on the common identity model. Everyone needs slightly different identity entities structure, relations or even attributes/properties.

Look at what Sun has in JES (Java Enterprise Systems). Whatever you deploy (portal, mail server etc.) you always have Access Manager (opensourced as OpenSSO) that acts like a black box to handle all the identity operations. Behind it you can plug a number of different identity stores. If you look at the API you'll see that while it defines few kinds of entities (user, role, group) the relations and attributes are not really strictly defined. So you can query two objects about what the relation can be. And in their scenario AM handles both identity and permissions.

IdM is quite huge thing and I don't know if we want to start a home grown solution right now. Its not something easy to implement to have "fit all projects" solution.

[anil.saldhana]

We need to have one unified api for identity (the portal identity api is a good start) for JEMS projects. Please forget about identity stores and other implementation details. The API should take into account aspects such as identity, roles (nested), groups etc.

Now how this API maps to the domain of other application servers/containers is an implementation/integration aspect.

This is IMHO.

[soshah]

Looking at this discussion, looks like two efforts are being proposed.

1/ A re-usable POJO ACL layer across JEMS (topic of this discussion, and IMO a higher priority item)

2/ A re-usable Identity Management Framework across JEMS (IMO, a nice to have, but not too urgent, especially considering the agreements that all JEMS projects will have to come to, in order to decide it)

I think ACL layer Design/Implementation should not be bogged down by the slower paced Identity Framework Design. They should be independent components of each other.

Thanks

[anil.saldhana]

Stefan, the JDK already has an API for ACL. We can leverage it, rather than creating a separate API for ACL.
http://java.sun.com/j2se/1.5.0/docs/api/java/security/acl/package-summary.html

Of course, we can add extensions.

[julien1]

I always heard from Scott that this ACL stuff is deprecated and useless code... at least this is the answer I had when I asked him the question 3 or 4 years ago.

[anil.saldhana]

The API is sufficient to hold CRUD type of access levels as long as you define the ACL permission class. But if projects start having complex requirements, then this jdk api may be insufficient. At this moment, I do not know.

Maybe Scott can give better answer about the acl api in the JDK.

[sguilhen]

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.

[julien1]

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.

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.

[julien1]

Actually ACL object defines a notion of domain, so 1/ is not very relevant.

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.

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.

[sguilhen]

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/trunk/acl/

Impl:
http://anonsvn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/trunk/acl/

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.