Open Stack

Hi John

I dont think any of this affects what I was saying, since I was only 
talking about role names, not swift account names or anything else. What 
my proposal does is simply make role names potentially much longer.
Only global role names would be the same as now, whilst local role names 
would be much longer as they would be pre-pended with their domain and 
project IDs, thus making them globally unique again (though much longer).

regards

David


On 08/01/2013 21:40, John Dickinson wrote:
> Keep in mind that the storage url given to the user is unambiguous. That is, objects under a given storage URL are referenced by that URL and that URL alone. You cannot reference the same object with two different storage URLs.
>
> There are 5 parts of a storage URL in Swift:
>
> http://swift.example.com/v1/AUTH_abc/image/cats.jpg
>
> 1) http://swift.example.com -- the protocol and domain (all very standard)
>
> 2) v1 -- the Swift API version (always, so far, "v1")
>
> 3) AUTH_abc -- the Swift account.
> 	This has 2 parts, separated by the first underscore. "AUTH" is the reseller prefix and allows Swift to have multiple auth systems running on the same cluster. It's essentially a namespace for Swift accounts. The second part "abc" is the storage account (I guess the "tenant id" in keystone v2 terms) as understood by the auth system.
>
> 4) image -- a container (unique to a Swift account)
>
> 5) cats.jpg -- an object (the object name, and it may container additional "/"s)
>
> The Swift account, container, and object name are the unique representation of an object. It sounds like this may mean that the Swift account for Keystone users should contain both the domain ID and the project ID. I'm not sure where the role fits in, but if it has to do with access, then that belongs in the ACLs stored in Swift (and specifically not in any of parts 3-5 above).
>
> However, if the project id is globally unique, then the domain id probably doesn't need to be included in the Swift account string. The keystone middleware authtoken would need to map the project ID and auth token given in the request to a keystone identity. The keystonemiddleware (provided by swift) can then make the determination of authorization based on the data stored in the cluster (ie the ACLs on the container and/or object).
>
> If I'm correct, then I'd vote for the second option (http://swift/v1/AUTH_${PROJECT_ID}/) and for not including the domain id in the storage URL.
>
> --John
>
>
>
>
>
> On Jan 8, 2013, at 12:53 PM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>
>> Hi Alex
>>
>> I can agree with you but would go further, in that we need both global roles and local roles. So, if I specify
>>
>> https://swift/AUTH_>Test
>>
>> then I am specifying the Test global role, but if I specify
>>
>> https://swift/AUTH_>{DOMAIN_ID}_{PROJECT_ID}_Test
>>
>> I am specifying the role Test which is local to the project. Similarly
>>
>> https://swift/AUTH_>{DOMAIN_ID}_Test
>>
>> is the Test local role of the domain.
>>
>> These are unambiguous since the _ is the separator between domains and projects, rather like the . is the separator in domain names.
>>
>> Note, what you should not be able to do is specify
>>
>> https://swift/AUTH_>{PROJECT_ID}_Test
>>
>> as this would be ambiguous. Which domain does it refer to?
>>
>> regards
>>
>> David
>>
>>
>>
>> On 08/01/2013 20:11, Alexandra Shulman-Peleg wrote:
>>> I think that there is a problem with simply using https://SWIFT/AUTH_
>>> <https://swift/AUTH_>{PROJECT_ID}instead of the current
>>> https://SWIFT/AUTH_ <https://swift/AUTH_>{TENANT_ID} since it will loose
>>> the proper level in the hierarchy. We need something that will represent
>>> the hosted enterprises and this is the goal of domains. Project are more
>>> fine-grained and can represent departments or projects.  For example,
>>> following the description of Henry if two different enterprises with use
>>> the project name "Test" both with map to https://SWIFT/AUTH_
>>> <https://swift/AUTH_>Test.
>>>
>>> I think that we need to have both the domain id and the project id in
>>> the URL/account name. For example as https://SWIFT/AUTH_
>>> <https://swift/AUTH_>{DOMAIN_ID}_{PROJECT_ID} or as https://SWIFT/
>>> <https://swift/>{DOMAIN_ID}_{PROJECT_ID}. In the second option we may
>>> try using the existing reseller prefix mechanism to simplify the
>>> implementation. Having the doman_id in the account name/URL is important
>>> to isolate the accounts that belong to different domains and remove the
>>> requirements for the global uniqueness of project names.
>>>
>>> Best Regards,
>>> Alex.
>>>
>>>
>>>
>>> From: Chuck Thier <cthier at gmail.com>
>>> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>,
>>> Date: 08/01/2013 09:38 PM
>>> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains
>>> in        Swift
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> Hi Henry,
>>>
>>> >From a swift perspective, I think we are fine there, as we do not use
>>> the user name or project name anywhere.  At the moment, I'm thinking
>>> that we can do auth in a similar way as we did with v2.0 api.  An
>>> "account" in swift is still tied to the project_id (which used to be
>>> tennant_id), which is in the storage url like:
>>> https://SWIFT/AUTH_ <https://swift/AUTH_>{PROJECT_ID}.  Keystone
>>> middleware in swift
>>> validates that the given token has permission for the given Project
>>> ID.
>>>
>>> >From this point of view domains are an abstract concept in keystone
>>> only, and wouldn't mean anything directly in swift.
>>>
>>> Please let me know if any of my assumptions are incorrect.
>>>
>>> Thanks,
>>>
>>> --
>>> Chuck
>>>
>>> On Tue, Jan 8, 2013 at 1:23 PM, Henry Nash <henryn at linux.vnet.ibm.com>
>>> wrote:
>>>> Chuck,
>>>>
>>>> So user_id and project_id are always globally unique - so we are safe
>>> there.  The problem is when you specify user name or project name in the
>>> cases when we have to handle enterprises being represented by a domain
>>> and they insist that their name attributes (e.g. user names, project
>>> names etc.) be private to that domain (e.g. "what do you mean I can't
>>> call my project "Test" because some other customer in another domain got
>>> there first!?!").  See the following blueprint which introduces this
>>> ability as optional for domains: https://review.openstack.org/#/c/18805/
>>>>
>>>> For such domains, we cannot assume that user_name or project_name (or
>>> tenant_name as it used to be called) are globally unique.  "Domain_name
>>> (or id) plus user_name" as well as  "Domain_name (or id) plus
>>> project_name" will be unique however.
>>>>
>>>> Henry
>>>> On 8 Jan 2013, at 19:05, Chuck Thier wrote:
>>>>
>>>>> Yeah, I was hoping for more clarity, as it would help to figure out
>>>>> how to best map the concepts in swift.  A couple of quick questions
>>>>> come to mind.  When a request is validated, is the domain required, or
>>>>> is a user_id and project_id sufficient?  Is the concept of a domain
>>>>> useful in the context of swift?
>>>>>
>>>>> --
>>>>> Chuck
>>>>>
>>>>> On Tue, Jan 8, 2013 at 11:37 AM, heckj <heckj at mac.com> wrote:
>>>>>> The best is probably
>>> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md,
>>> but it's a bit light on use-cases around the concepts I'm afraid.
>>>>>>
>>>>>> -joe
>>>>>>
>>>>>> On Jan 8, 2013, at 9:19 AM, Chuck Thier <cthier at gmail.com> wrote:
>>>>>>> Is there documentation anywhere that defines all of these, and the use
>>>>>>> cases?  That would help us figure out how to map these concepts to
>>>>>>> swift.
>>>>>>>
>>>>>>> --
>>>>>>> Chuck
>>>>>>>
>>>>>>> On Tue, Jan 8, 2013 at 11:13 AM, Dolph Mathews
>>> <dolph.mathews at gmail.com> wrote:
>>>>>>>> I think it would be practical to expose the authenticated user's
>>> DOMAIN_ID
>>>>>>>> and DOMAIN_NAME into the request environment for the underlying
>>> service /
>>>>>>>> middleware to consume, as we do today with TENANT_ID /
>>> TENANT_NAME (soon to
>>>>>>>> be deprecated in favor of PROJECT_ID / PROJECT_NAME).
>>>>>>>>
>>>>>>>>
>>>>>>>> -Dolph
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jan 8, 2013 at 7:22 AM, Alexandra Shulman-Peleg
>>>>>>>> <SHULMANA at il.ibm.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> As most of you know, Keystone v3 API will introduce the notions of
>>>>>>>>> "domains" and "projects" which will replace the existing notion
>>> of tenants.
>>>>>>>>> It is important to allow using the same concepts in Swift. Since
>>> different
>>>>>>>>> domains may represent different companies, it is important to allow
>>>>>>>>> reflecting the Keystone "domain name" in the Swift "account
>>> name", providing
>>>>>>>>> an option to isolate the requests of different domains. Are
>>> there existing
>>>>>>>>> plans of adjusting Swift to Keystone v3 API? If not, I would
>>> like to start
>>>>>>>>> discussing the potential solutions.
>>>>>>>>>
>>>>>>>>> Thank you all,
>>>>>>>>> Alex.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------
>>>>>>>>> Alexandra Shulman-Peleg, PhD
>>>>>>>>> Storage Research, Cloud Platforms Dept.
>>>>>>>>> IBM Haifa Research Lab
>>>>>>>>> Tel: +972-3-7689530 | Fax: +972-3-7689545
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OpenStack-dev mailing list
>>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OpenStack-dev mailing list
>>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>