[Engine-devel] Adding Authentication mechanism to oVirt

Itamar Heim iheim at redhat.com
Wed Dec 12 23:43:19 UTC 2012


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?

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





More information about the Engine-devel mailing list