directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [LDAP] Merging server-ssl with protocol-ldap
Date Sun, 11 Mar 2007 23:13:28 GMT
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