Storing and retrieving users and passwords from LDAP
Locked
Storing and retrieving users and passwords from LDAP
 
|
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
|
|
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 |
smime.p7s (3K)
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
|
|
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(), > 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 <[hidden email]>: > > 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
|
|
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 <[hidden email]>: > >> >> 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
|
|
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 <[hidden email]>: > > 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 <[hidden email]>: > > > >> > >> 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
|
|
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 <[hidden email]>: > >> >> 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 <[hidden email]>: >> > >> >> >> >> 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
|
|
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 <[hidden email]>: > > 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 <[hidden email]>: > > > >> > >> 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 <[hidden email]>: > >> > > >> >> > >> >> 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 > >> >> > > >> >> > > >> >> > >> > > >> > > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |