directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [LDAP] Merging server-ssl with protocol-ldap
Date Sun, 11 Mar 2007 23:21:05 GMT
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?

Alex

On 3/11/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
>
> On 3/10/07, Emmanuel Lecharny <elecharny@gmail.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
> Spring config.
>
> > 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)
> site.
>
> Enrique
>

Mime
View raw message