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.
Enrique Rodriguez a écrit :
> 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
> 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]
>> 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)
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).