OpenNebula

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.

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

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.

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

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.

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.

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.

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

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

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.

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

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

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

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.

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