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< >> [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 >>>>> >>>>>
