OpenNebula

I take up this thread for following the discussion we had with Javi Fontan during OpenNebulaConf. He suggested an overhaul of the authentication layer. As a seed of the design discussion, I propose the following leads:

1. Keeping the OpenNebula architecture modularity and consistency with "pluggable" access driver. Why not an IAD (Identity Access Driver)?
2. Keeping as well the "per-user" authentication (why not even multiple way for a user. e.g. openID then ldap then db)
3. Introducing the concept of context. A context is an abstract class implemented according to the entry point (e.g. HTTP context for web browser, username/password context for general purpose, one_auth file context for command line...), passed to the IAD that himself would return another context (User context when user is logged, system context when a third party system is logged). This mechanism allows flexibility and extensibility such as impersonation or user proxying.
4. According to the entry point (sunstone, SSH, OCCI...) a series of control gate are available. E.g. sunstone has HTTP context and username/password, command line has one_auth file access and username/password.

Here is an example for a user authenticating on sunstone.

• 3 IAD registered on opennebula:

• OpenID IAD: driver accepting HTTP context (means that the driver is called at first HTTP GET without even prompting)
• LDAP IAD: driver accepting username/password context
• database driver: driver accepting username/password context

• User has 3 IAD set on his profile in a specific order: OpenID then LDAP.
• User connects to sunstone with web browser. Implicitly, since the OpenID is enabled in the configuration and implements the first control gate (HTTP context), it is called and look for OpenID token in the HTTP session.
• No OpenID token, the OpenID IAD returns null or an exception, next control gate prompts with the usual usual username/password form (that btw can also contain a button "connect with openID" that link to openid server) that once submitted calls in a specific user order (LDAP then database) the IAD implementing the username/password context that validates the authentication.

Please submit your remarks and views on this to move to implementation asap.
Thank you.

Hi

A couple of questions,

• We still need the user entry in the OpenNebula DB to store IAD list and preferences, right? In this sense the architecture is similar to the current authentication drivers, or not?

• As described this feature could be reformulated to support multiple authentication drivers per account, or I am missing something?

• We now have the login tokens, is that close to the context class right? Could we extend that to support driver specific tokens? http://docs.opennebula.org/4.10/administration/users_and_groups/manage_users.html#user-authentication

Cheers

Ruben S. Montero wrote:

Hi

A couple of questions,

• We still need the user entry in the OpenNebula DB to store IAD list and preferences, right? In this sense the architecture is similar to the current authentication drivers, or not?

Yes, right. Yes indeed but the authentication mechanism would more flexible since it would not be set by subsystem (sunstone, command line, occi...) but by user and called according to the context

• As described this feature could be reformulated to support multiple authentication drivers per account, or I am missing something?

exact.

• We now have the login tokens, is that close to the context class right? Could we extend that to support driver specific tokens? http://docs.opennebula.org/4.10/administration/users_and_groups/manage_users.html#user-authentication

login token could be a context itself (Token Context) handled by a proper IAD (Token IAD).

Cheers