12:22 p.m.
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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...