OpenNebula

After analyzing the problem, we have identified the possible problems derived from authenticating users. This needs to be taken into account if we want to avoid using passwords in clear text.

In the image, the arrows marks auth requests from different components. The red arrow can be secured using some sort of SSL proxy for the XMLRPC connections, so this is not an issue.

The blue arrow talks about the relation needed for the user to use its password to get an auth token. For this we use passwords in clear text, which is what we are trying to avoid. We have two choices:

1) save the file that stores the password in other format. If the file is stolen however, this offers the same protection as storing them in clear text. If we want to encrpyt it, then the user will need to enter the password each time it issues a request
2) create time expiring proxies using a password. this is our preferred solution, and it can be accomplished right now with the ssh auth module.
3) other mechanisms rather than proxies (like having a login/logout session). The problem is that we will need to rely on user discipline.

The problem with choice 2) (our preferred one) are what is depicted with black arrows in the image. There are components that need to authenticate with the core using the oneadmin account, for a variety of reasons. The problem about having time-expiring proxies for the oneadmin account is that it doesn't neatly apply to production environments, since these proxies will need to be manually updated.

Therefore we suggest a mix between 1) and 2), where 1) will apply to oneadmin account and 2) to the other, regular users.

implemented as ssh drivers