Adam, There was a previous thread on the subject of implementing other "authentication and security" models to support OpenId, LDAP, and other custom authentication needs. The subject of the thread was "Alternatives to using UserLoginId as a primary key".
Here is a snippet of that thread from Jacopo. Does your implementation follow a similar approach to what Jacopo suggested? I'm asking because we need a custom authentication model to support unique user IDs across groups where the individual IDs may conflict. On Mon, Feb 20, 2012 at 5:59 AM, Jacopo Cappellato <jacopo.cappell...@hotwaxmedia.com> wrote: > I like Adrian's proposal to make the UserLogin entity more flexible. > Brett, as regards your proposal about the extension mechanism (i.e. the > UserCredentials), I think it would be better an approach where each specific > security implementation defines its own *Credentials (or *UserLogin or > *Authentication or some other name) entity as an extension to the UserLogin > for that authenticationTypeId (instead of attempting to define a general > purpose UserCredentials entity). > > For example, for a UserLogin record for LDAP (i.e. > authenticationTypeId="LDAP) we could have a corresponding record in the > LdapUserLogin record; for a UserLogin record for OpenId we could have a > corresponding record in the OpenIdUserLogin record etc... you could define > your own for the specific security you are working on. > > Kind regards, > > Jacopo > On Thu, Apr 19, 2012 at 9:26 AM, Adam Heath <doo...@brainfood.com> wrote: > I have a series of patches that enable ofbiz to be used as an openid > *provider*. I used this to allow a wordpress site to delegate > authentication to ofbiz(the company in question already had an ofbiz > deployment hooked into their internal ldap, with phone/name synching; > didn't want to duplicate all that). > > I do *not* yet have working openid client support. Should I wait > until I do(there is no client that has payed for that), or should I > commit what I already have? I need to verify it again first, but that > shouldn't take overly long. Thanks, Brett
