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.