Sorry for being MIA for so long.
+1 to merge all SASL + SSL + StartTLS code into protocol-ldap module removing the need for these tiny modules.
+1 to using server-unit to aggregate unit tests that work against the protocols.
Now I don't understand what's going on with ChainConfiguration. Are you using CoR pattern?
On 3/10/07, Emmanuel Lecharny < email@example.com> wrote:
> Enrique Rodriguez a écrit :
> > I know TODOs are bad, but I piled all the hardcoded
> > config with TODOs and comments there. From there the config can get
> > integrated into the core config/server.xml infrastructure.
> So basically, we can just feed the server.xml with a lot of new
> parameters. That would be the first option. What about going a step
> further, and adding those configuration parameters into the server ?
IMO, we should concentrate on getting SASL working and configurable.
A 1.5.1 with SASL support and Start TLS would be a good feature set to
have working. I would rather get this integrated into server.xml as
> Here are the parameters we would like to set :
> - mechanisms
> - saslHost (what will it be used for ?)
> - principal name
> - QoP
> - realms
> Is that all ?
We also need to specify user lookups, either by searching a base DN or
regex mapping directly to a DN. SASL is going to give us,
server-side, a username and possibly realm; for example:
CRAM-MD5: username = 'hnelson'
DIGEST-MD5: username = 'hnelson', realm = 'EXAMPLE.COM'
GSSAPI: username = ' hnelson@EXAMPLE.COM'
It is up to us to determine how to map those username forms to DN's in
the DIT for purposes of both (1) authenticating that user, meaning (a)
getting their userPassword or (b) Kerberos credentials and (2) getting
an LdapContext for them to use.
Other than that, yes, that is everything I can think of. As you
noticed, all of these are centralized in ConfigureChain with the
intent of moving them to XML config.
The "saslHost" is the hostname of the server. The issue here is that
it is transmitted during SASL negotiation and checked for a mismatch,
much like web server SSL certificates are checked to make sure the web
server name matches the cn attribute of the X.509 public certificate.
For example, with client-side JNDI, if your PROVIDER_URL doesn't match
the server's saslHost, you'll see:
javax.naming.AuthenticationException : [LDAP: error code 49 -
DIGEST-MD5: digest response format violation. Mismatched URI:
ldap/localhost; expecting: ldap/ldap.example.com]
> It would be good if we can put all these guys into the system partition,
> in dc=configuration, dc=system for instance. A
> dc=sasl-conf,dc=configuration, dc=system
> with some attributes like :
> mechanism: SIMPLE
> mechanism: CRAM-MD5
> mechanism: DIGEST-MD5
> mechanism: GSSAPI
> etc ...
A compromise here might be to only put RootDSE attributes in the DIT,
for now, since they are already only hard-coded config in
DefaultPartitionNexus, ie not in the Spring XML. Then Spring XML
would be used to override the "supported" mechanisms with the
Spring-configured "allowed" mechanisms, so admins can still disable
weak mechanisms if, for example, they are an all-GSSAPI (Kerberos)