Open Stack

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
>