On Mon, Feb 14, 2011 at 12:15 PM, Emmanuel Lecharny <elecha...@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<p...@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
