On Tuesday 09 January 2007 09:12, Andrew Zeneski wrote: > Thinking about this a little more maybe we should consider breaking > this down into two independent interfaces: > > org.ofbiz.security.AuthenticationHandler > org.ofbiz.security.PermissionHandler
At this point I would like to pop in with a very basic criticism. I've always been a little confused by the use of user credentials as opposed to parties and, especially, the fact that the userLoginId is the primary key of the credentials. I can see why you want to track which credential was used to perform a particular action and I can also see the argument that the whole party management app shouldn't always be a requirement for an OFBiz install. What doesn't make sense is that I can't do very basic things like have several different authentication schemes (ie: LDAP, SMB, Radius, Kerberos) attached to the same party with the same or varying userLoginId and same or different passwords or other shared secrets. Its also very vexing that I can't have duplicate userLoginIds for different parties in different authentication contexts (ie. multihomed multicontext ecommerce widget or whatever). I really would like to see userLogins separated by some sort of "realm" and having their own IDs that are not the user identifier and potentially even their own tables if the shared secret is complex (ie. retina print or somethign). The base table could also specify an authenticating service call (service engine style) on a per credential basis (with a default?). It would be very nice, for instance, to integrate JPAM so that you could authenticate your ofbiz users off of your Samba server and handle password changes through it and so forth. I'm thinking out loud a little here, obviously. -- Ean Schuessler, CTO [EMAIL PROTECTED] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
