openstack team mailing list archive

[Monsyne Dragon <mdragon@xxxxxxxxxxxxx>]

On 3/3/11 5:51 PM, Eric Day wrote:
> 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.
sorry, a bit confused...   "I'm not even sure this is the best path"...  
'this' == ?  (mental buffer overflow here...)
> 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:
[example trimmed]

in the case of the v1.1 api, yes, that would be much preferred. Simply 
spec the account as part of the url for the api, thus the token is an 
auth for a given user, on whatever account he has access to.

(actually, I just thought of another problem w/ our current service url, 
too, namely, we include the version identifier in the 
server-management-url :P )

The mergeprop I have is for fixing the v1.0 api to work the way 
CloudServers currently does, so we can inject an account identifier, 
without breaking current clients.
We haven't really started implementing the v1.1 api yet, and that isn't 
going to make cactus.


--

--
    -Monsyne Dragon
    work:         210-312-4190
    mobile        210-441-0965
    google voice: 210-338-0336



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.