5:47 p.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "Thierry Kauffmann" <thierry.kauffmann(a)univ-montp2.fr>, "Yaniv
Kaul" <ykaul(a)redhat.com>, "engine-devel"
<engine-devel(a)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.
>