If we are talking about the trunk and there are no objections or better ideas I would be in favor of refactoring the existing security implementation to use the new model.
Regards, Jacopo On Feb 21, 2012, at 2:18 AM, Brett Palmer wrote: > 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 < > [email protected]> 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< >>>> [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 >>>>>>> >>>>>>> >> >>
