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 < [email protected]> 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 <[email protected]> >> >>> 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<[email protected]> 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 >>> >>>
