Opening LDAP configuration to allow connection with Tomcat user realm.

By: Karel Gardas user 18 Oct 2018 at 2 a.m. CDT

5 Responses
Karel Gardas gravatar
Hello, I work on a project using Gluu and Tomcat. For OpenID tomcat <-> Gluu integration we are using Boyle's Software connector: https://github.com/boylesoftware/tomcat8-oidcauth Everything runs fine so far, but we got to the point where we would like to connect Tomcat user realm to the Gluu's LDAP. That is to prevent user data duplication in both Gluu LDAP and somewhere in Tomcat realm of whatever kind. I've successfully open LDAP port for listening also on the outside. I've successfully changed its X509 crypto from self signed certificate to our CA's signed certificate. I've verified that by using Apache Directory Studio and openssl s_connect -showcerts. Besides this I've also changed Gluu's certificate to use our own generated one signed by our CA. I've also imported our CA's certificate to JDK's cacerts and also to opendj/config/truststore. And finally also changed opendj's trusted cert in /etc/certs/opendj.pkcs12 to contain our CA's certificate. But still identity app (and oxauth too, exceptions are the same basically) throws exceptions on me and failed on deployment, since it can't connect to LDAP. The message is: ``` 2018-10-17 19:41:57,260 INFO [main] [org.xdi.oxauth.model.util.SecurityProviderUtility] (SecurityProviderUtility.java:23) - Adding Bouncy Castle Provider 2018-10-17 19:41:58.330:WARN:oeja.ServletContainerInitializersStarter:main: org.xdi.exception.ConfigurationException: Failed to create LDAP connection pool! at org.xdi.oxauth.service.AppInitializer.createConnectionProvider(AppInitializer.java:342) at org.xdi.oxauth.service.AppInitializer.applicationInitialized(AppInitializer.java:168) at org.xdi.oxauth.service.AppInitializer$Proxy$_$$_WeldSubclass.applicationInitialized(Unknown Source) ``` and: ``` 018-10-17 19:41:58.331:WARN:oejw.WebAppContext:main: Failed startup of context o.e.j.w.WebAppContext@627551fb{oxAuth Server,/oxauth,[file:///opt/jetty-9.4/temp/jetty-localhost-8081-oxauth.war-_oxauth-any-675306209942242451.dir/we bapp/, jar:file:///opt/jetty-9.4/temp/jetty-localhost-8081-oxauth.war-_oxauth-any-675306209942242451.dir/webapp/WEB-INF/lib/javax.faces-2.2.16.jar!/META-INF/resources, jar:file:///opt/jetty-9.4/temp/jetty-localhost-8081-oxauth.war -_oxauth-any-675306209942242451.dir/webapp/WEB-INF/lib/oxauth-static-3.1.4.Final.jar!/META-INF/resources, jar:file:///opt/jetty-9.4/temp/jetty-localhost-8081-oxauth.war-_oxauth-any-675306209942242451.dir/webapp/WEB-INF/lib/omnifac es-2.6.9.jar!/META-INF/resources],UNAVAILABLE}{/oxauth.war} java.lang.RuntimeException: org.xdi.exception.ConfigurationException: Failed to create LDAP connection pool! at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:69) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:355) at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497) ``` which is caused by: ``` Caused by: org.xdi.exception.ConfigurationException: Failed to create LDAP connection pool! at org.xdi.oxauth.service.AppInitializer.createConnectionProvider(AppInitializer.java:342) at org.xdi.oxauth.service.AppInitializer.applicationInitialized(AppInitializer.java:168) at org.xdi.oxauth.service.AppInitializer$Proxy$_$$_WeldSubclass.applicationInitialized(Unknown Source) ``` Do you have any idea where I may switch on some debugging which would lead me better on where I need to touch Gluu in order to support such hacked LDAP? Thanks! Karel
Ubuntu 16.04
closed

Answers

By Aliaksandr Samuseu staff 18 Oct 2018 at 12:18 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Karel. Let's try one simple thing before delving deeper into it. Inside container, edit `/etc/gluu/conf/ox-ldap.properties` and comment out next 3 lines: ``` ssl.trustStoreFile: /etc/certs/opendj.pkcs12 ssl.trustStorePin: BASE64-STRING== ssl.trustStoreFormat: pkcs12 ``` Then restart oxauth/identity and see whether it helped. If it won't, we would need you to provide more complete logs for us to analize them. Please do next: 1. Run `date` command inside container and copy the timestamp 2. Restart `oxauth` service, wait 5 minutes, then grab `oxauth.log` file and the recent `*-jetty.log` file under `/opt/gluu/jetty/oxauth/logs/` 3. Restart `identity` service, wait 5 minutes, then grab `oxtrust.log` file and the recent `*-jetty.log` file under `/opt/gluu/jetty/oxauth/logs/` 4. Share it with us using any file sharing service of your choice, also provide the timestamp you shared at step 1

By Aliaksandr Samuseu staff 18 Oct 2018 at 12:26 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
One more thing. You mentioned this: >I've also imported our CA's certificate to JDK's cacerts and also to opendj/config/truststore. A couple of questions: 1. Which JDK's cacerts file did you import them into? Could you provide the exact path to it? 2. Have you tried also to import the OpenDJ and Apache certificates itself in cacerts, not just their root CA's cert?

By Aliaksandr Samuseu staff 18 Oct 2018 at 12:39 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Karel, did you also remove the previous (self-signed) certificates for OpenDJ and Apache from `cacerts`?

By Karel Gardas user 18 Oct 2018 at 1:05 p.m. CDT

Copy
Karel Gardas gravatar
Aliaksandr, thanks a lot for your help. It's indeed very fast since by an advice to comment those bits inside the ox-ldap.properties you have solved my problem completely! Looks like those properties are not required? Thanks! Karel

By Aliaksandr Samuseu staff 18 Oct 2018 at 1:19 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Sure, you're welcome. >Looks like those properties are not required? I'm honestly not even sure now, as we've suggested to comment them out in cases like yours so many times. Commenting them out won't break anything, you can be sure of that, at least. I'll rise this question with the dev team.

Post an answer