Re: SASL/EXTERNAL binding
> On Nov 16, 2017, at 2:35 PM, Emmanuel Lécharny wrote: > > Regarding this specific feature, teh real problem for us was to get it > tested. But if you don't mind doing this part of the job, we probably > can move forward ! +1 to needing help with the testing. I’ve never used SASL before and would like to learn how. If we get it to that point and have reusable tests, I’ll document it in the user’s manual. Shawn
Re: SASL/EXTERNAL binding
Le 16/11/2017 à 18:35, Frank Crow a écrit :
> About four years ago, I started on a project using OpenLDAP and Apache LDAP
> API for ldap client applications. Due to requirements we moved away from
> using stored passwords and configured for client-side certificates
> (SASL/EXTERNAL). That is when I discovered that the Apache LDAP API did
> not support SASL/EXTERNAL and that there was an outstanding bug
> (DIRAPI-105) against that feature.
It's not a bug, but a missing feature( although it's wrongly qualified
as 'bug' ;-)
>
> We undid the SASL/EXTERNAL requirement and failed our requirements with a
> promise to implement when available. Now I'm off of that project and onto
> a new one. Again, we have similar requirements. And still, after all
> these years DIRAPI-105 keeps getting kicked down the road.
Indeed :/
>
> So, after that ticket being open for nearly 7 years, I'm just wondering if
> I should give up hope? It's been quite a long road from the Mxx releases
> into the RC1 and RC2 and now 1.0.0 and still not supported. I'm really
> wanting to implement this authentication mechanism (actually, I am anyway)
> and I'd really like to use the Apache LDAP API but I'm stuck with simple
> binds if I do.
Implementing EXTERNAL in the LDAP API should be quite simple : it should
be as simple as extending the AbstractSaslRequest class, and to pass teh
EXTERNAL machanism as a String, plus an optional authzID parameter (whch
is a part of teh AbstractSaslRequest class). Adding the EXTERNAL value
in the SupportedSaslMechanisms class would help :
public final class SupportedSaslMechanisms
{
/** CRAM-MD5 mechanism */
public static final String CRAM_MD5 = "CRAM-MD5";
...
/** The EXTERNAL mechanism */
public static final String EXTERNAL = "EXTERNAL";
...
and
package org.apache.directory.ldap.client.api;
import
org.apache.directory.api.ldap.model.constants.SupportedSaslMechanisms;
/**
* Holds the data required to complete the EXTERNAL SASL operation
*
* @author mailto:d...@directory.apache.org";>Apache Directory
Project
*/
public class SaslExternalRequest extends AbstractSaslRequest
{
/**
* Creates a new instance of SaslExternalRequest.
*/
public SaslExternalRequest()
{
super( SupportedSaslMechanisms.EXTERNAL );
}
/**
* Creates a new instance of SaslExternalRequest.
*/
public SaslExternalRequest( String authzId )
{
super( SupportedSaslMechanisms.EXTERNAL );
this.authorizationId = authzId;
}
}
Last, not least, adding the appropriate function in
LdapNetworkConnection is needed :
/**
* Bind to the server using a SaslExternalRequest object.
*
* @param request The SaslExternalRequest POJO containing all the
needed parameters
* @return A LdapResponse containing the result
* @throws LdapException if some error occurred
*/
public BindResponse bind( SaslExternalRequest request ) throws
LdapException
{
if ( request == null )
{
String msg = "Cannot process a null request";
LOG.debug( msg );
throw new IllegalArgumentException( msg );
}
BindFuture bindFuture = bindAsync( request );
// Get the result from the future
try
{
// Read the response, waiting for it if not available
immediately
// Get the response, blocking
BindResponse bindResponse = bindFuture.get( timeout,
TimeUnit.MILLISECONDS );
if ( bindResponse == null )
{
// We didn't received anything : this is an error
LOG.error( "Bind failed : timeout occurred" );
throw new LdapException( TIME_OUT_ERROR );
}
if ( bindResponse.getLdapResult().getResultCode() ==
ResultCodeEnum.SUCCESS )
{
authenticated.set( true );
// Everything is fine, return the response
LOG.debug( "Bind successful : {}", bindResponse );
}
else
{
// We have had an error
LOG.debug( "Bind failed : {}", bindResponse );
}
return bindResponse;
}
catch ( Exception ie )
{
// Catch all other exceptions
LOG.error( NO_RESPONSE_ERROR, ie );
throw new LdapException( NO_RESPONSE_ERROR, ie );
}
}
That should be enough to get it working. Now, it requires some test.
Would you like to give it a little run ? If you validate that this code
works, I can easily inject it into the API and cut a release.
>
> I'm talking about projects which are pretty big US Navy programs of record
> where this feature would be very valuable. But I'm just thinking that I
> need to move on with life. Maybe look at Oracle Unified Directory or
> something else.
>
> Any ideas on that?
I gave you what I have from the top of my head. I
SASL/EXTERNAL binding
About four years ago, I started on a project using OpenLDAP and Apache LDAP API for ldap client applications. Due to requirements we moved away from using stored passwords and configured for client-side certificates (SASL/EXTERNAL). That is when I discovered that the Apache LDAP API did not support SASL/EXTERNAL and that there was an outstanding bug (DIRAPI-105) against that feature. We undid the SASL/EXTERNAL requirement and failed our requirements with a promise to implement when available. Now I'm off of that project and onto a new one. Again, we have similar requirements. And still, after all these years DIRAPI-105 keeps getting kicked down the road. So, after that ticket being open for nearly 7 years, I'm just wondering if I should give up hope? It's been quite a long road from the Mxx releases into the RC1 and RC2 and now 1.0.0 and still not supported. I'm really wanting to implement this authentication mechanism (actually, I am anyway) and I'd really like to use the Apache LDAP API but I'm stuck with simple binds if I do. I'm talking about projects which are pretty big US Navy programs of record where this feature would be very valuable. But I'm just thinking that I need to move on with life. Maybe look at Oracle Unified Directory or something else. Any ideas on that? Thanks, -- Frank
Re: Unavailable Cipher Suites
Le 16/11/2017 à 16:54, Frank Crow a écrit :
> I'm using Apache Directory Studio (which I assume is using the Apache LDAP
> API) and having an issue connecting due to (apparently) "unavailable cipher
> suites" with OpenLDAP.
>
> I created a self-signed CA using OpenSSL command line tools and have
> verified that the certificate (and even client-side certs signed by it)
> work without problems using all of the OpenLDAP applications. I've even
> successfully integrated it with Kerberos and SSSD with TLS/SSL.
>
> On some machines, the Apache Directory Studio works with my configuration
> no problem as well. However, on Windows and certain other Linux machines,
> it fails with "SSL Handshake Error".
>
> I added "-Djavax.net.debug=ssl:handshake" and was able to determine that
> the cipher suite that I'm using (ECDHE-RSA-AES256-GCM-SHA385) is output as
> an "unavailable cipher suite". It also looks like the only available
> cipher suites (listed later in the output) use AES128 or weaker algorithms.
>
> How can I get Apache Directory Studio to use updated cryptography libraries?
You most certainly have to install JCE, which offers AES 256 bit
scipher. It's not part of the standard JAVA JRE/SDK for US export policy
reasons.
("If stronger algorithms are needed (for example, AES with 256-bit
keys), the JCE Unlimited Strength Jurisdiction Policy Files
must be obtained and installed in the JDK/JRE.", from
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html
>
>
> Thanks,
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Unavailable Cipher Suites
I'm using Apache Directory Studio (which I assume is using the Apache LDAP API) and having an issue connecting due to (apparently) "unavailable cipher suites" with OpenLDAP. I created a self-signed CA using OpenSSL command line tools and have verified that the certificate (and even client-side certs signed by it) work without problems using all of the OpenLDAP applications. I've even successfully integrated it with Kerberos and SSSD with TLS/SSL. On some machines, the Apache Directory Studio works with my configuration no problem as well. However, on Windows and certain other Linux machines, it fails with "SSL Handshake Error". I added "-Djavax.net.debug=ssl:handshake" and was able to determine that the cipher suite that I'm using (ECDHE-RSA-AES256-GCM-SHA385) is output as an "unavailable cipher suite". It also looks like the only available cipher suites (listed later in the output) use AES128 or weaker algorithms. How can I get Apache Directory Studio to use updated cryptography libraries? Thanks, -- Frank
