[openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift
David Chadwick
d.w.chadwick at kent.ac.uk
Tue Jan 8 20:53:00 UTC 2013
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
>
More information about the OpenStack-dev
mailing list