directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [Shared] [LDAP API] Additional classes and method arguments for GSSAPI binds
Date Mon, 14 Feb 2011 16:29:06 GMT
On Mon, Feb 14, 2011 at 12:15 PM, Emmanuel Lecharny <elecharny@gmail.com>wrote:

> 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 !


How about naming this branch 1.0 and that way we don't have to keep changing
the name with every RC or milestone release we have?

Regards,
Alex

Mime
View raw message