[Engine-devel] Adding Authentication mechanism to oVirt

[Alon Bar-Lev]

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