You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Torsten Schlabach <ts...@gmx.net> on 2007/03/01 00:06:39 UTC
Re: Storing and retrieving users and passwords from LDAP
Change or provide an alternative implementation?
If I did either one, would you commit it?
I mean, would that be a "clean" solution?
David E. Jones schrieb:
>
> Rather than trying to do this through the entity engine it might be
> better/easier to just change the userLogin service to look at both
> sources, and manage conflicts as desired, etc.
>
> -David
>
>
> On Feb 28, 2007, at 11:29 AM, Torsten Schlabach wrote:
>
>> Hi!
>>
>> I think I am about to find my way through OFBiz internals, so
>> basically I am just asking for confirmation and some little hints.
>>
>> What I am trying to do is to read users and their passwords not from
>> the embedded Derby database but from a given LDAP directory.
>>
>> I have taken a look at org.ofbiz.common.login.LoginServices. From
>> there I find out that it's using a delegator to retrieve the username
>> and corresponding password through the entity engine.
>>
>> Am I right that I would have to configure the entity engine in a way
>> that it keeps retrieving anything else from where it does today, but
>> that I would have to tell it to use a different datasource for the
>> entity UserLogin?
>>
>> I haven't found that specific place yet, but hopefully that shouldn't
>> be that difficult.
>>
>> But browsing pre-defined datasources in entityengine.xml, I did not
>> find anything which looked like LDAP to me. So I wonder: Are
>> delegators tied to SQL databases and JDBC? Or to something which has
>> to have a relational structure? (LDAP can be mapped into a relational
>> structure, but as we know, it's not relational by default.)
>>
>> Would I have to code a new implementation of a Delegator to talk to
>> an LDAP server? Or would there be a way to achieve this just through
>> configuration?
>>
>> Also I haven't yet found the place where datasources, delegators and
>> entities are connected.
>>
>> Can this be done at all at reasonable effort?
>>
>> I am thinking of implementing my own replacement for LoginServices as
>> an alternative. That would for example allow to check for container
>> based authentication (getUserPrincial()). But that would just manage
>> logins. I would loose the chance to create new users through OFBiz,
>> wouldn't I?
>>
>> Any comments or pointers to specific documents are welcome.
>>
>> Regards,
>> Torsten
>
>
Re: Storing and retrieving users and passwords from LDAP
Posted by Amine AZZI <ba...@gmail.com>.
Hi Torsten,
Happy that my work helped to make a more suitable work. Thank you also for
enhancing the job.
Amine.
2007/7/14, Torsten Schlabach <ts...@gmx.net>:
>
> Hi Amine,
>
> thank you for your help. I was able to make this work, and I have spent
> some extra time to create a version which uses JDNI (as included in the
> JDK) and therefore does not need any extra lib and does not have any
> license issues. I have attched my version to the JIRA issue.
>
> Adrian still would like to see the code organized differently for
> inclusion. I am not sure when I will find time, so I at least wanted to
> make sure I will share this interim solution, especially as you need to
> build that Netscape LDAP lib from source which can be a bit cumbersome.
>
> I have also removed the need for ldap.user and ldap.password. I just use
> the credentials supplied by the user to try and bind to LDAP. There is
> no need for the OFBiz app to know the credentials of some overall LDAP
> tree superuser. Putting this in the OFBiz config is nothing but a
> security risk IMO.
>
> Some more words of caution to everyone who might want to use apply this
> patch:
>
> 1. This is an all-or-nothing solution. If you set login.useLDAP=true
> *all* user's passwords are checked against LDAP. There is no fallback in
> either direction, e.g. if the user is not found in LDAP, use the
> database or vice versa. An optimal solution might be to give a user's
> record an extra field "external auth" or something like that which would
> point to an external authentication object, which might be an LDAP
> object. (Take a look at Oracle's "IDENTIFIED BY" for example.) Besides
> LDAP, we might also be looking at SSO solutions in the future, for
> example.
>
> 2. With the given implementation, all LDAP user objects need to be in a
> single LDAP context, determined by ldap.baseDN. There is no sub-tree
> searching for user objects. If in practice you would be looking at
> keeping admins in a different part of the tree or even in a different
> directory as normal users, that "external auth" field would be a
> solution for that, again, if it would contain the full URL of the object
> in LDAP.
>
> Anyway, hopefully this patch is useful. Thanks again, Amine, for
> providing the basic work here.
>
> Regards,
> Torsten
>
>
> Amine AZZI schrieb:
> > Hi Torsten,
> >
> > I posted a jira issue with svn patches for the same work on
> >
> > https://issues.apache.org/jira/browse/OFBIZ-811
> >
> > I hope this would help you. Of course there some work to do to have it
> on
> > Ofbiz,
> >
> > Amine.
> >
> > 2007/7/14, Torsten Schlabach <ts...@gmx.net>:
> >
> >>
> >> Hi Amine!
> >>
> >> It has been a long time ago since you sent me this, but now I am
> >> revisiting the topic.
> >>
> >> > I send you the patch here (it concerns a CVS diff unfortunaltely but
> >> > it's so basic that you can reproduce it).
> >>
> >> Well, no, sorry, but not at all. I was able to extract the
> >>
> >> userLoginLdap(DispatchContext ctx, Map context)
> >>
> >> function from your patch and planted it into LoginServices.java, but I
> >> have no idea where to put the rest.
> >>
> >> I took a look at the original
> >>
> >> public static Map userLogin(DispatchContext ctx, Map context)
> >>
> >> function and it's so damn complex.
> >>
> >> The actual password checking is obviously done here:
> >>
> >> // if the password.accept.encrypted.and.plain property
> >> // in security is set to true allow plain or encrypted
> >> // passwords
> >> // if this is a system account don't bother checking the
> >> // passwords
> >> if ((userLogin.get("currentPassword") != null &&
> >> (realPassword.equals(userLogin.getString("currentPassword")) ||
> >> ("true".equals(UtilProperties.getPropertyValue("security.properties",
> >> "password.accept.encrypted.and.plain")) &&
> >> password.equals(userLogin.getString("currentPassword")))))) {
> >> Debug.logVerbose("[LoginServices.userLogin
> ]
> >> : Password Matched", module);
> >>
> >> I am especially confused by the comment:
> >>
> >> // if this is a system account don't bother checking the
> >> // passwords
> >>
> >> but it's done anyway.
> >>
> >> How can I make sure that system accounts still work after I switched on
> >>
> >> login.useLDAP=true
> >>
> >> Any help would be appreciated.
> >>
> >> Regards,
> >> Torsten
> >>
> >>
> >>
> >> Amine AZZI schrieb:
> >> > Hello Torsten,
> >> >
> >> > I fell in the same problem. what I did if the integration of an ldap
> >> API
> >> > and
> >> > added a method to LoginServices, and to security.properties
> >> > I send you the patch here (it concerns a CVS diff unfortunaltely but
> >> > it's so
> >> > basic that you can reproduce it).
> >> > The API integrated is the one of Mozzila LDAP
> >> > The use is very easy, you set useLDAP to true to use the parametrized
> >> ldap
> >> > server, otherwise the party module is used to do authentification.
> >> >
> >> > The privileges configuration remains in Party Management module
> >> >
> >> >
> >> > Amine.
> >> >
> >> > Index:
> ./securityext/src/org/ofbiz/securityext/login/LoginServices.java
> >> > ===================================================================
> >> > RCS file:
> >> >
> >>
> /cvsroot/neogia/ofbizNeogia/applications/securityext/src/org/ofbiz/securityext/login/Attic/LoginServices.java,v
> >>
> >> >
> >> > retrieving revision 1.1.1.4
> >> > diff -r1.1.1.4 LoginServices.java
> >> > 27a28,30
> >> >
> >> >> import netscape.ldap.LDAPConnection;
> >> >> import netscape.ldap.LDAPException;
> >> >>
> >> > 147c150,162
> >> > <
> >> > ---
> >> >
> >> >>
> >> >> //this is useful in case someone wants to
> have
> >> an
> >> >
> >> > ldap authentification
> >> >
> >> >> //it also requires that use create
> connections
> >> on
> >> >
> >> > the party manager
> >> >
> >> >> boolean useLdap = "true".equals(
> >> >
> >> > UtilProperties.getPropertyValue("security.properties", "login.useLDAP
> >> "));
> >> >
> >> >> boolean validPass = false;
> >> >> if (!useLdap) {
> >> >> validPass = (userLogin.get
> >> ("currentPassword")
> >> >
> >> > != null &&
> >> >
> >> >> (realPassword.equals(
> >> >
> >> > userLogin.getString("currentPassword")) ||
> >> >
> >> >> ("true".equals(
> >> >
> >> > UtilProperties.getPropertyValue("security.properties", "
> >> > password.accept.encrypted.and.plain")) && password.equals(
> >> > userLogin.getString("currentPassword")))));
> >> >
> >> >> } else {
> >> >> validPass = userLoginLdap(ctx, context);
> >> >> }
> >> >>
> >> > 150,152c165
> >> > < if ((userLogin.get("currentPassword") !=
> null
> >> &&
> >> > <
> >> > (realPassword.equals(userLogin.getString("currentPassword"))
> >> > ||
> >> > < ("true".equals(
> >> > UtilProperties.getPropertyValue("security.properties", "
> >> > password.accept.encrypted.and.plain")) && password.equals(
> >> > userLogin.getString("currentPassword")))))) {
> >> > ---
> >> >
> >> >> if (validPass) {
> >> >
> >> > 769a783,811
> >> >
> >> >>
> >> >> private static boolean userLoginLdap(DispatchContext ctx, Map
> >> >> context)
> >> >
> >> > {
> >> >
> >> >>
> >> >> String host =
> >> >> UtilProperties.getPropertyValue("security.properties",
> >> >
> >> > "ldap.host.name");
> >> >
> >> >> int port = Integer.parseInt(UtilProperties.getPropertyValue
> ("
> >> >
> >> > security.properties", "ldap.host.port"));
> >> >
> >> >> int protocol =
> >> Integer.parseInt(UtilProperties.getPropertyValue
> >> ("
> >> >
> >> > security.properties", "ldap.protocol"));;
> >> >
> >> >>
> >> >> String baseDN = UtilProperties.getPropertyValue("
> >> >
> >> > security.properties", "ldap.baseDN");
> >> >
> >> >> String ldapUser = UtilProperties.getPropertyValue("
> >> >
> >> > security.properties", "ldap.user");
> >> >
> >> >> String ldapPassword = UtilProperties.getPropertyValue("
> >> >
> >> > security.properties", "ldap.password");
> >> >
> >> >>
> >> >> String username = (String) context.get("login.username");
> >> >> if (username == null) username = (String)
> >> >> context.get("username");
> >> >> String password = (String) context.get("login.password");
> >> >> if (password == null) password = (String)
> >> >> context.get("password");
> >> >>
> >> >> LDAPConnection conn = new LDAPConnection();
> >> >> try {
> >> >> conn.connect(host, port, ldapUser, ldapPassword);
> >> >> conn.authenticate(protocol, username, password);
> >> >> } catch ( LDAPException e ) {
> >> >> Debug.logVerbose("Error number: " +
> >> e.getLDAPResultCode(),
> >> >
> >> > module) ;
> >> >
> >> >> break;
> >> >> }
> >> >> return false;
> >> >> }
> >> >>
> >> >> return true;
> >> >> }
> >> >
> >> > Index: ./security/config/security.properties
> >> > ===================================================================
> >> > RCS file:
> >> >
> >>
> /cvsroot/neogia/ofbizNeogia/framework/security/config/security.properties,v
> >>
> >> > retrieving revision 1.1.1.3
> >> > diff -r1.1.1.3 security.properties
> >> > 53a54,64
> >> >
> >> >>
> >> >> # --ldap parameters
> >> >>
> >> >> ldap.host.name=ldapSrv
> >> >> ldap.host.port=389
> >> >> ldap.baseDN=dc=neogia,dc=org
> >> >> ldap.protocol=3
> >> >> ldap.user=cn=myUserid,ou=Myou,ou=MyOU2,dc=neogia,dc=org
> >> >> ldap.password=myPass
> >> >> login.useLDAP=false
> >> >>
> >> >
> >> >
> >> > 2007/3/1, Torsten Schlabach <ts...@gmx.net>:
> >> >
> >> >>
> >> >> Change or provide an alternative implementation?
> >> >>
> >> >> If I did either one, would you commit it?
> >> >>
> >> >> I mean, would that be a "clean" solution?
> >> >>
> >> >> David E. Jones schrieb:
> >> >> >
> >> >> > Rather than trying to do this through the entity engine it might
> be
> >> >> > better/easier to just change the userLogin service to look at both
> >> >> > sources, and manage conflicts as desired, etc.
> >> >> >
> >> >> > -David
> >> >> >
> >> >> >
> >> >> > On Feb 28, 2007, at 11:29 AM, Torsten Schlabach wrote:
> >> >> >
> >> >> >> Hi!
> >> >> >>
> >> >> >> I think I am about to find my way through OFBiz internals, so
> >> >> >> basically I am just asking for confirmation and some little
> hints.
> >> >> >>
> >> >> >> What I am trying to do is to read users and their passwords
> >> not from
> >> >> >> the embedded Derby database but from a given LDAP directory.
> >> >> >>
> >> >> >> I have taken a look at org.ofbiz.common.login.LoginServices. From
> >> >> >> there I find out that it's using a delegator to retrieve
> >> the username
> >> >> >> and corresponding password through the entity engine.
> >> >> >>
> >> >> >> Am I right that I would have to configure the entity engine in
> >> a way
> >> >> >> that it keeps retrieving anything else from where it does today,
> >> but
> >> >> >> that I would have to tell it to use a different datasource for
> the
> >> >> >> entity UserLogin?
> >> >> >>
> >> >> >> I haven't found that specific place yet, but hopefully
> >> that shouldn't
> >> >> >> be that difficult.
> >> >> >>
> >> >> >> But browsing pre-defined datasources in entityengine.xml, I did
> not
> >> >> >> find anything which looked like LDAP to me. So I wonder: Are
> >> >> >> delegators tied to SQL databases and JDBC? Or to something
> >> which has
> >> >> >> to have a relational structure? (LDAP can be mapped into
> >> a relational
> >> >> >> structure, but as we know, it's not relational by default.)
> >> >> >>
> >> >> >> Would I have to code a new implementation of a Delegator to talk
> to
> >> >> >> an LDAP server? Or would there be a way to achieve this
> >> just through
> >> >> >> configuration?
> >> >> >>
> >> >> >> Also I haven't yet found the place where datasources,
> >> delegators and
> >> >> >> entities are connected.
> >> >> >>
> >> >> >> Can this be done at all at reasonable effort?
> >> >> >>
> >> >> >> I am thinking of implementing my own replacement for
> >> LoginServices as
> >> >> >> an alternative. That would for example allow to check for
> >> container
> >> >> >> based authentication (getUserPrincial()). But that would just
> >> manage
> >> >> >> logins. I would loose the chance to create new users through
> >> OFBiz,
> >> >> >> wouldn't I?
> >> >> >>
> >> >> >> Any comments or pointers to specific documents are welcome.
> >> >> >>
> >> >> >> Regards,
> >> >> >> Torsten
> >> >> >
> >> >> >
> >> >>
> >> >
> >>
> >
>
Re: Storing and retrieving users and passwords from LDAP
Posted by Torsten Schlabach <ts...@gmx.net>.
Hi Amine,
thank you for your help. I was able to make this work, and I have spent
some extra time to create a version which uses JDNI (as included in the
JDK) and therefore does not need any extra lib and does not have any
license issues. I have attched my version to the JIRA issue.
Adrian still would like to see the code organized differently for
inclusion. I am not sure when I will find time, so I at least wanted to
make sure I will share this interim solution, especially as you need to
build that Netscape LDAP lib from source which can be a bit cumbersome.
I have also removed the need for ldap.user and ldap.password. I just use
the credentials supplied by the user to try and bind to LDAP. There is
no need for the OFBiz app to know the credentials of some overall LDAP
tree superuser. Putting this in the OFBiz config is nothing but a
security risk IMO.
Some more words of caution to everyone who might want to use apply this
patch:
1. This is an all-or-nothing solution. If you set login.useLDAP=true
*all* user's passwords are checked against LDAP. There is no fallback in
either direction, e.g. if the user is not found in LDAP, use the
database or vice versa. An optimal solution might be to give a user's
record an extra field "external auth" or something like that which would
point to an external authentication object, which might be an LDAP
object. (Take a look at Oracle's "IDENTIFIED BY" for example.) Besides
LDAP, we might also be looking at SSO solutions in the future, for example.
2. With the given implementation, all LDAP user objects need to be in a
single LDAP context, determined by ldap.baseDN. There is no sub-tree
searching for user objects. If in practice you would be looking at
keeping admins in a different part of the tree or even in a different
directory as normal users, that "external auth" field would be a
solution for that, again, if it would contain the full URL of the object
in LDAP.
Anyway, hopefully this patch is useful. Thanks again, Amine, for
providing the basic work here.
Regards,
Torsten
Amine AZZI schrieb:
> Hi Torsten,
>
> I posted a jira issue with svn patches for the same work on
>
> https://issues.apache.org/jira/browse/OFBIZ-811
>
> I hope this would help you. Of course there some work to do to have it on
> Ofbiz,
>
> Amine.
>
> 2007/7/14, Torsten Schlabach <ts...@gmx.net>:
>
>>
>> Hi Amine!
>>
>> It has been a long time ago since you sent me this, but now I am
>> revisiting the topic.
>>
>> > I send you the patch here (it concerns a CVS diff unfortunaltely but
>> > it's so basic that you can reproduce it).
>>
>> Well, no, sorry, but not at all. I was able to extract the
>>
>> userLoginLdap(DispatchContext ctx, Map context)
>>
>> function from your patch and planted it into LoginServices.java, but I
>> have no idea where to put the rest.
>>
>> I took a look at the original
>>
>> public static Map userLogin(DispatchContext ctx, Map context)
>>
>> function and it's so damn complex.
>>
>> The actual password checking is obviously done here:
>>
>> // if the password.accept.encrypted.and.plain property
>> // in security is set to true allow plain or encrypted
>> // passwords
>> // if this is a system account don't bother checking the
>> // passwords
>> if ((userLogin.get("currentPassword") != null &&
>> (realPassword.equals(userLogin.getString("currentPassword")) ||
>> ("true".equals(UtilProperties.getPropertyValue("security.properties",
>> "password.accept.encrypted.and.plain")) &&
>> password.equals(userLogin.getString("currentPassword")))))) {
>> Debug.logVerbose("[LoginServices.userLogin]
>> : Password Matched", module);
>>
>> I am especially confused by the comment:
>>
>> // if this is a system account don't bother checking the
>> // passwords
>>
>> but it's done anyway.
>>
>> How can I make sure that system accounts still work after I switched on
>>
>> login.useLDAP=true
>>
>> Any help would be appreciated.
>>
>> Regards,
>> Torsten
>>
>>
>>
>> Amine AZZI schrieb:
>> > Hello Torsten,
>> >
>> > I fell in the same problem. what I did if the integration of an ldap
>> API
>> > and
>> > added a method to LoginServices, and to security.properties
>> > I send you the patch here (it concerns a CVS diff unfortunaltely but
>> > it's so
>> > basic that you can reproduce it).
>> > The API integrated is the one of Mozzila LDAP
>> > The use is very easy, you set useLDAP to true to use the parametrized
>> ldap
>> > server, otherwise the party module is used to do authentification.
>> >
>> > The privileges configuration remains in Party Management module
>> >
>> >
>> > Amine.
>> >
>> > Index: ./securityext/src/org/ofbiz/securityext/login/LoginServices.java
>> > ===================================================================
>> > RCS file:
>> >
>> /cvsroot/neogia/ofbizNeogia/applications/securityext/src/org/ofbiz/securityext/login/Attic/LoginServices.java,v
>>
>> >
>> > retrieving revision 1.1.1.4
>> > diff -r1.1.1.4 LoginServices.java
>> > 27a28,30
>> >
>> >> import netscape.ldap.LDAPConnection;
>> >> import netscape.ldap.LDAPException;
>> >>
>> > 147c150,162
>> > <
>> > ---
>> >
>> >>
>> >> //this is useful in case someone wants to have
>> an
>> >
>> > ldap authentification
>> >
>> >> //it also requires that use create connections
>> on
>> >
>> > the party manager
>> >
>> >> boolean useLdap = "true".equals(
>> >
>> > UtilProperties.getPropertyValue("security.properties", "login.useLDAP
>> "));
>> >
>> >> boolean validPass = false;
>> >> if (!useLdap) {
>> >> validPass = (userLogin.get
>> ("currentPassword")
>> >
>> > != null &&
>> >
>> >> (realPassword.equals(
>> >
>> > userLogin.getString("currentPassword")) ||
>> >
>> >> ("true".equals(
>> >
>> > UtilProperties.getPropertyValue("security.properties", "
>> > password.accept.encrypted.and.plain")) && password.equals(
>> > userLogin.getString("currentPassword")))));
>> >
>> >> } else {
>> >> validPass = userLoginLdap(ctx, context);
>> >> }
>> >>
>> > 150,152c165
>> > < if ((userLogin.get("currentPassword") != null
>> &&
>> > <
>> > (realPassword.equals(userLogin.getString("currentPassword"))
>> > ||
>> > < ("true".equals(
>> > UtilProperties.getPropertyValue("security.properties", "
>> > password.accept.encrypted.and.plain")) && password.equals(
>> > userLogin.getString("currentPassword")))))) {
>> > ---
>> >
>> >> if (validPass) {
>> >
>> > 769a783,811
>> >
>> >>
>> >> private static boolean userLoginLdap(DispatchContext ctx, Map
>> >> context)
>> >
>> > {
>> >
>> >>
>> >> String host =
>> >> UtilProperties.getPropertyValue("security.properties",
>> >
>> > "ldap.host.name");
>> >
>> >> int port = Integer.parseInt(UtilProperties.getPropertyValue("
>> >
>> > security.properties", "ldap.host.port"));
>> >
>> >> int protocol =
>> Integer.parseInt(UtilProperties.getPropertyValue
>> ("
>> >
>> > security.properties", "ldap.protocol"));;
>> >
>> >>
>> >> String baseDN = UtilProperties.getPropertyValue("
>> >
>> > security.properties", "ldap.baseDN");
>> >
>> >> String ldapUser = UtilProperties.getPropertyValue("
>> >
>> > security.properties", "ldap.user");
>> >
>> >> String ldapPassword = UtilProperties.getPropertyValue("
>> >
>> > security.properties", "ldap.password");
>> >
>> >>
>> >> String username = (String) context.get("login.username");
>> >> if (username == null) username = (String)
>> >> context.get("username");
>> >> String password = (String) context.get("login.password");
>> >> if (password == null) password = (String)
>> >> context.get("password");
>> >>
>> >> LDAPConnection conn = new LDAPConnection();
>> >> try {
>> >> conn.connect(host, port, ldapUser, ldapPassword);
>> >> conn.authenticate(protocol, username, password);
>> >> } catch ( LDAPException e ) {
>> >> Debug.logVerbose("Error number: " +
>> e.getLDAPResultCode(),
>> >
>> > module) ;
>> >
>> >> break;
>> >> }
>> >> return false;
>> >> }
>> >>
>> >> return true;
>> >> }
>> >
>> > Index: ./security/config/security.properties
>> > ===================================================================
>> > RCS file:
>> >
>> /cvsroot/neogia/ofbizNeogia/framework/security/config/security.properties,v
>>
>> > retrieving revision 1.1.1.3
>> > diff -r1.1.1.3 security.properties
>> > 53a54,64
>> >
>> >>
>> >> # --ldap parameters
>> >>
>> >> ldap.host.name=ldapSrv
>> >> ldap.host.port=389
>> >> ldap.baseDN=dc=neogia,dc=org
>> >> ldap.protocol=3
>> >> ldap.user=cn=myUserid,ou=Myou,ou=MyOU2,dc=neogia,dc=org
>> >> ldap.password=myPass
>> >> login.useLDAP=false
>> >>
>> >
>> >
>> > 2007/3/1, Torsten Schlabach <ts...@gmx.net>:
>> >
>> >>
>> >> Change or provide an alternative implementation?
>> >>
>> >> If I did either one, would you commit it?
>> >>
>> >> I mean, would that be a "clean" solution?
>> >>
>> >> David E. Jones schrieb:
>> >> >
>> >> > Rather than trying to do this through the entity engine it might be
>> >> > better/easier to just change the userLogin service to look at both
>> >> > sources, and manage conflicts as desired, etc.
>> >> >
>> >> > -David
>> >> >
>> >> >
>> >> > On Feb 28, 2007, at 11:29 AM, Torsten Schlabach wrote:
>> >> >
>> >> >> Hi!
>> >> >>
>> >> >> I think I am about to find my way through OFBiz internals, so
>> >> >> basically I am just asking for confirmation and some little hints.
>> >> >>
>> >> >> What I am trying to do is to read users and their passwords
>> not from
>> >> >> the embedded Derby database but from a given LDAP directory.
>> >> >>
>> >> >> I have taken a look at org.ofbiz.common.login.LoginServices. From
>> >> >> there I find out that it's using a delegator to retrieve
>> the username
>> >> >> and corresponding password through the entity engine.
>> >> >>
>> >> >> Am I right that I would have to configure the entity engine in
>> a way
>> >> >> that it keeps retrieving anything else from where it does today,
>> but
>> >> >> that I would have to tell it to use a different datasource for the
>> >> >> entity UserLogin?
>> >> >>
>> >> >> I haven't found that specific place yet, but hopefully
>> that shouldn't
>> >> >> be that difficult.
>> >> >>
>> >> >> But browsing pre-defined datasources in entityengine.xml, I did not
>> >> >> find anything which looked like LDAP to me. So I wonder: Are
>> >> >> delegators tied to SQL databases and JDBC? Or to something
>> which has
>> >> >> to have a relational structure? (LDAP can be mapped into
>> a relational
>> >> >> structure, but as we know, it's not relational by default.)
>> >> >>
>> >> >> Would I have to code a new implementation of a Delegator to talk to
>> >> >> an LDAP server? Or would there be a way to achieve this
>> just through
>> >> >> configuration?
>> >> >>
>> >> >> Also I haven't yet found the place where datasources,
>> delegators and
>> >> >> entities are connected.
>> >> >>
>> >> >> Can this be done at all at reasonable effort?
>> >> >>
>> >> >> I am thinking of implementing my own replacement for
>> LoginServices as
>> >> >> an alternative. That would for example allow to check for
>> container
>> >> >> based authentication (getUserPrincial()). But that would just
>> manage
>> >> >> logins. I would loose the chance to create new users through
>> OFBiz,
>> >> >> wouldn't I?
>> >> >>
>> >> >> Any comments or pointers to specific documents are welcome.
>> >> >>
>> >> >> Regards,
>> >> >> Torsten
>> >> >
>> >> >
>> >>
>> >
>>
>
Re: Storing and retrieving users and passwords from LDAP
Posted by Amine AZZI <ba...@gmail.com>.
Hi Torsten,
I posted a jira issue with svn patches for the same work on
https://issues.apache.org/jira/browse/OFBIZ-811
I hope this would help you. Of course there some work to do to have it on
Ofbiz,
Amine.
2007/7/14, Torsten Schlabach <ts...@gmx.net>:
>
> Hi Amine!
>
> It has been a long time ago since you sent me this, but now I am
> revisiting the topic.
>
> > I send you the patch here (it concerns a CVS diff unfortunaltely but
> > it's so basic that you can reproduce it).
>
> Well, no, sorry, but not at all. I was able to extract the
>
> userLoginLdap(DispatchContext ctx, Map context)
>
> function from your patch and planted it into LoginServices.java, but I
> have no idea where to put the rest.
>
> I took a look at the original
>
> public static Map userLogin(DispatchContext ctx, Map context)
>
> function and it's so damn complex.
>
> The actual password checking is obviously done here:
>
> // if the password.accept.encrypted.and.plain property
> // in security is set to true allow plain or encrypted
> // passwords
> // if this is a system account don't bother checking the
> // passwords
> if ((userLogin.get("currentPassword") != null &&
> (realPassword.equals(userLogin.getString("currentPassword")) ||
> ("true".equals(UtilProperties.getPropertyValue("security.properties",
> "password.accept.encrypted.and.plain")) &&
> password.equals(userLogin.getString("currentPassword")))))) {
> Debug.logVerbose("[LoginServices.userLogin]
> : Password Matched", module);
>
> I am especially confused by the comment:
>
> // if this is a system account don't bother checking the
> // passwords
>
> but it's done anyway.
>
> How can I make sure that system accounts still work after I switched on
>
> login.useLDAP=true
>
> Any help would be appreciated.
>
> Regards,
> Torsten
>
>
>
> Amine AZZI schrieb:
> > Hello Torsten,
> >
> > I fell in the same problem. what I did if the integration of an ldap API
> > and
> > added a method to LoginServices, and to security.properties
> > I send you the patch here (it concerns a CVS diff unfortunaltely but
> > it's so
> > basic that you can reproduce it).
> > The API integrated is the one of Mozzila LDAP
> > The use is very easy, you set useLDAP to true to use the parametrized
> ldap
> > server, otherwise the party module is used to do authentification.
> >
> > The privileges configuration remains in Party Management module
> >
> >
> > Amine.
> >
> > Index: ./securityext/src/org/ofbiz/securityext/login/LoginServices.java
> > ===================================================================
> > RCS file:
> >
> /cvsroot/neogia/ofbizNeogia/applications/securityext/src/org/ofbiz/securityext/login/Attic/LoginServices.java,v
> >
> > retrieving revision 1.1.1.4
> > diff -r1.1.1.4 LoginServices.java
> > 27a28,30
> >
> >> import netscape.ldap.LDAPConnection;
> >> import netscape.ldap.LDAPException;
> >>
> > 147c150,162
> > <
> > ---
> >
> >>
> >> //this is useful in case someone wants to have
> an
> >
> > ldap authentification
> >
> >> //it also requires that use create connections
> on
> >
> > the party manager
> >
> >> boolean useLdap = "true".equals(
> >
> > UtilProperties.getPropertyValue("security.properties", "login.useLDAP
> "));
> >
> >> boolean validPass = false;
> >> if (!useLdap) {
> >> validPass = (userLogin.get
> ("currentPassword")
> >
> > != null &&
> >
> >> (realPassword.equals(
> >
> > userLogin.getString("currentPassword")) ||
> >
> >> ("true".equals(
> >
> > UtilProperties.getPropertyValue("security.properties", "
> > password.accept.encrypted.and.plain")) && password.equals(
> > userLogin.getString("currentPassword")))));
> >
> >> } else {
> >> validPass = userLoginLdap(ctx, context);
> >> }
> >>
> > 150,152c165
> > < if ((userLogin.get("currentPassword") != null
> &&
> > <
> > (realPassword.equals(userLogin.getString("currentPassword"))
> > ||
> > < ("true".equals(
> > UtilProperties.getPropertyValue("security.properties", "
> > password.accept.encrypted.and.plain")) && password.equals(
> > userLogin.getString("currentPassword")))))) {
> > ---
> >
> >> if (validPass) {
> >
> > 769a783,811
> >
> >>
> >> private static boolean userLoginLdap(DispatchContext ctx, Map
> >> context)
> >
> > {
> >
> >>
> >> String host =
> >> UtilProperties.getPropertyValue("security.properties",
> >
> > "ldap.host.name");
> >
> >> int port = Integer.parseInt(UtilProperties.getPropertyValue("
> >
> > security.properties", "ldap.host.port"));
> >
> >> int protocol = Integer.parseInt(UtilProperties.getPropertyValue
> ("
> >
> > security.properties", "ldap.protocol"));;
> >
> >>
> >> String baseDN = UtilProperties.getPropertyValue("
> >
> > security.properties", "ldap.baseDN");
> >
> >> String ldapUser = UtilProperties.getPropertyValue("
> >
> > security.properties", "ldap.user");
> >
> >> String ldapPassword = UtilProperties.getPropertyValue("
> >
> > security.properties", "ldap.password");
> >
> >>
> >> String username = (String) context.get("login.username");
> >> if (username == null) username = (String)
> >> context.get("username");
> >> String password = (String) context.get("login.password");
> >> if (password == null) password = (String)
> >> context.get("password");
> >>
> >> LDAPConnection conn = new LDAPConnection();
> >> try {
> >> conn.connect(host, port, ldapUser, ldapPassword);
> >> conn.authenticate(protocol, username, password);
> >> } catch ( LDAPException e ) {
> >> Debug.logVerbose("Error number: " + e.getLDAPResultCode(),
> >
> > module) ;
> >
> >> break;
> >> }
> >> return false;
> >> }
> >>
> >> return true;
> >> }
> >
> > Index: ./security/config/security.properties
> > ===================================================================
> > RCS file:
> >
> /cvsroot/neogia/ofbizNeogia/framework/security/config/security.properties,v
> > retrieving revision 1.1.1.3
> > diff -r1.1.1.3 security.properties
> > 53a54,64
> >
> >>
> >> # --ldap parameters
> >>
> >> ldap.host.name=ldapSrv
> >> ldap.host.port=389
> >> ldap.baseDN=dc=neogia,dc=org
> >> ldap.protocol=3
> >> ldap.user=cn=myUserid,ou=Myou,ou=MyOU2,dc=neogia,dc=org
> >> ldap.password=myPass
> >> login.useLDAP=false
> >>
> >
> >
> > 2007/3/1, Torsten Schlabach <ts...@gmx.net>:
> >
> >>
> >> Change or provide an alternative implementation?
> >>
> >> If I did either one, would you commit it?
> >>
> >> I mean, would that be a "clean" solution?
> >>
> >> David E. Jones schrieb:
> >> >
> >> > Rather than trying to do this through the entity engine it might be
> >> > better/easier to just change the userLogin service to look at both
> >> > sources, and manage conflicts as desired, etc.
> >> >
> >> > -David
> >> >
> >> >
> >> > On Feb 28, 2007, at 11:29 AM, Torsten Schlabach wrote:
> >> >
> >> >> Hi!
> >> >>
> >> >> I think I am about to find my way through OFBiz internals, so
> >> >> basically I am just asking for confirmation and some little hints.
> >> >>
> >> >> What I am trying to do is to read users and their passwords
> not from
> >> >> the embedded Derby database but from a given LDAP directory.
> >> >>
> >> >> I have taken a look at org.ofbiz.common.login.LoginServices. From
> >> >> there I find out that it's using a delegator to retrieve
> the username
> >> >> and corresponding password through the entity engine.
> >> >>
> >> >> Am I right that I would have to configure the entity engine in
> a way
> >> >> that it keeps retrieving anything else from where it does today,
> but
> >> >> that I would have to tell it to use a different datasource for the
> >> >> entity UserLogin?
> >> >>
> >> >> I haven't found that specific place yet, but hopefully
> that shouldn't
> >> >> be that difficult.
> >> >>
> >> >> But browsing pre-defined datasources in entityengine.xml, I did not
> >> >> find anything which looked like LDAP to me. So I wonder: Are
> >> >> delegators tied to SQL databases and JDBC? Or to something
> which has
> >> >> to have a relational structure? (LDAP can be mapped into
> a relational
> >> >> structure, but as we know, it's not relational by default.)
> >> >>
> >> >> Would I have to code a new implementation of a Delegator to talk to
> >> >> an LDAP server? Or would there be a way to achieve this
> just through
> >> >> configuration?
> >> >>
> >> >> Also I haven't yet found the place where datasources,
> delegators and
> >> >> entities are connected.
> >> >>
> >> >> Can this be done at all at reasonable effort?
> >> >>
> >> >> I am thinking of implementing my own replacement for
> LoginServices as
> >> >> an alternative. That would for example allow to check for container
> >> >> based authentication (getUserPrincial()). But that would just
> manage
> >> >> logins. I would loose the chance to create new users through OFBiz,
> >> >> wouldn't I?
> >> >>
> >> >> Any comments or pointers to specific documents are welcome.
> >> >>
> >> >> Regards,
> >> >> Torsten
> >> >
> >> >
> >>
> >
>
Re: Storing and retrieving users and passwords from LDAP
Posted by Torsten Schlabach <ts...@gmx.net>.
Hi Amine!
It has been a long time ago since you sent me this, but now I am
revisiting the topic.
> I send you the patch here (it concerns a CVS diff unfortunaltely but
> it's so basic that you can reproduce it).
Well, no, sorry, but not at all. I was able to extract the
userLoginLdap(DispatchContext ctx, Map context)
function from your patch and planted it into LoginServices.java, but I
have no idea where to put the rest.
I took a look at the original
public static Map userLogin(DispatchContext ctx, Map context)
function and it's so damn complex.
The actual password checking is obviously done here:
// if the password.accept.encrypted.and.plain property
// in security is set to true allow plain or encrypted
// passwords
// if this is a system account don't bother checking the
// passwords
if ((userLogin.get("currentPassword") != null &&
(realPassword.equals(userLogin.getString("currentPassword")) ||
("true".equals(UtilProperties.getPropertyValue("security.properties",
"password.accept.encrypted.and.plain")) &&
password.equals(userLogin.getString("currentPassword")))))) {
Debug.logVerbose("[LoginServices.userLogin]
: Password Matched", module);
I am especially confused by the comment:
// if this is a system account don't bother checking the
// passwords
but it's done anyway.
How can I make sure that system accounts still work after I switched on
login.useLDAP=true
Any help would be appreciated.
Regards,
Torsten
Amine AZZI schrieb:
> Hello Torsten,
>
> I fell in the same problem. what I did if the integration of an ldap API
> and
> added a method to LoginServices, and to security.properties
> I send you the patch here (it concerns a CVS diff unfortunaltely but
> it's so
> basic that you can reproduce it).
> The API integrated is the one of Mozzila LDAP
> The use is very easy, you set useLDAP to true to use the parametrized ldap
> server, otherwise the party module is used to do authentification.
>
> The privileges configuration remains in Party Management module
>
>
> Amine.
>
> Index: ./securityext/src/org/ofbiz/securityext/login/LoginServices.java
> ===================================================================
> RCS file:
> /cvsroot/neogia/ofbizNeogia/applications/securityext/src/org/ofbiz/securityext/login/Attic/LoginServices.java,v
>
> retrieving revision 1.1.1.4
> diff -r1.1.1.4 LoginServices.java
> 27a28,30
>
>> import netscape.ldap.LDAPConnection;
>> import netscape.ldap.LDAPException;
>>
> 147c150,162
> <
> ---
>
>>
>> //this is useful in case someone wants to have an
>
> ldap authentification
>
>> //it also requires that use create connections on
>
> the party manager
>
>> boolean useLdap = "true".equals(
>
> UtilProperties.getPropertyValue("security.properties", "login.useLDAP"));
>
>> boolean validPass = false;
>> if (!useLdap) {
>> validPass = (userLogin.get("currentPassword")
>
> != null &&
>
>> (realPassword.equals(
>
> userLogin.getString("currentPassword")) ||
>
>> ("true".equals(
>
> UtilProperties.getPropertyValue("security.properties", "
> password.accept.encrypted.and.plain")) && password.equals(
> userLogin.getString("currentPassword")))));
>
>> } else {
>> validPass = userLoginLdap(ctx, context);
>> }
>>
> 150,152c165
> < if ((userLogin.get("currentPassword") != null &&
> <
> (realPassword.equals(userLogin.getString("currentPassword"))
> ||
> < ("true".equals(
> UtilProperties.getPropertyValue("security.properties", "
> password.accept.encrypted.and.plain")) && password.equals(
> userLogin.getString("currentPassword")))))) {
> ---
>
>> if (validPass) {
>
> 769a783,811
>
>>
>> private static boolean userLoginLdap(DispatchContext ctx, Map
>> context)
>
> {
>
>>
>> String host =
>> UtilProperties.getPropertyValue("security.properties",
>
> "ldap.host.name");
>
>> int port = Integer.parseInt(UtilProperties.getPropertyValue("
>
> security.properties", "ldap.host.port"));
>
>> int protocol = Integer.parseInt(UtilProperties.getPropertyValue("
>
> security.properties", "ldap.protocol"));;
>
>>
>> String baseDN = UtilProperties.getPropertyValue("
>
> security.properties", "ldap.baseDN");
>
>> String ldapUser = UtilProperties.getPropertyValue("
>
> security.properties", "ldap.user");
>
>> String ldapPassword = UtilProperties.getPropertyValue("
>
> security.properties", "ldap.password");
>
>>
>> String username = (String) context.get("login.username");
>> if (username == null) username = (String)
>> context.get("username");
>> String password = (String) context.get("login.password");
>> if (password == null) password = (String)
>> context.get("password");
>>
>> LDAPConnection conn = new LDAPConnection();
>> try {
>> conn.connect(host, port, ldapUser, ldapPassword);
>> conn.authenticate(protocol, username, password);
>> } catch ( LDAPException e ) {
>> Debug.logVerbose("Error number: " + e.getLDAPResultCode(),
>
> module) ;
>
>> break;
>> }
>> return false;
>> }
>>
>> return true;
>> }
>
> Index: ./security/config/security.properties
> ===================================================================
> RCS file:
> /cvsroot/neogia/ofbizNeogia/framework/security/config/security.properties,v
> retrieving revision 1.1.1.3
> diff -r1.1.1.3 security.properties
> 53a54,64
>
>>
>> # --ldap parameters
>>
>> ldap.host.name=ldapSrv
>> ldap.host.port=389
>> ldap.baseDN=dc=neogia,dc=org
>> ldap.protocol=3
>> ldap.user=cn=myUserid,ou=Myou,ou=MyOU2,dc=neogia,dc=org
>> ldap.password=myPass
>> login.useLDAP=false
>>
>
>
> 2007/3/1, Torsten Schlabach <ts...@gmx.net>:
>
>>
>> Change or provide an alternative implementation?
>>
>> If I did either one, would you commit it?
>>
>> I mean, would that be a "clean" solution?
>>
>> David E. Jones schrieb:
>> >
>> > Rather than trying to do this through the entity engine it might be
>> > better/easier to just change the userLogin service to look at both
>> > sources, and manage conflicts as desired, etc.
>> >
>> > -David
>> >
>> >
>> > On Feb 28, 2007, at 11:29 AM, Torsten Schlabach wrote:
>> >
>> >> Hi!
>> >>
>> >> I think I am about to find my way through OFBiz internals, so
>> >> basically I am just asking for confirmation and some little hints.
>> >>
>> >> What I am trying to do is to read users and their passwords not from
>> >> the embedded Derby database but from a given LDAP directory.
>> >>
>> >> I have taken a look at org.ofbiz.common.login.LoginServices. From
>> >> there I find out that it's using a delegator to retrieve the username
>> >> and corresponding password through the entity engine.
>> >>
>> >> Am I right that I would have to configure the entity engine in a way
>> >> that it keeps retrieving anything else from where it does today, but
>> >> that I would have to tell it to use a different datasource for the
>> >> entity UserLogin?
>> >>
>> >> I haven't found that specific place yet, but hopefully that shouldn't
>> >> be that difficult.
>> >>
>> >> But browsing pre-defined datasources in entityengine.xml, I did not
>> >> find anything which looked like LDAP to me. So I wonder: Are
>> >> delegators tied to SQL databases and JDBC? Or to something which has
>> >> to have a relational structure? (LDAP can be mapped into a relational
>> >> structure, but as we know, it's not relational by default.)
>> >>
>> >> Would I have to code a new implementation of a Delegator to talk to
>> >> an LDAP server? Or would there be a way to achieve this just through
>> >> configuration?
>> >>
>> >> Also I haven't yet found the place where datasources, delegators and
>> >> entities are connected.
>> >>
>> >> Can this be done at all at reasonable effort?
>> >>
>> >> I am thinking of implementing my own replacement for LoginServices as
>> >> an alternative. That would for example allow to check for container
>> >> based authentication (getUserPrincial()). But that would just manage
>> >> logins. I would loose the chance to create new users through OFBiz,
>> >> wouldn't I?
>> >>
>> >> Any comments or pointers to specific documents are welcome.
>> >>
>> >> Regards,
>> >> Torsten
>> >
>> >
>>
>
Re: Storing and retrieving users and passwords from LDAP
Posted by Amine AZZI <ba...@gmail.com>.
Hello Torsten,
I fell in the same problem. what I did if the integration of an ldap API and
added a method to LoginServices, and to security.properties
I send you the patch here (it concerns a CVS diff unfortunaltely but it's so
basic that you can reproduce it).
The API integrated is the one of Mozzila LDAP
The use is very easy, you set useLDAP to true to use the parametrized ldap
server, otherwise the party module is used to do authentification.
The privileges configuration remains in Party Management module
Amine.
Index: ./securityext/src/org/ofbiz/securityext/login/LoginServices.java
===================================================================
RCS file:
/cvsroot/neogia/ofbizNeogia/applications/securityext/src/org/ofbiz/securityext/login/Attic/LoginServices.java,v
retrieving revision 1.1.1.4
diff -r1.1.1.4 LoginServices.java
27a28,30
> import netscape.ldap.LDAPConnection;
> import netscape.ldap.LDAPException;
>
147c150,162
<
---
>
> //this is useful in case someone wants to have an
ldap authentification
> //it also requires that use create connections on
the party manager
> boolean useLdap = "true".equals(
UtilProperties.getPropertyValue("security.properties", "login.useLDAP"));
> boolean validPass = false;
> if (!useLdap) {
> validPass = (userLogin.get("currentPassword")
!= null &&
> (realPassword.equals(
userLogin.getString("currentPassword")) ||
> ("true".equals(
UtilProperties.getPropertyValue("security.properties", "
password.accept.encrypted.and.plain")) && password.equals(
userLogin.getString("currentPassword")))));
> } else {
> validPass = userLoginLdap(ctx, context);
> }
>
150,152c165
< if ((userLogin.get("currentPassword") != null &&
<
(realPassword.equals(userLogin.getString("currentPassword"))
||
< ("true".equals(
UtilProperties.getPropertyValue("security.properties", "
password.accept.encrypted.and.plain")) && password.equals(
userLogin.getString("currentPassword")))))) {
---
> if (validPass) {
769a783,811
>
> private static boolean userLoginLdap(DispatchContext ctx, Map context)
{
>
> String host = UtilProperties.getPropertyValue("security.properties",
"ldap.host.name");
> int port = Integer.parseInt(UtilProperties.getPropertyValue("
security.properties", "ldap.host.port"));
> int protocol = Integer.parseInt(UtilProperties.getPropertyValue("
security.properties", "ldap.protocol"));;
>
> String baseDN = UtilProperties.getPropertyValue("
security.properties", "ldap.baseDN");
> String ldapUser = UtilProperties.getPropertyValue("
security.properties", "ldap.user");
> String ldapPassword = UtilProperties.getPropertyValue("
security.properties", "ldap.password");
>
> String username = (String) context.get("login.username");
> if (username == null) username = (String) context.get("username");
> String password = (String) context.get("login.password");
> if (password == null) password = (String) context.get("password");
>
> LDAPConnection conn = new LDAPConnection();
> try {
> conn.connect(host, port, ldapUser, ldapPassword);
> conn.authenticate(protocol, username, password);
> } catch ( LDAPException e ) {
> Debug.logVerbose("Error number: " + e.getLDAPResultCode(),
module) ;
> break;
> }
> return false;
> }
>
> return true;
> }
Index: ./security/config/security.properties
===================================================================
RCS file:
/cvsroot/neogia/ofbizNeogia/framework/security/config/security.properties,v
retrieving revision 1.1.1.3
diff -r1.1.1.3 security.properties
53a54,64
>
> # --ldap parameters
>
> ldap.host.name=ldapSrv
> ldap.host.port=389
> ldap.baseDN=dc=neogia,dc=org
> ldap.protocol=3
> ldap.user=cn=myUserid,ou=Myou,ou=MyOU2,dc=neogia,dc=org
> ldap.password=myPass
> login.useLDAP=false
>
2007/3/1, Torsten Schlabach <ts...@gmx.net>:
>
> Change or provide an alternative implementation?
>
> If I did either one, would you commit it?
>
> I mean, would that be a "clean" solution?
>
> David E. Jones schrieb:
> >
> > Rather than trying to do this through the entity engine it might be
> > better/easier to just change the userLogin service to look at both
> > sources, and manage conflicts as desired, etc.
> >
> > -David
> >
> >
> > On Feb 28, 2007, at 11:29 AM, Torsten Schlabach wrote:
> >
> >> Hi!
> >>
> >> I think I am about to find my way through OFBiz internals, so
> >> basically I am just asking for confirmation and some little hints.
> >>
> >> What I am trying to do is to read users and their passwords not from
> >> the embedded Derby database but from a given LDAP directory.
> >>
> >> I have taken a look at org.ofbiz.common.login.LoginServices. From
> >> there I find out that it's using a delegator to retrieve the username
> >> and corresponding password through the entity engine.
> >>
> >> Am I right that I would have to configure the entity engine in a way
> >> that it keeps retrieving anything else from where it does today, but
> >> that I would have to tell it to use a different datasource for the
> >> entity UserLogin?
> >>
> >> I haven't found that specific place yet, but hopefully that shouldn't
> >> be that difficult.
> >>
> >> But browsing pre-defined datasources in entityengine.xml, I did not
> >> find anything which looked like LDAP to me. So I wonder: Are
> >> delegators tied to SQL databases and JDBC? Or to something which has
> >> to have a relational structure? (LDAP can be mapped into a relational
> >> structure, but as we know, it's not relational by default.)
> >>
> >> Would I have to code a new implementation of a Delegator to talk to
> >> an LDAP server? Or would there be a way to achieve this just through
> >> configuration?
> >>
> >> Also I haven't yet found the place where datasources, delegators and
> >> entities are connected.
> >>
> >> Can this be done at all at reasonable effort?
> >>
> >> I am thinking of implementing my own replacement for LoginServices as
> >> an alternative. That would for example allow to check for container
> >> based authentication (getUserPrincial()). But that would just manage
> >> logins. I would loose the chance to create new users through OFBiz,
> >> wouldn't I?
> >>
> >> Any comments or pointers to specific documents are welcome.
> >>
> >> Regards,
> >> Torsten
> >
> >
>