[Engine-devel] Adding Authentication mechanism to oVirt

[Alon Bar-Lev]

----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Thierry Kauffmann" <thierry.kauffmann at univ-montp2.fr>, "Itamar Heim" <iheim at redhat.com>, "engine-devel"
> <engine-devel at ovirt.org>
> 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.

Active Directory support SASL with Diget-MD5, no need to support GSSAPI.

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