There has been a private thread going on between Michael Neale and me over the usage of an appropriate authorization framework in Drools. I want to invite Michael to use this design thread to chalk out the details.
1) JBossSX is the security implementation in JBoss for the whole of the JEMS stack. It also includes a JACC layer.
2) An UI for defining roles can be part of your application.
3) You can do an lazy load of permissions, a role will have at the last minute. As long as you populate all the known permission types for your application in the PolicyConfiguration, just for the dispatch to the lazy permission collection.
Michael Neale wrote: > Yeah that thread kind of touches on what I want to do (but perhaps is dealing with a larger quantity of data, but more or less the same). > > So can I clarify a few things about JACC and JBossSX? Its all very confusing to me. > > * Is JbossSX an implementation of JACC (and more?) > * If I use JACC/JBossSX are the roles defined "outside" my application? Is there an API/UI to assign users to these roles? > * Is there an API/UI for assigning application specific permissions (to the above roles) ? > * Is there a database structure that stores these permission assignments? (does JBossSX provide this?) > * To confirm, the enforcement of the permission/permissioncollection is done by my application in some kind of interceptor layer yes? > > I am just trying to work out what is the resposibility of my app, versus the framework. > > Also, I have some constraints that my repository may be used in any container (and not even in a JEE container), not just JBoss AS. > > Thanks for your feedback. > > PS I have been talking with Sohil about what he is doing with ACLs in the portal, so perhaps he is already solving this? He was looking at what I did regarding persistence, and was doing to adapt it to the framework (which I would then retrofit into my app). > > Michael. > > From: Anil Saldhana > To: Michael Neale > > Hi Michael, > from what I understand, you should be able to use JACC. You can > always define the permissions a particular role will have and then you > can check the permissions from your application against the ones in the > PolicyConfiguration. > > There is a way to do lazy permission collection checks also that allows > a security check to be made lazily (eg: read the latest perms from the > DB). So maybe in the lazy perm check, you can create the perm group and > check against that. > > See this thread: > http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73586 > > Regards, > Anil
Hi Anil. > > Best is to look at the classes in: > > http://anonsvn.labs.jboss.com/trunk/labs/jbossrules/drools-repository/src/main/java/org/drools/repository/security/ > > Basically any object in the repository database that implements > ACLResource *can* optionally have permissions set to a group of users > (the groups, which I really shoudl rename to be roles) are application > specific, and store in the apps database. This is row level security. > > The user identity is passed in to the app from the container outside > (i guess the roles could to??) > > From what I have read about JACC and xacml is that policies can be > fine grained, but it doesn't quite seem that fine grained. For > instance, from the OASIS website, > > > /Scope/ > > XACML is expected to address fine grained control of authorized > activities, the effect of characteristics of the access requestor, the > protocol over which the request is made, authorization based on > classes of activities, and content introspection (i.e. authorization > based on both the requestor and potentially attribute values within > the target where the values of the attributes may not be known to the > policy writer). XACML is also expected to suggest a policy > authorization model to guide implementers of the authorization mechanism. > > The interesting part to me is "content introspection" where > authorization is based on attribute values. Now if it is "rule" based > stuff, say "you can see assets that are marked as 'HR' records, but > not 'FINANCE' etc" I can see that working, for sure. But then that is > pushing the authorisation basically on the content itself. Maybe I am > missing the point, but I thought really fine grained meant you > specified to the ACL exactly what resources are allowed to be touched > and how ... > > > > Ideas? Thoughts? Am I going down the wrong path? Should I move to > using policies that set rules of access rather then an ACL that > specifies individual records? (possibly.. thats a thought...) > > > > Michael. > > > > *From:* Anil Saldhana > *Sent:* Wed 1/02/2006 7:58 AM > *To:* Michael Neale > *Subject:* Re: ACL > > Hi Michael, > do you have some examples of your data related security that you talk > about? > > If I see some examples, then I can opine whether JBossSX will fit in. > > Regards, > Anil > > Michael Neale wrote: > > > Hi Anil. Our specific needs are really just for "data partitioning" > > type of security. I am not sure how JBossSX fits into that. From what > > I have seen of all the frameworks, they all fall short of providing a > > general solution to instance security (which is probably very hard to > > make general anyway, every app is slightly different in its data of > > course). > > > > Does this sort of instance/data security fit within the bounds of > > jbossSX from what you know? I can see that all the other stuff is > > still relevant, but the main problem we are trying to solve is > > instance security. > > > > MIchael. > > > > *From:* Anil Saldhana > > *Subject:* Re: ACL > > > > It basically depends on the location of your policy xml files as well as > > to what complexity is your "Policy Combining" Algorithms. > > > > My only request to all the project leads in search of a security > > solution, is to reuse the JBossSX layer as much as possible or suggest > > updates to it. Please run it with Scott, before embarking on a mission > > of your own. ;) > > > > If every project does its security in its own custom manner, with its > > own dependencies, then JEMS integration is ???