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	+_catalog = {"nova": [{"region": "nova",
292	+ "v1Default": "true",
293	+ "publicUrl": _url,
294	+ "privateUrl": _url}],
295	+ "swift": [{"region": "nova",
296	+ "v1Default": "true",
297	+ "publicUrl": _url,
298	+ "privateUrl": _url}],
299	+ "cdn": [{"region": "nova",
300	+ "v1Default": "true",
301	+ "publicUrl": _url,
302	+ "privateUrl": _url}]}

Clearly the above needs to be configurable. Also, what is "region"? Does this have to do with zones that Sandy is working on or something else? Apologies if the above was just for demo purposes and I'm reviewing in too much detail...

7)

In AuthnMiddleware.process_request(), I see that API.validate_token() is called, but I can't see where API.authenticate() is called.

8)

I would love to see authentication and authorization broken into two separate patches when you eventually propose for merging.

9)

When you propose for merging, I'd like to documentation on:
* How auth works, including how all the different driver/manager/service levels interact
* What the auth contact is. What are the expected inputs, what are the contractual outputs.

Cheers!
jay