[jboss-dev-forums] [Design of Security on JBoss] - Bringing together an unified security view

anil.saldhana@jboss.com do-not-reply at jboss.com
Thu Oct 11 13:22:29 EDT 2007


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.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4094211#4094211

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4094211



More information about the jboss-dev-forums mailing list