Jacopo, That sounds like a good approach. We'll look at an extension of the UserLogin entity with a specific type. Is the current LDAP implementation following that model or would this be something new?
Thanks, Brett 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 Feb 20, 2012, at 8:38 AM, Adrian Crum wrote: > > > As far as I know, there are two LDAP authentication implementations - > one that I worked on a while back that can be found in the framework, and a > CAS-LDAP one that can be found in specialpurpose. There is also a SSO > implementation and some X509 stuff. > > > > -Adrian > > > > On 2/20/2012 3:32 AM, Brett Palmer wrote: > >> Adrian, > >> > >> Yes, that approach would work for us as well. I like the generic > >> authentication approach which opens it up for OpenId, LDAP, and custom > >> authentication methods without changing how authorization in ofbiz is > >> performed. > >> > >> A you proposing that we refactor the UserLogin entity, removing the > custom > >> fields and introduce a new entity like UserCredentials? That would work > >> for us. We need to implement this type of solution for our application. > >> We would prefer a solution that would be adopted by the community as an > >> alternative login approach when needed. We would be happy to contribute > >> this solution back to the community. What else has already been done in > >> this area so we can avoid duplicating anyone's efforts or at least > continue > >> where they left off? > >> > >> We could create a proof of concept implementation and then post it to > the > >> community for review. We would like suggestions and feedback early so > we > >> can avoid large changes after the POC is complete. > >> > >> Let me know the best way to proceed with this effort. > >> > >> > >> Thanks, > >> > >> > >> Brett > >> > >> On Sun, Feb 19, 2012 at 2:30 AM, Adrian Crum< > >> adrian.c...@sandglass-software.com> wrote: > >> > >>> Brett, > >>> > >>> This opens up the possibility to solve another problem - supporting > >>> alternate authentication systems (like LDAP, etc). > >>> > >>> Right now the userLogin entity includes OFBiz credentials (login name, > >>> password), LDAP credentials (DN), and some other credentials that > Andrew > >>> added. From my perspective, it might be best to use the UserLogin > entity > >>> only for persisting a user, and have the credentials stored in another > >>> entity. The UserLogin entity could then support any number of > >>> authentication schemes: > >>> > >>> UserCredentials > >>> --------------- > >>> > >>> userLoginId* > >>> authenticationTypeId* > >>> fromDate* > >>> thruDate > >>> loginName > >>> password > >>> > >>> Would something like that solve your problem? > >>> > >>> -Adrian > >>> > >>> > >>> On 2/19/2012 6:51 AM, Brett Palmer wrote: > >>> > >>>> Sakthi, > >>>> > >>>> Thanks for the quick reply. The system generated UserIds would not be > >>>> visible to the user. They would just be used by the system to use > ofbiz > >>>> existing authentication and security features. > >>>> > >>>> Our application is not a typical ecommerce app but one that is used by > >>>> students and teachers for testing. The students are suppose to use > their > >>>> personal userID assigned to them but these are often not remembered > and so > >>>> errors occur. > >>>> > >>>> Here is what I am proposing for our solution: > >>>> > >>>> > >>>> 1. Add new fields to the UserLoginId table that will allow us to > determine > >>>> uniqueness within their particular organization. For example, a > district > >>>> ID and a studentID. > >>>> > >>>> 2. Create custom authentication method to handle the de-references of > the > >>>> student's studentId and districtId to determine the actual system Id. > >>>> > >>>> 3. Verify the password matches the one in the UserLogin table. > >>>> > >>>> 5. Get the UserLogin GenericValue and store in a session so ofbiz > >>>> authentication and security features work. > >>>> > >>>> > >>>> Now when a person calls to say their userId was incorrectly entered > we can > >>>> quickly update their UserId because the ID the student uses is not the > >>>> primary key. > >>>> > >>>> > >>>> Let me know if anyone sees anything wrong with this approach. > >>>> > >>>> > >>>> > >>>> Brett > >>>> > >>>> On Fri, Feb 17, 2012 at 5:57 AM, Integrin > Solutions<info.integrin@gmail.* > >>>> *com<info.integ...@gmail.com> > >>>> > >>>>> wrote: > >>>>> Brett - > >>>>> My thoughts - > >>>>> - System generated UserIds might be hard for the users to remember; > >>>>> - Changing UsersIds of a Person is not that difficult afterall; You > >>>>> might want to assign a new UserId to the User<from PartyManager> > and > >>>>> disable the existing one; > >>>>> > >>>>> - Sakthi > >>>>> > >>>>> On 2/17/12, Brett Palmer<brettgpal...@gmail.com> wrote: > >>>>> > >>>>>> We have an application based on the ofbiz framework for online > testing. > >>>>>> > >>>>> We > >>>>> > >>>>>> use the ofbiz user authentication and userLoginId as designed by > ofbiz. > >>>>>> The problem is that often teachers and students incorrectly > register in > >>>>>> the system with a specific userId. Then they call up and want to > change > >>>>>> their userId because it doesn't match their actual ID. It is > difficult > >>>>>> > >>>>> to > >>>>> > >>>>>> change the userLoginId for a person once it has been assigned to a > >>>>>> > >>>>> person. > >>>>> > >>>>>> We would like the UserLoginId to work similarly to how the PartyId > >>>>>> works. > >>>>>> PartyId is a system generated ID that is assigned to a Person, > >>>>>> > >>>>> PartyGroup, > >>>>> > >>>>>> etc. As a system generated ID it gives us a lot of flexibility in > how > >>>>>> it > >>>>>> is used. It also allow us to make changes easily like changing a > >>>>>> > >>>>> person's > >>>>> > >>>>>> name, etc. > >>>>>> > >>>>>> A few months ago there was some discussion in the forums about > >>>>>> > >>>>> alternative > >>>>> > >>>>>> to how UserLoginId is used in the system. Has anyone come up with > an > >>>>>> alternative to the default implementation of UserLoginId. > >>>>>> > >>>>>> Thanks in advance for your suggestions. > >>>>>> > >>>>>> > >>>>>> Brett > >>>>>> > >>>>>> -- > >>>>> Sent from my mobile device > >>>>> > >>>>> > >
