openstack team mailing list archive
Mailing list archive
Re: [Merge] lp:~mdragon/nova/multi-tenant-accounting into lp:nova
Taking this from the MP to ML for wider audience.
On Thu, Mar 03, 2011 at 11:29:43PM -0000, Monsyne Dragon wrote:
> > Actually, the OpenStack API only defines compute methods, it punts on
> > auth currently (as it should). There is no definitive "OpenStack Auth"
> > document or service right now, which is what all the recent chatter
> > is about. We need one, and we need a common service. This is bigger
> > than just OpenStack API in Nova.
> > While cloud servers uses token based auth, there is nothing saying we
> > need to. The OpenStack API in Nova could take a basic auth request
> > directly if the current middleware is replaced, which means there
> > is no service URL returned from the token validation (there is no
> > service URL, we're already at the service). There are other methods
> > of handling service URLs with methods without tokens such as a http
> > redirect, but it's not been discussed at all.
> Yah, I wasn't talking about the auth specifically. I was explaining that the openstack apis defined as being off of an endpoint found by some sort of service discovery, (in this case the url returned in the headers of the auth request.), thus changing that endpoint url will not break existing clients.
Getting into this a bit more, I'm not sure this is something that
should be the default. For CloudServers v1.0 token auth compatibility,
I'm not even sure this is the best path. It seems like this is
something that should be handled at the service level with the
API version, not by the token server. For v1.0, account=user from
token. For v1.1, just look at the path element for account.
Speaking for just OpenStack in general, I don't think we should
generate a token or provide a service URL (once we have a token server)
with a hard coded account ID. For example, If I authn with account
'eday' and I have access to two other accounts representing groups
in my org, 'dev' and 'production', should I really need two tokens
to interact with each? I think we should just have one token auth,
and then I get:
X-Auth-Groups: dev, production # probably not the best discovery mechanism
And then I can:
# Launch a server in my account
# Launch a server in production
# Launch a server in dev
# List all servers in my account and accounts I have access to
# Probably not the best method, but gets the idea out there
All this is done with the same token, I didn't need three tokens and
service URLs for each account I'm a part of.