OpenDJ: REST LDAP gateway & LDAPS or LDAP & StartTLS

OpenDJ Community Logo Shortly after OpenDJ 2.6.0, Matt added support in the REST LDAP gateway (download the latest from Artifactory) for securing connections to directory servers by using LDAPS or LDAP & StartTLS. The configuration is described in the in-progress admin guide, but you hardly need the doc given the comments Matt added to the configuration file.

Securing the connection from the gateway to the LDAP servers changes nothing for REST client applications. You can however see in the access log that switching from:

"connectionSecurity"       : "none"

to:

"connectionSecurity"       : "startTLS"

makes a difference in how the gateway connects to the server. Without securing the connection:

$ curl --user bjensen:hifalutin \
http://opendj.example.com:8080/rest2ldap/users/bjensen

Produces this in the OpenDJ access log:

[09/Jul/2013:10:14:24 +0200] CONNECT conn=2 from=127.0.0.1:51448 to=127.0.0.1:1389 protocol=LDAP
[09/Jul/2013:10:14:24 +0200] BIND REQ conn=2 op=0 msgID=1 version=3 type=SIMPLE dn="uid=bjensen,ou=People,dc=example,dc=com"
[09/Jul/2013:10:14:24 +0200] BIND RES conn=2 op=0 msgID=1 result=0 authDN="uid=bjensen,ou=People,dc=example,dc=com" etime=2
[09/Jul/2013:10:14:24 +0200] SEARCH REQ conn=2 op=1 msgID=2 base="uid=bjensen,ou=people,dc=example,dc=com" scope=baseObject filter="(objectClass=*)" attrs="etag,manager,telephoneNumber,mail,uid,sn,givenName,cn,modifyTimestamp,createTimestamp,isMemberOf"
[09/Jul/2013:10:14:24 +0200] SEARCH RES conn=2 op=1 msgID=2 result=0 nentries=1 etime=31

After the change, you can see the StartTLS extended request and response in the access log:

[09/Jul/2013:10:18:18 +0200] CONNECT conn=3 from=127.0.0.1:51487 to=127.0.0.1:1389 protocol=LDAP
[09/Jul/2013:10:18:18 +0200] EXTENDED REQ conn=3 op=0 msgID=1 name="StartTLS" oid="1.3.6.1.4.1.1466.20037"
[09/Jul/2013:10:18:18 +0200] EXTENDED RES conn=3 op=0 msgID=1 name="StartTLS" oid="1.3.6.1.4.1.1466.20037" result=0 etime=1
[09/Jul/2013:10:18:18 +0200] BIND REQ conn=3 op=1 msgID=2 version=3 type=SIMPLE dn="cn=directory manager"
[09/Jul/2013:10:18:18 +0200] BIND RES conn=3 op=1 msgID=2 result=0 authDN="cn=Directory Manager,cn=Root DNs,cn=config" etime=1
[09/Jul/2013:10:18:18 +0200] SEARCH REQ conn=3 op=2 msgID=3 base="ou=people,dc=example,dc=com" scope=wholeSubtree filter="(&(objectClass=inetOrgPerson)(uid=bjensen))" attrs="1.1"
[09/Jul/2013:10:18:18 +0200] SEARCH RES conn=3 op=2 msgID=3 result=0 nentries=1 etime=2

This works even with a self-signed certificate because the default is blind trust:

"trustManager"             : "trustAll"

If you want the gateway to check the certificate, you can change the “trustManager” setting. You can either rely on the CA certificates from your Java environment with “jvm” (if the OpenDJ connection handler has a certificate signed by a well-known CA), or rely on a trust store file if you are using a self-signed certificate.

Here is one way of having the gateway trust the self-signed certificate after you change the configuration to:

"trustManager"             : "file"

Before changing the configuration, export the OpenDJ server-cert certificate and then import it into a JKS trust store file. If you do not use the defaults as in the following commands, then adjust the “fileBasedTrustManager*” settings, too.

$ keytool -export -alias server-cert \
> -file server-cert.crt \
> -keystore /path/to/opendj/config/keystore \
> -storepass `cat /path/to/opendj/config/keystore.pin`
> -storepass `cat /path/to/opendj/config/keystore.pin`
Certificate stored in file <server-cert.crt>
$ keytool -importcert -trustcacerts \
> -keystore truststore -alias server-cert \
> -file server-cert.crt -storetype JKS \
> -storepass password
Owner: CN=opendj.example.com, O=OpenDJ Self-Signed Certificate
Issuer: CN=opendj.example.com, O=OpenDJ Self-Signed Certificate
Serial number: 5b6a2074
Valid from: Tue Jul 09 10:11:34 CEST 2013 until: Mon Jul 04 10:11:34 CEST 2033
Certificate fingerprints:
	 MD5:  91:0D:F0:4D:5A:80:52:EC:A1:7A:C0:2A:CE:B0:68:3A
	 SHA1: F4:9B:51:D7:C9:8D:9D:18:11:EC:C5:8B:4F:7E:4D:E4:53:3F:2D:60
	 SHA256: F6:5A:33:22:CB:FB:D2:B5:E9:38:6A:16:55:96:9A:7F:8A:F0:DD:0F:94:AB:A6:9C:C8:F2:0D:4D:11:EF:E7:1F
	 Signature algorithm name: SHA1withRSA
	 Version: 3
Trust this certificate? [no]:  yes
Certificate was added to keystore

After making the configuration changes, you can restart the gateway to be sure all the changes were picked up.

Who has tried this with other directory servers?

Advertisements

Leave a comment

Filed under Directory Services and LDAP, Docs

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s