----- Original Message ----- > From: "Itamar Heim" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Thierry Kauffmann" <[email protected]>, "Yaniv Kaul" > <[email protected]>, "engine-devel" > <[email protected]> > Sent: Thursday, December 13, 2012 1:43:19 AM > Subject: Re: Adding Authentication mechanism to oVirt > > On 12/12/2012 06:53 PM, Alon Bar-Lev wrote: > > Hello Thierry, > > > > If I understand correctly you wish to help in modifying the engine > > to support non GSSAPI authentication methods. > > > > Following is a quick design goals for this implementation. > > > > I will be glad to improve this. > > thanks for writing this part. > what about making the LDAP part plugable, or at least > scheme-configurable to cover openLDAP, or any other source (atlassian > crowd), or well, anything?
I thought our primary goal is to reduce the noise around the kerberos. Doing a complete re-write (aka modular) will consume far more resources and time. It also touches many part of the implementation instead of only the LDAP context and authentication. > > thanks, > Itamar > > > Alon > > > > --- > > > > Implementation should support the following transports: > > > > 1. LDAP (plain). > > 2. LDAP over TLS. > > 3. LDAP with StartTLS. > > > > Implementation should support the following authentication methods: > > > > 1. Simple. > > 2. Digest-MD5 (plain and strong). > > > > I believe the GSSAPI can be dropped, I see no advantage of using > > it. > > > > A sample of low level implementation for transport and > > authentication is attached. > > > > When adding a domain the following facts should be provided: > > > > 1. Search user name. > > 2. Search user password. > > 3. Transport type (ldap, ldaps, ldap+startTLS) > > 4. Authentication (simple, Digest-MD5) > > 5. Sever selection policy (failover, round-robin, random). > > 6. Server address type (explicit, DNS record) > > 7. Server address set. > > 8. Optional base DN. > > 9. Optional root certificate. > > 10. Optional certificate chain. > > 11. Search page size. > > 10. Query timeout. > > etc... > > > > Within product there are two separate components that perform LDAP > > authentication: > > > > 1. User password validation. > > 2. User permission fetch. > > > > These two components needs to work in share-nothing mode, meaning > > that each should communicate with directory independently with the > > other. > > > > USER PASSWORD VALIDATION > > > > Input: user > > Input: domain > > Input: password > > Output: DN of user > > Output: success/failure > > Credentials used: user/password provided. > > Notes: LDAP session should not be cached. > > Logic: Perform LDAP bind. > > > > USER PERMISSION FETCH > > > > Input: DN of user (passed by user password validation) > > Input: domain (passed by user password validation) > > Output: A set of permissions > > Credentials used: search user and password configured within > > system. > > Notes: LDAP context can be cached. > > Logic: Perform LDAP searches, this is most of current logic. > > > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
