Bringing together an unified security view

[anil.saldhana]

Chat with Mark Proctor.

(11:36:25 AM) conan: anil: I have two concerns really.
(11:36:50 AM) conan: 1) is we are already using seam for identity
(11:37:24 AM) conan: 2) we need instance based ACL, fast enough to provide object filtering on table views. my email to the groups summarized the features, all standard stuff really.
(11:37:37 AM) conan: what we don't want is a mismatch of two security frameworks
(11:37:47 AM) anil: understand the concern
(11:37:48 AM) conan: so it seems lke we have two things to solve
(11:37:56 AM) conan: get a fast ACL impl
(11:38:09 AM) conan: maybe xacml can be made to do this, I don't know.....
(11:38:20 AM) conan: but certainly not the RI that sun provide.
(11:38:35 AM) conan: the other is figure out how to bring the AS security and the Seam security teams closer together.
(11:38:47 AM) conan: you guys should be re-developing the wheel.
(11:38:55 AM) conan: even if it means seam is wrapping your stuff
(11:39:02 AM) conan: or is that what they do already?
(11:39:43 AM) conan: shane, seam team, has said he'll put time into this if he is supported. he can also work to make their security stuff standalone.
(11:39:51 AM) anil: My take between ====== lines (two of them)
(11:39:54 AM) anil: =================================
(11:40:35 AM) anil: 1) Seam should be using JBoss Security ( we are supposed to be generic). We currently sprouted out the AS of course. So still reeling under all the AS things (backwards compatibility and other blah blah)
(11:41:19 AM) anil: 2) We have a generic authz framework. I am thinking a drools based implementation would solve the ACL thing). Seam already is using it. So if we provide a rules based impl. Seam (and you) can use JBsec
(11:41:22 AM) anil: =================
(11:42:05 AM) conan: anil: no it can't be drools based.
(11:42:24 AM) conan: drools has to be loaded fully on each restart
(11:42:34 AM) conan: so on large ACLs that is gonna increase overhead time
(11:42:50 AM) conan: needs to just be a simple hibernate solution with good use of caching
(11:43:07 AM) conan: the seam ACL is execution permissions
(11:43:14 AM) conan: not ACL instance based access permissions
(11:43:24 AM) conan: they currently have no offering for this
(11:43:30 AM) conan: nor for strong group/roles support
(11:45:45 AM) anil: Mark, sorry for this. Can u give some examples of instance based access perms from rules perspective.
(11:46:18 AM) conan: forget rules
(11:46:21 AM) conan: this is nothign to do with rules
(11:46:35 AM) anil: I mean drools as a project
(11:46:37 AM) conan: its about ACL CRUD permissions on a Resource
(11:46:41 AM) conan: ok we have the BRMS
(11:46:48 AM) conan: the BRMs contains assets
(11:46:53 AM) conan: each item is an asset
(11:46:59 AM) conan: a drl, a ruleflow, a jar.
(11:47:14 AM) conan: users, like on a file system, have CRUD access to those assets.
(11:47:26 AM) conan: so lets say there are 500 drls
(11:47:49 AM) conan: and the user says "show me all drls" he might now have permissions to see all 500, so the ACL system's R permission would filter that view.
(11:48:05 AM) conan: he may try and create a new drl, again the ACL would check his C permissions.
(11:48:14 AM) conan: of U to update an asset
(11:48:45 AM) conan: so in reality think of the BRMS as just a storage system for files that have the same operations on them as on a file system
(11:49:15 AM) anil: I am getting to understand the problem.
(11:49:41 AM) conan: its just standard instance based ACL really
(11:49:44 AM) conan: not much to it
(11:49:54 AM) anil: right.
(11:49:57 AM) conan: the main thing to consider is what do you consider a "Resource"
(11:50:03 AM) conan: a Resource is something you apply ACLs too
(11:50:06 AM) anil: that is domain specific
(11:50:09 AM) conan: how do you identify that Resource
(11:50:10 AM) anil: I mean resource
(11:50:11 AM) conan: yes exactly
(11:50:37 AM) conan: so the user when trying to authorize on a resource would probably have to provide some sort of component mapping class
(11:50:52 AM) conan: something that translates our Asset into your Resource
(11:51:17 AM) conan: as a users object may be uniquely identified by URI, URL, long, UUID or composite key
(11:51:29 AM) conan: this is teh same thing that hibernate solves already, user provided primary keys
(11:51:59 AM) conan: thats the only bit that is different really and needs to be got right
(11:52:09 AM) conan: if thats done right, then all systems should be able to use it.
(11:52:12 AM) anil: Mind if I copy paste this discussion into some place later.
(11:52:16 AM) conan: sure
(11:52:37 AM) conan: now the other thing is we need an API for user/group/rule management.
(11:52:44 AM) conan: you have the enterprise view where everything is in LDAP
(11:52:52 AM) conan: and in general end users are never allowed to touch that
(11:53:11 AM) conan: but there are other requirements where deparatemetns need control of this and just want to install something locally.
(11:53:39 AM) conan: so whether the user(identity), groups and rules is LDAP or hibernate it needs to be abstracted from our system. so we can build an integrated gui for the management of this.
(11:53:56 AM) anil: think portal, jbpm have the same need
(11:54:06 AM) anil: this so called Identity component
(11:54:20 AM) conan: yes in general you don't want people going to a different system to managers users, groups and roles.
(11:54:27 AM) anil: true
(11:54:31 AM) anil: ldap or hibernate
(11:54:34 AM) conan: even if all teh systems map to the same store and the store provides its own GUI
(11:54:46 AM) conan: so yes you might end up with three GUIs doing the same thing
(11:54:49 AM) conan: but thats acceptable
(11:54:58 AM) conan: as long a they use the same api and same storage
(11:56:12 AM) anil: Mark, I know this acl thing has been a burning issue for u for sometime. Did anything turn out of the jcr standardization?
(11:58:23 AM) conan: nope
(11:58:31 AM) conan: as you know we discuss this almost 2 years ago
(11:58:39 AM) conan: and we where basically putting our security on hold
(11:58:51 AM) conan: hoping that JCR would solve this or JBoss would, or both.
(11:58:53 AM) conan: neither have
(11:59:51 AM) conan: see gavin's reply
(11:59:53 AM) conan: I see his point
(11:59:59 AM) conan: I wonder if there is any compromise
(12:00:08 PM) conan: in that ultimately seam is doing the same thing as jboss security
(12:00:15 PM) conan: just simplifying it and providing out of the box integration
(12:00:21 PM) conan: wonder if it could atleast wrap what you have
(12:00:34 PM) conan: in an idea world this would happen
(12:00:51 PM) conan: jboss security would develop a good ACL solution, or make XACML fast and usable.
(12:01:16 PM) conan: seam would then wrap/brdige this, likewise anything else that seam overlaps with on the jboss securtiy project.
(12:01:21 PM) conan: seam security also becomes standalone.
(12:01:43 PM) conan: basically becoming a unifying wrapper and simplifier for integration
(12:03:07 PM) anil: two things needs to be done - Fine Grained Authorization that needs to be performant and Identity Component
(12:03:17 PM) conan: yes
(12:03:27 PM) conan: basically OSAccess and OSUser
(12:03:33 PM) conan: those are two old projects taht tried to solve this problem.
(12:03:45 PM) conan: I tried to do a rewrite once, think the code is around somewhere.
(12:03:49 PM) conan: but not an easy thing to solve.
(12:04:02 PM) anil: would JDK5 be a decent requirement?
(12:04:04 PM) conan: nested groups and roles is very hard to get right performance wise.
(12:04:08 PM) conan: yes
(12:04:12 PM) conan: no need to support jdk1.4
(12:04:15 PM) conan: we've just shed that now
(12:05:11 PM) anil: Mark, I think I have the requirements now. I will draft something and send across. I will look at what Shane has and see if we can do whatever needs to be done such that JBS becomes the reference

Mark is basically requesting an unified API/Implementation for a fast ACL implementation that Drools and Seam require. He also mentions the need for an Identity Component that Drools, Seam, jBPM and Portal need.

[mark.proctor]

(11:38:47 AM) conan: you guys should be re-developing the wheel.
Should NOT be re-developing the wheel.

[mark.proctor]

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

[anil.saldhana]

Instance Based ACL Implementation
I talked to Scott about Seam Security and the instance based security that is important for Non-AS projects like Drools, Portal, jBPM and Seam.


There are two prominent projects that have tried to solve instance based security:

1) OSAccess from OpenSymphony [1] through [3] (A dead project now)
2) Acegi Security for Spring [4]

I also point you to an article on IBM Developer Works for differences between container authorization (typically RBAC) and Data Driven Authorization (Instance Based).

What we will provide:
A simple library that does a mapping between roles structure (groups, nested roles etc) and instance based crud (bits representing CRUD). The key here is to keep it simple and fast. The library can have pluggable implementation strategies like hibernate, ldap, cache whatever.

Integration for Drools, jBPM, Portal etc:
Scott feels that they should integrate via Seam (same opinion from Proctor) because Seam is AS agnostic. They can integrate with JBoss Security to play nice with JBAS. Seam can then make use of the ACL implementation to provide other integration faces to different containers (WS, WL etc).

References:
OSAccess
[1] http://wiki.opensymphony.com/display/OS/OSAccess
[2] https://osaccess.dev.java.net/
[3]http://osdir.com/ml/java.open-symphony.devel/2002-07/msg00035.html (Note: Steve Ebersole in the mail)

Acegi Security For Spring
[4] http://www.acegisecurity.org/acegi-security/apidocs/index.html
Look at the packages: org.acegisecurity.acl, org.acegisecurity.acls and their subpackages

Authorization Concepts and Solutions for J2EE Applications
[5]http://www.ibm.com/developerworks/websphere/library/techarticles/0607_ilechko/0607_ilechko.html

[julien1]

Some important points for portal (and maybe for others too) is the capability to query several domains and get descriptions

- existing resources that are secured and that could be secured
- existing actions
- relationship between actions
- capability to test security for a specified subject and not something based on thread local

The bottom line is that we not only need to be able to do checks, we also need to be able to do runtime configuration of various aspects and build complete GUI for it.

[julien1]

I understand that Seam can be leveraged for integrating software nicely, but it should not be a requirement for using it.

Instance Based ACL Implementation
I talked to Scott about Seam Security and the instance based security that is important for Non-AS projects like Drools, Portal, jBPM and Seam.


There are two prominent projects that have tried to solve instance based security:

1) OSAccess from OpenSymphony [1] through [3] (A dead project now)
2) Acegi Security for Spring [4]

I also point you to an article on IBM Developer Works for differences between container authorization (typically RBAC) and Data Driven Authorization (Instance Based).

What we will provide:
A simple library that does a mapping between roles structure (groups, nested roles etc) and instance based crud (bits representing CRUD). The key here is to keep it simple and fast. The library can have pluggable implementation strategies like hibernate, ldap, cache whatever.

Integration for Drools, jBPM, Portal etc:
Scott feels that they should integrate via Seam (same opinion from Proctor) because Seam is AS agnostic. They can integrate with JBoss Security to play nice with JBAS. Seam can then make use of the ACL implementation to provide other integration faces to different containers (WS, WL etc).

References:
OSAccess
[1] http://wiki.opensymphony.com/display/OS/OSAccess
[2] https://osaccess.dev.java.net/
[3]http://osdir.com/ml/java.open-symphony.devel/2002-07/msg00035.html (Note: Steve Ebersole in the mail)

Acegi Security For Spring
[4] http://www.acegisecurity.org/acegi-security/apidocs/index.html
Look at the packages: org.acegisecurity.acl, org.acegisecurity.acls and their subpackages

Authorization Concepts and Solutions for J2EE Applications
[5]http://www.ibm.com/developerworks/websphere/library/techarticles/0607_ilechko/0607_ilechko.html

[tom.baeyens]

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.

Portal defines a session facade interface that provides access to users and group objects. Those objects themselves don't expose relation getters. Instead, the session facade contains the methods for traversing the relations.

The motivation for the ession facade approach is to have different implementations. One for DB with hibernate, one for LDAP and so on.


From jBPM perspective, what I would like is for the shared identity component to look like this:

* a set of java classes with getters and setters also for the relation properties.

* hibernate persistence for those classes

* JSF UI components as building blocks to create a identity management console.

Then portal can still leverage such a component as 1 implementation (the DB/hibernate impl) of their own identity abstraction interfaces.

I don't think it is feasible in the short term to come up with an interface that suits all requirements and that can switch between DB, LDAP and maybe other stores like e.g. XML files. But I do think it is feasible to create 1 implementation of a DB-schema/Java objects/hibernate mappings that everyone can leverage, leaving the abstraction interfaces still to the individual projects.

E.g. in our case, those abstraction interfaces are on a per-use-case basis: an assignment handler for assigning a task to a user or a set of candidates. and an email address resolver that converts user ids into email adresses.

[tom.baeyens]

I understand that Seam can be leveraged for integrating software nicely, but it should not be a requirement for using it.

+1. seam should not be required to leverage the shared identity component.

[soshah]

tom-

what you are talking about at this point is the Identity Management Framework. As far as the ACL component is concerned (topic of discussion in this thread), it should be Identity Management Framework agnostic with ability to plugin different Identity Management implementations.

Thanks

[anil.saldhana]

Seam provides the AS agnostic view that you projects need. JBoss Security is primarily targeted towards the JBoss AS, because that is where our expertise and resources are.

[julien1]

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.

Portal defines a session facade interface that provides access to users and group objects. Those objects themselves don't expose relation getters. Instead, the session facade contains the methods for traversing the relations.

The motivation for the ession facade approach is to have different implementations. One for DB with hibernate, one for LDAP and so on.


From jBPM perspective, what I would like is for the shared identity component to look like this:

* a set of java classes with getters and setters also for the relation properties.

* hibernate persistence for those classes

* JSF UI components as building blocks to create a identity management console.

Then portal can still leverage such a component as 1 implementation (the DB/hibernate impl) of their own identity abstraction interfaces.

I don't think it is feasible in the short term to come up with an interface that suits all requirements and that can switch between DB, LDAP and maybe other stores like e.g. XML files. But I do think it is feasible to create 1 implementation of a DB-schema/Java objects/hibernate mappings that everyone can leverage, leaving the abstraction interfaces still to the individual projects.

E.g. in our case, those abstraction interfaces are on a per-use-case basis: an assignment handler for assigning a task to a user or a set of candidates. and an email address resolver that converts user ids into email adresses.

[julien1]

it looks like Seam would be about "how to apply/integration authorization with different frameworks".

please leave this as an implementation detail of the framework consumer.

Seam provides the AS agnostic view that you projects need. JBoss Security is primarily targeted towards the JBoss AS, because that is where our expertise and resources are.

[bdaw]

Portal identity model will be redesigned (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112843). Sohil pointed right that we should focus on common ACL solution that will work with any IdM framework. I'm sure it wouldn't be possible to agree on common set of identity POJOs....

[tom.baeyens]

tom-

what you are talking about at this point is the Identity Management Framework. As far as the ACL component is concerned (topic of discussion in this thread), it should be Identity Management Framework agnostic with ability to plugin different Identity Management implementations.

Thanks

if i understand you correctly, that is exactly the opposite of what I'm trying to promote.

i think we can build 1 implementation so that all the projects can leverage it as an implementation for project specific identity interfaces.

that way, in the platforms, it would be possible to configure all the components to use 1 and the same component implementation.

at a minimum, a database schema has to be defined so that we all can work with a single DB repository. And IMO, a set of POJO's+hibernate mappings should accompany the common identity database schema.

[julien1]

I don't understand why you want so hard to mutualize a set of POJOs + an hibernate configuration. It's trivial software to write.

In portal world, a lot of things are done rather around LDAP and database is a good default option (for out of the box).

tom-

what you are talking about at this point is the Identity Management Framework. As far as the ACL component is concerned (topic of discussion in this thread), it should be Identity Management Framework agnostic with ability to plugin different Identity Management implementations.

Thanks

if i understand you correctly, that is exactly the opposite of what I'm trying to promote.

i think we can build 1 implementation so that all the projects can leverage it as an implementation for project specific identity interfaces.

that way, in the platforms, it would be possible to configure all the components to use 1 and the same component implementation.

at a minimum, a database schema has to be defined so that we all can work with a single DB repository. And IMO, a set of POJO's+hibernate mappings should accompany the common identity database schema.