Feature #521

X509 Authorization

Added by Ted Hesselroth over 8 years ago. Updated about 8 years ago.

Status:ClosedStart date:07/28/2011
Priority:NormalDue date:07/28/2011
Assignee:Javi Fontan% Done:

0%

Category:Drivers - Auth
Target version:Release 3.0
Resolution:fixed Pull request:

Description

Here are patches for adding X509 authorization to OpenNebula 2.2, made from a checkout of the head today.

One functionality allows users to make an OpenNebula login from an X509 proxy. This uses the authorization plugin format and a file called x509_auth.rb. Since cryptography is used rather than a password, the user's DN should be placed in the password field of the user pool. Thus the code authenticates the user based on the provided certificate information, and authorizes the user based on the presence of the DN the the user pool.

Another functionality allows authorization for the EC2 query interface based on an X509 certificate that is loaded into a browser. This requires an https proxy to handle requests for the OpenNebula econe server. Apache may used for the proxy; the ssl.conf file is attached. The user certificate is then available in the http header. In the econe server code, the users DN is extracted from the certificate, and the DN is checked by x509_auth.rb to authorize the user.

A third functionality allows a admin login to be created based on the host certificate of the OpenNebula server. This prevents an admin login from being created without root access to the server.

For the query interface, tests were done using curl commands. Examples of the commands are attached.

X509authz.tar.gz - Patches to add X509 Authorization to OpenNebula 2.2 (40 KB) Ted Hesselroth, 03/09/2011 10:19 PM

querytest.txt Magnifier - Example curl commands to test OpenNebula query interface (1.9 KB) Ted Hesselroth, 03/09/2011 10:19 PM

ssl.conf - Configuration file for apache https proxy (3.64 KB) Ted Hesselroth, 03/09/2011 10:19 PM

X509authz-110503.tar.gz (9.07 KB) Ted Hesselroth, 05/03/2011 04:48 PM

0002-Add-x509_login-and-host_login-functions.patch Magnifier (14.8 KB) Ted Hesselroth, 05/03/2011 06:48 PM

X509authz-110506.tar.gz (10.1 KB) Ted Hesselroth, 05/06/2011 06:34 PM

X509authz-110510.tar.gz (9.92 KB) Ted Hesselroth, 05/10/2011 03:27 PM

x509-multiple-dns.tar.gz (3.69 KB) Ted Hesselroth, 06/06/2011 04:39 PM

0001-Send-DN-in-host-signed-token-instead-of-password-dig.patch Magnifier (9.15 KB) Ted Hesselroth, 06/13/2011 08:32 PM

0001-Merge-of-feature-521-into-feature-667.-Resolved-conf.patch Magnifier (13.4 KB) Ted Hesselroth, 07/07/2011 04:22 PM

X509-cert-chain-patches.tar.gz - Patch to authorize based on client certificate chain. (2.56 KB) Ted Hesselroth, 07/21/2011 04:58 PM

0001-Authorize-based-on-certificate-chain.patch Magnifier (4.05 KB) Ted Hesselroth, 07/21/2011 09:48 PM


Related issues

Follows Feature #754: Update Auth Drivers to make use of the new ACL engine Closed 07/27/2011

History

#1 Updated by Ruben S. Montero over 8 years ago

  • Category set to Drivers - Auth
  • Assignee set to Javi Fontan
  • Target version set to Release 3.0

This is for the next release. THANKS FOR THIS CONTRIBUTION! :)

#2 Updated by Ted Hesselroth over 8 years ago

I updated a few of the patches so that they could be a applied to the current head. They also apply to the current 2.2 branch.

I have also added a patch to allow the Sunstone server to use X509 authorization if the user credentials are found in the http header.

#3 Updated by Ted Hesselroth over 8 years ago

Please use this for the x509_auth.rb patch, instead of the one included in the latest tarball.

#4 Updated by Javi Fontan over 8 years ago

Thanks for your contribution, we feel that this functionality is really nice and we feel it is better to add it to the main code base. We still have some comments on the patches:

  • It would be nice to have a switch on oned configuration file so oneadmin could be authenticated by the core (as it is done now) or by the one_auth module. The idea is to get rid of the host_signed check in the core, as this is specific of the x509 driver. If it is still needed when oneadmin is requesting the authentication on behalf other user as in the cloud services, we can keep it (plain:auth_delegate:...) for example, but just for the driver.
  • Also a switch to use X509 in cloud layers is needed so there is only one code base to maintain
  • Match the license of the files to the rest of the source code. That way there's only one license to read when downloading/using the software. Your contributions will be noted in NOTICE file.
  • Make oneadmin use custom certificates (the secret key cannot be encrypted). In this case you can "protect" the host_certificates from oneadmin, as this could be an strong requirement if those certs are being used by other services.

Tell me what you think about this. Maybe I fail to see something as I am not really used to the patches you've sent.

#5 Updated by Ted Hesselroth over 8 years ago

  • I'll work on replacing the detection of the host_signed check with a configuration parameter.
  • In the cloud layers, instead of a switch the server looks for the user credentials in the http header. If none are found, the usual secret key ID, secret key auth is used. That way, both mechanisms are supported at the same time. The new X509 code in econe-server and Sunstone should have no effect on those who are using the secret key auth method. So I don't think there needs to be another code base.
  • There is only one new file, x509_auth.rb, so I will add the license to that.
  • I'll make a change so that the host cert files can be specified.

#6 Updated by Javi Fontan over 8 years ago

We can open a branch for these developments and we can also help you on integrating these features in the main codebase. We think we are better suited to check the core modifications but tell us if you need any help in other parts of the module.

If you think on any other way of cooperation please tell us.

#7 Updated by Javi Fontan over 8 years ago

I have created the branch feature-521 branch for this feature code. I will add your patches to it an also our changes:

  • Changes to the core to accomodate this features
  • URL encode user strings so they don't cause problems to the database or the API internals

#8 Updated by Ted Hesselroth over 8 years ago

Here are the patches with the changes as described in my last update. To specify the host or service cert and key, and the ca certificates directory, use optional lines in auth.conf, as follows

:database: sqlite://auth.db
:authentication: x509
:hostcert: /etc/grid-security/hostcert.pem
:hostkey: /etc/grid-security/hostkey.pem
:ca_directory: /etc/grid-security/certificates
:authorization: dn
:quota:
:enabled: false
:defaults:
:cpu: 10.0
:memory: 1048576

Instead of detecting host-signed in the token, a configuration parameter is now used. Add this line to oned.conf:

USE_AUTH_MAD_FOR_ADMIN = true

I have tested all the functionality on my own machine, and the patch and build process and basic functionality on our test stand. I think I will need to submit some documentation for 2.4.

#9 Updated by Ted Hesselroth over 8 years ago

Though I made my changes against the head, I am sure they will apply to the new feature-521 branch. When you have completed your tests and changes, or need some further changes from us, we will check it out and start using it on our test stand.

#10 Updated by Javi Fontan over 8 years ago

The new branch is created from the head so this should not be a problem. I am going to apply the last set of patches you have sent so we can work from the same state.

#11 Updated by Javi Fontan over 8 years ago

I've been trying to apply the patches you sent and the don't apply, specifically 0006. Do you have a public repo where I can check what it is happening or can you recreate the patches? I will be traveling from tomorrow to the end of the week but I'll try to work a bit on this.

#12 Updated by Ted Hesselroth over 8 years ago

Looks like some files changed between the time I did my checkout and the time you made the new branch. Here is a new set of patches based on a fresh checkout of the feature-521 branch.

#13 Updated by Javi Fontan over 8 years ago

Now they apply nicely, the patches are commited to the branch.

#14 Updated by Ted Hesselroth over 8 years ago

Here are more patches. They fix these problems:

1. The use of service certificates is now supported in EC2Query and Sunstone.
2. Mapping of multiple DNs to one user is now supported in EC2Query and Sunstone.
3. Fixed problem with signing a long string of multple DNs. Now the digest is signed instead.

#15 Updated by Ted Hesselroth over 8 years ago

This patch replaces the solution of number 3 of the last patch (see above). Instead of signing the digest of multiple DNs, only the user's DN is signed. This is simpler and makes x509_auth.rb consistent with the method used for command-line authorization.

#16 Updated by Ted Hesselroth over 8 years ago

This patch encapsulates the merge of branch feature-521 into branch feature-667. Conflicts between the two branches were resolved in four files. It can be applied by doing

git checkout feature-667
git apply 0001-Merge-...

#17 Updated by Javi Fontan over 8 years ago

Applying this patch changes nothing in my machine and gives no errors appart from some white space warnings.

Ted Hesselroth wrote:

This patch encapsulates the merge of branch feature-521 into branch feature-667. Conflicts between the two branches were resolved in four files. It can be applied by doing

git checkout feature-667
git apply 0001-Merge-...

#18 Updated by Ted Hesselroth over 8 years ago

git status should show the changed files

  1. modified: src/authm_mad/oneauth
  2. modified: src/scheduler/src/client/Client.cc
  3. modified: src/sunstone/models/SunstoneServer.rb
  4. modified: src/sunstone/sunstone-server.rb

For example, to oneauth is added the x509_login and host_login functions, which are not in the feature-667 branch.

#19 Updated by Javi Fontan over 8 years ago

I've just applied the path using git am, don't know what was happening with git apply. Thanks a lot for the patches!

#20 Updated by Ted Hesselroth about 8 years ago

This patch adds to EC2QueryServer the feature of authorizing based on the client certificate chain, instead of simply the first certificate presented. This allows supporting delegated credentials and temporary proxy certs. We anticipate using this in a grid context.

There is no corresponding patch for SunstoneServer, since web browsers cannot import such certificates. For EC2QueryServer, the client commands will be sent using the curl library, which can present proxy certs.

There are three other patches included, that were required by my to make the branch work. I am on the feature-667 branch with the above "Resolved-conf" patch applied, followed by a "git pull". Doing the latter caused a few things to break. Patch 0003 is a suitable fix, but patches 0002 and 0004 are workarounds and you may wish to examine the code more closely.

#21 Updated by Ted Hesselroth about 8 years ago

Please use this patch in place of the corresponding on the the above X509-cert-chain-patches.tar.gz.

#22 Updated by Ted Hesselroth about 8 years ago

I have merged all the X509 code into the head and pushed that to a Fermilab git repository, branch x509-1. The following worked to merge my changes back into the OpenNebula repository.

git clone git://git.opennebula.org/one.git
cd one
git remote add fermilab http://cdcvs.fnal.gov/projects/onex509
git fetch fermilab
git merge fermilab/x509-1

#23 Updated by Ruben S. Montero about 8 years ago

Thanks Ted, The external auth system is missing some parts in 3.0beta1 because of the new auth subsystem. Now most of it is in place, we've made some changes in the driver. Now you can specify the authN module as part of the token like user:ssh:token, user:dummy:token, user:plain:token or user:x509:token. I'll merge your changes in a week or so.

(there is still some work to be done in the core, e.g. use auth driver for oneadmin)

Anyway thanks again for the merge that would be very helpful!!!

Ruben

#24 Updated by Ted Hesselroth about 8 years ago

That's good. I would note that in the current X509 code for a user the login is of the form

user:plain:token

so I hope that the new auth subsystem will prevent any hashing when either "plain" or "x509" is in the second field.

There is also a host-signed login which currently has the form

user:plain:host-signed:token

so the new auth subsystem should also prevent any hashing for "host-signed", and the second field can be removed.

I like the new flexibility of having more than one auth mechanism available at one time. This will help in our migration from plain to X509.

#25 Updated by Ruben S. Montero about 8 years ago

Yes in fact we do not hash if there are more than one ':' So basically we have now:

  • user:passwd (this one is hashed, and reserved for ONE internal auth)
  • user:protocol:token (this is not hashed, and token may contain additional tokens with : or in any other format defined by the auth driver).

Using the protocol string we look for the corresponding driver...

Cheers

#26 Updated by Ruben S. Montero about 8 years ago

  • Status changed from New to Closed
  • Resolution set to fixed

Changes to EC2 servers needs to be done, but other issue will be opened for that development

Also available in: Atom PDF