Alternatives to using UserLoginId as a primary key

[Brett]

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

[Sakthivel Vellingiri]

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

[Brett]

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

[Adrian Crum-3]

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

[Brett]

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

[Adrian Crum-3]

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

[Jacopo Cappellato-4]

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

[Adrian Crum-3]

Thanks Jacopo - that is a great plan.

-Adrian

On 2/20/2012 12:59 PM, Jacopo Cappellato 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<
>>> [hidden email]>   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<[hidden email]>
>>>>>
>>>>>> 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<[hidden email]>    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
>>>>>>
>>>>>>

[Brett]

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

[Jacopo Cappellato-4]

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