directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [Shared] [LDAP API] Additional classes and method arguments for GSSAPI binds
Date Mon, 14 Feb 2011 10:15:22 GMT
On 2/14/11 11:05 AM, Stefan Seelmann wrote:
> On Mon, Feb 14, 2011 at 9:05 AM, Pierre-Arnaud Marcelot<pa@marcelot.net>  wrote:
>> Hi Dev,
>> These last days, I've been reviewing Authentication in Studio using the LDAP
>> API.
>> I'm happy to say that all the Authentication methods that were supported in
>> Studio with JNDI are also working (not yet with the same options, though)
>> with the LDAP API integrated in Studio.
>> This includes:
>> - All encryption methods
>>      - No encryption
>>      - SSL encryption (LDAPS)
>>      - StartTLS via exended operation
>> - All authentication methods
>>      - No authentication (anonymous)
>>      - Simple authentication
>>      - DIGEST-MD5 (SASL)
>>      - CRAM-MD5 (SASL)
>>      - GSSAPI (Kerberos)
>> That said, there are still some options which are not (yet) available in the
>> LDAP API for some authentication methods (specifically SASL and GSSAPI)
>> like:
>> - For SASL
>>      - Quality of Protection
>>      - Protection Strength
>>      - Mutual Authentication
>> - For Kerberos
>>      - Use native TGT for Kerberos Credential Configuration
>>      - Use native system configuration
>>      - Use a specific configuration file
>> All these new settings will increase the, already long, list
>> of parameters for the SASL and GSSAPI methods.
>> To resolve that, I'd like to add new classes that will hold all these
>> informations and can be passed to the SASL and GSSAPI methods.
>> We could keep one or two general methods for each type of authentication
>> with the most commonly used parameters and a more generic approach with the
>> use of these new "configuration holder" classes.
>> Thoughts?
> +1 to use a parameter object
>
>> One more question.
>> Should we push this into Shared-1.0.0-M1 or wait for the next iteration?
> Too late, vote already started. But maybe we need to rollback ;-)

No, let's push all the move to the M2 branch (which has to be renamed, 
btw, it's M1 atm)

We will have lots of modifications in the API in M2 anyway, so don't 
worry too much. M1 != API freeze !


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message