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