OpenNebula

Requested on behalf of the EGI Federated Cloud Task Force -- http://www.egi.eu/infrastructure/cloud/

Hi

We've a couple of questions about the first item of this issue. In EGI's use case, Do we need to assign a given DN to just one user account? So do we need OpenNebula check that DN to user assignment is unique?.

About the second bullet we're thinking of using a simple encoding (URL).

BTW, there are other features for x509 underway like CRL support. And for federated authentication systems there is a SAML plugin, check #1731

Cheers

Ruben

Hi Ruben,

In EGI's use case, Do we need to assign a given DN to just one user account?
So do we need OpenNebula check that DN to user assignment is unique?

Since there is no consistent way to choose a specific user account to log into when using x509 authn, it would be useful to keep DNs unique and assigned to a single user account. Current approach works nicely for OCA shell utils since they generate a token and the token includes a username; but not with X509CloudAuth (e.g., Sunstone) and its 'username = get_username(cert.subject.to_s.delete("\s"))'.

So, to sum things up: X.509 authn in OpenNebula doesn't work consistently across all its APIs, in some of them you can pick a user account to log into, in some of them you cannot (and multiple users with the same DN will result in a First-come-First-served login). The 4.0 release might give you the opportunity to review/re-design/re-implement the authn subsystem and make it more consistent (supported globally across all APIs and GUIs). This would be definitely appreciated and would help with EGI's efforts.

About the second bullet we're thinking of using a simple encoding (URL).

That would be great but any fully reversible process would do. At the moment we have to keep a copy of user's DN in his properties to be able to identify him or her in a X.509-only environment.

Thank you.

Cheers, Boris

Ruben S. Montero wrote:

Hi

We've a couple of questions about the first item of this issue. In EGI's use case, Do we need to assign a given DN to just one user account? So do we need OpenNebula check that DN to user assignment is unique?.

About the second bullet we're thinking of using a simple encoding (URL).

BTW, there are other features for x509 underway like CRL support. And for federated authentication systems there is a SAML plugin, check #1731

Cheers

Ruben

There is one very dangerous practice used in the current implementation of get_username in src/cloud/common/CloudAuth.rb:

xpath = "USER[contains(PASSWORD, \"#{password}\")]/NAME"

you should never use contains(...) when selecting a single username based on the content of its password field since contains() is checking for substring matches. This is a big problem for X.509 authN. DN of one user could theoretically contain a DN of another user as a substring or one user can have multiple DNs that differ only in appended CN attributes (and we've encountered such a user in production, it's quite common).

Here is a simple (also a very slow fix) for this issue -- https://gist.github.com/arax/4722445

It is one of the reasons forcing me to file this request. Is there a possibility this will change in the future?

Thank you.

Here is an updated version of the fix (more ruby-esque)

# Gets the username associated with a password
# password:: _String_ the password
# [return] _Hash_ with the username
def get_username(password)
    xpath = "USER[PASSWORD=\"#{password}\"]/NAME" 
    username = retrieve_from_userpool(xpath)

    # No exact match, trying to match password with each
    # of the pipe-separated DNs stored in USER/PASSWORD
    if username.nil?
        @lock.synchronize {
            @user_pool.each { |user|
                return user["NAME"] if user["AUTH_DRIVER"] == "x509" && user["PASSWORD"].split('|').include?(password)
            }
        }
    end

    username
end

Is @lock.synchronize really necessary here? Nothing in this class is multi-threaded, @lock is an instance variable and it's not shared with any other class in a separate thread and multi-threading in Ruby is implemented within the Ruby interpreter (it won't create threads 1:1 on an OS level, except maybe on jRuby). Am I missing something?

Thank you.

Ruben S. Montero wrote:

Good catch!

We'll do our best to finish this before release 4.0 (Moved from request to feature). And thanks for the patch, this can be at least used to re-implement the method for X509Auth class.

Pasting the gist here for reference
[...]

Boris Parak wrote:

There is one very dangerous practice used in the current implementation of get_username in src/cloud/common/CloudAuth.rb:

xpath = "USER[contains(PASSWORD, \"#{password}\")]/NAME"

you should never use contains(...) when selecting a single username based on the content of its password field since contains() is checking for substring matches. This is a big problem for X.509 authN. DN of one user could theoretically contain a DN of another user as a substring or one user can have multiple DNs that differ only in appended CN attributes (and we've encountered such a user in production, it's quite common).

Here is a simple (also a very slow fix) for this issue -- https://gist.github.com/arax/4722445

It is one of the reasons forcing me to file this request. Is there a possibility this will change in the future?

Thank you.

Thanks. Yes an instance of this class is shared by Sinatra requests.
Boris Parak wrote:

Here is an updated version of the fix (more ruby-esque)

[...]

Is @lock.synchronize really necessary here? Nothing in this class is multi-threaded, @lock is an instance variable and it's not shared with any other class in a separate thread and multi-threading in Ruby is implemented within the Ruby interpreter (it won't create threads 1:1 on an OS level, except maybe on jRuby). Am I missing something?

Thank you.

Now the DNs are escaped using \<hex value> for space characters. I am not using + as this is a reserved character with meaning.

I've also changed a bit the get_username method. Now it searches for the dn substring using xpath (the each_with_xpath method) and only tries the users that match. Xpath search is done with rexml or nokogiri, this will make it much faster if nokogiri is installed.