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:23:57 GMT
Hi Emmanuel,

We can release faster too if people want to do that to get features faster
to users.  I'm fine with doing that if others are interested in it.

Alex

On 3/11/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> Enrique Rodriguez a écrit :
>
> > 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.
>
> yep. For 1.5.0, first, let's have SASL working with server.xml. ADS
> 1.5.1 is another question, you are right.
>
> >
> >> 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'
>
> I got to read RFC 4422, I guess ...
>
> >
> > 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.
>
> Yeah, I saw that.
>
> >
> > 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]
>
> ok.
>
> >
> >> 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.
>
> My point is that the less hard coded values we have in the code, the
> better. Storing infos in a real partition, loading them with a Ldif file
> (which is already an available option in ADS) seems easy and
> confortable. But at this point, again, let's do whatever necessary to
> have a 1.5.0 with SASL.
>
> Keep in mind that we want to deliver a 1.5.0 before end of march, if
> possible. If we can include SASL in it, that would be great. Otherwise,
> this will be for 1.5.1, so it's 2 to 3 months far in the future
> (hopefully for ApacheConEU, but this is not mandatory).
>
> >
> > Enrique
> >
>
>

Mime
View raw message