Re: [Engine-devel] Adding Authentication mechanism to oVirt

From: "Yaniv Kaul" <ykaul(a)redhat.com&gt; To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; Cc: "Thierry Kauffmann" <thierry.kauffmann(a)univ-montp2.fr&gt;, "Itamar Heim" <iheim(a)redhat.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt; Sent: Wednesday, December 12, 2012 7:18:18 PM 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. > 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. Except that Active Directory usually does not work (especially not out of the box) with certificates. Y.

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