Merge lp://qastaging/~anso/nova/authn_and_authz into lp://qastaging/~hudson-openstack/nova/trunk

This hasn't been rebased onto trunk yet, so there may be some spurious conflicts in the diff, we wanted the branch to remain intact while we work on it, we will resolve conflicts again before actually proposing for review. For the moment this is just to get launchpad to generate a bit of a diff so that people can look over the code more easily.

Hi guys!

I'm not sure how much specifics I should get into here, since you say it's mostly for discussion, so please excuse me if I have gone into too much of a discussion of the implementation details!

1) Any reason bin/nova-authn and bin/nova-authz don't use paste.config like the other bin/ servers?

2) It seems that bin/nova-authz was not completed? Am I missing something? I don't think that this code:

129 +if __name__ == '__main__':
130 + utils.default_flagfile()
131 + flags.FLAGS(sys.argv)
132 + logging.setup()
133 + service.serve()
134 + service.wait()

will work...

3) In bin/stack:

165 +gflags.DEFINE_string('password', 'user1', 'Direct API password')

We've run into some problems in the unit tests where the user and key were both "user1" :) Could we avoid problems by making the password "pass1" or something like that?

194 + if not token and authenticate_before:
195 + token = do_authenticate()

do_authenticate() returns token, but it returns it like so:

182 + rv = do_request('authn', 'authenticate', params,
183 + host=FLAGS.authn_host,
184 + port=FLAGS.authn_port,
185 + authenticate_before=False)
186 + return rv['auth']['token']['id']

This will raise KeyError if the authentication doesn't work, correct? Probably best to trap for this in do_request(). That said, I believe a better solution would be to have the do_request() call in do_authenticate() trap for the 401 that *should* be returned if a user does not authenticate, no?

4)

Have you guys taken a look at this blueprint: http://wiki.openstack.org/openstack-authn? Jorge and Khaled suggest using the X-Authorization header and mandating that the authentication service set the X-Identity-Status header. What were your thoughts on this?

5) In etc/nova-api.conf

226 +pipeline = logrequest authenticate authn adminrequest authorizer ec2executor

and:

245 +pipeline = faultwrap auth authn ratelimit osapiapp

Seems to be a be confusing having (authenticate and authn) or (auth and authn) in same pipeline...

6) About nova/api/authn.py

This file and its contents are difficult for me to understand. I have the following issues/questions about it:

287 +flags.DEFINE_string('authn_topic', 'authn', 'topic to listen for authn on')

Why are we adding more AMQP communication for authentication? Perhaps I'm just not understanding the various service/manager/driver/adapter abstractions going on here, but it seems odd to be delegating authentication requests to the message queue that another service is listening on?

304 +class AuthnManager(manager.Manager):
305 + """Manages token based authentication."""
306 + def __init__(self, auth_manager=None, *args, **kwargs):
307 + if not auth_manager:
308 + auth_manager = manager_auth.AuthManager()
309 + self.auth_manager = auth_manager
310 + super(AuthnManager, self).__init__(*args, **kwargs)

So, we have an AuthnManager that inherits from manager.Manager and yet has a self.auth_manager member that is a manager_auth.AuthManager? Yikes, that just got really confusing. Could we document this relationship in code comments? I'm having a really tough time understanding how all the managers relate to each other.

290 +_url = "http://127.0.0.1:9001"
291 +_cat...