SimpleDirContextAuthenticationStrategy and DefaultSpringSecurityContextSource should accept SSLSocketFactory

[marschall]

In order to support custom truststores more SSL configuration SimpleDirContextAuthenticationStrategy and DefaultSpringSecurityContextSource should accept a SSLSocketFactory.

This is a follow up for #494

[jakub-moravec]

This would be very helpful.

[jzheaux]

Hi, @marschall. I can see how this would be nice, but I'm not sure the underlying Java API supports it since ultimately the DirContext environment wants a class name, not a fully-constructed class in the java.naming.ldap.factory.socket environment property.

Is there a way that SimpleDirContextAuthenticationStrategy and DefaultSpringSecurityContextSource could accept a fully-constructed SSLSocketFactory?

[marschall]

Hi, @marschall. I can see how this would be nice, but I'm not sure the underlying Java API supports it since ultimately the DirContext environment wants a class name, not a fully-constructed class in the java.naming.ldap.factory.socket environment property.

Yes, that's a problem. There is discussion about this in #547. For a possible solution see https://github.com/marschall/ssl-socket-factory-factory-bean.

[jzheaux]

@marschall, sorry, I'm still not quite seeing how the factory bean helps in this situation. It may help in others, but in the cases listed in this ticket, the Java API asks for a class name. Having a factory construct the object still doesn't help since Java doesn't allow for specifying socket factory instances.

Does it sound like I'm missing something? If so, maybe it would help if you shared a code snippet of how DefaultSpringSecurityContextSource should change.

[jzheaux]

Jotting down a quick note to myself to test the following:

contextSource.setBaseEnvironmentProperties(Map.of("java.naming.ldap.factory.socket", CustomSslSocketFactory.class.getName()))

The possible drawback is the setting would apply to the anonymous and authenticated environments, which may not be desired.

Alternatively, SimpleDirContextAuthenticationStrategy could add a setter to post-process the Hashtable or perhaps a constructor.

It sort of begs the question of whether all DirContextAuthenticationStrategys should have a way to augment the hashtable, so a final way to consider is whether Spring Security can easily expose its wrapper authentication strategy and simplify post-processing through delegation.