[openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift
Dolph Mathews
dolph.mathews at gmail.com
Fri Feb 1 18:27:33 UTC 2013
It's not; we dropped it from the list of required attributes, but you can
still provide one.
-Dolph
On Fri, Feb 1, 2013 at 11:56 AM, Ali, Haneef <haneef.ali at hp.com> wrote:
> Are you sure that token contains email-address? I don't see that as
> required field in user creation in v3.
>
> Thanks
> Haneef
>
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
> Sent: Friday, February 01, 2013 3:06 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in
> Swift
>
> Since the token contains the email address of the user, isnt it possible
> to use this in the ACL?
>
> regards
>
> David
>
> On 23/01/2013 10:23, Alexandra Shulman-Peleg wrote:
> > Hi,
> >
> > I would like to get back to this discussion and specify the exact
> > syntax of ACLs that can be used when removing the global uniqueness
> > constraint on user names. I wander whether we really need to prefix
> > both the project_name and the username with the domain id? Especially,
> > since on ACLs we mainly need to properly identify the user and not the
> project.
> > So the notion of a project may not be required in this context? For
> > example, in NFSv4 ACLs (also adopted by CDMI) users are identified by
> > username at domain. So I wander whether on ACLs, in V3 we can simply
> > switch from tenant_id:username to domain_id:username? This seems to
> > fulfill the identification requirements and will give a very simple
> > solution for the migration of existing v2 customers to private domains
> > in V3 - assigning the new domain_id to match the old tenant_id will
> > allow preserving all of the stored containers without the need to
> > modify the containers' meta data.
> >
> > Best Regards,
> > Alex.
> >
> >
> >
> > From: "Yee, Guang" <guang.yee at hp.com>
> > To: OpenStack Development Mailing List
> > <openstack-dev at lists.openstack.org>,
> > Date: 11/01/2013 10:31 PM
> > Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API
> > domains in Swift
> > ----------------------------------------------------------------------
> > --
> >
> >
> >
> > As long as Swift URL stay the same we should be OK. Frankly, there
> > aren't any strong arguments for changing it at this point. Whenever we
> > remove the globally uniqueness constraint on names, new Swift ACLs
> > probably will need to switch over to using namespacing.
> >
> > domain_name.project_name:domain_name.username
> >
> > something like that. Existing Swift ACLs should work fine since if the
> > given domain is the default (migrated) system domain, auth_token
> > middleware should not set the domains headers.
> >
> >
> > Guang
> >
> >
> > -----Original Message-----
> > From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
> > Sent: Friday, January 11, 2013 8:36 AM
> > To: OpenStack Development Mailing List
> > Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API
> > domains in Swift
> >
> > Hi Chuck
> >
> > On 11/01/2013 15:59, Chuck Thier wrote:
> > > The Tenant_ID is in the URL
> > > (https://{SWIFT_IP}/v1/AUTH_{TENANT_ID}/{CONTAINER}/{OBJECT})
> > >
> > > I think we have beaten this part to death a bit now, as we seem to
> > all > agree that we can continue this pattern with the V3 API. The
> > one > concern that I still have is how the ACLs will work, and
> > weather or > not that will need to change.
> > >
> > > I'm also curious how the Keystone V3 API will work alongside V2 apis.
> >
> > My opinion (only, I dont speak for anyone else) is as follows:
> >
> > 1. A v2 API system has no problems as it is working OK today 2. A v3
> > API system only, with domains added, should work OK tomorrow otherwise
> > the v3 API has problems 3. So the main point as you say is how do v2
> > and v3 systems interwork. I suggest there is an intercept module, say
> > in the Keystone pipeline, that knows it is operating in a v2/v3
> > environment, and when it receives a v2 request already containing a
> > tenant_ID it knows it will comprise domain:project and it can unpack
> > it, and give the separate elements to the rest of the V3 code for
> > processing as in a v3 system. When the intercept module receives a v2
> > request that needs a tenant ID returning to it, it will encode up the
> > domain and project as a tenant ID, and return this to the v2 client.
> > The v2 client will be blissfully unaware that what it thinks is a
> > tenant ID is actually a combination of domain and project.
> >
> > regards
> >
> > david
> >
> >
> >
> > >
> > > --
> > > Chuck
> > >
> > > On Thu, Jan 10, 2013 at 4:16 AM, David Chadwick
> > <d.w.chadwick at kent.ac.uk>
> > wrote:
> > >> You have to ask, where does the Swift client get the tenant_Id from?
> > Isnt
> > it
> > >> Keystone? So if Keystone returns project_ID:tenant_Id to swift as
> > the >> project_id string, then Swift can continue to use this as if
> > nothing has >> changed. Its just a string whose content has no
> > meaning to Swift, but whose >> content does have meaning to Keystone.
> > The Swift policy simply needs to >> change the value of the tenant_id
> > in its policy to the new value and it >> should work the same >> >>
> > regards >> >> David >> >> >> On 09/01/2013 20:21, heckj wrote:
> > >>>
> > >>> Given that domains are a segmentation of projects/tenants, then I
> > wouldn't >>> expect to want to change it from a project_id
> > representation to anything >>> else.
> > >>>
> > >>> -joe
> > >>>
> > >>> On Jan 9, 2013, at 12:13 PM, Chuck Thier <cthier at gmail.com> wrote:
> > >>>>
> > >>>> Things are always easy, until you start thinking about backwards
> > >>>> compatibility. The storage urls for swift with keystone are
> > currently >>>> keyed off of the tenant_id (soon to be project_id), so
> > you end up with >>>> an endpoint url that looks something like >>>>
> > http://{SWIFT_IP}/v1/AUTH_{TENANT_ID} if you change that by adding
> > >>>> the domain, then you break any current users in your system, and
> > you >>>> can't use v2 and v3 auth contracts simultaneously.
> > >>>>
> > >>>> --
> > >>>> Chuck
> > >>>>
> > >>>> On Wed, Jan 9, 2013 at 1:37 PM, David Chadwick
> > <d.w.chadwick at kent.ac.uk> >>>> wrote:
> > >>>>>
> > >>>>> I would have thought that the solution is conceptually rather
> > >>>>> straightforward. If domains can have their own project names and
> > >>>>> usernames, >>>>> then you prefix the names with the domain ID
> > or domain name to make them >>>>> globally unique again.
> > >>>>>
> > >>>>> regards
> > >>>>>
> > >>>>> David
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 09/01/2013 19:14, Yee, Guang wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>> Yes. Swift ACLs <tenant_id>:<user_name>,
> > <tenant_id>:<user_name>, and >>>>>> *:<user_name> will be impacted if
> > project (formely tenant) name and >>>>>> user >>>>>> name are no
> > longer globally unique. We'll need to figure out a >>>>>> migration
> > >>>>>> path before relaxing that constraint.
> > >>>>>>
> > >>>>>>
> > >>>>>> Guang
> > >>>>>>
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Chuck Thier [mailto:cthier at gmail.com] >>>>>> Sent:
> > Wednesday, January 09, 2013 10:48 AM >>>>>> To: OpenStack Development
> > Mailing List >>>>>> Subject: Re: [openstack-dev] [swift] [keystone]
> > Keystone v3 API domains >>>>>> in >>>>>> Swift >>>>>> >>>>>> Se
> > responses inline:
> > >>>>>>
> > >>>>>> On Wed, Jan 9, 2013 at 4:01 AM, Henry Nash
> > <henryn at linux.vnet.ibm.com> >>>>>> wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> So there are a couple of issues intertwined in this thread:
> > >>>>>>>
> > >>>>>>> 1) Uniqueness of identifiers in Swift given the keystone
> > Identity v3 >>>>>>> api.
> > >>>>>>> This is the issue of whether Swift uses tenant names (now
> > called >>>>>>> project >>>>>>> names) at all to uniquely identify
> > any objects - if it did, then it >>>>>>> would >>>>>>> need to also
> > consider storing a domain name or id. From the >>>>>>> discussion,
> > >>>>>> >>>>>> >>>>>> it >>>>>>> >>>>>>> >>>>>>> sounds like
> > tenant/project ID is used instead, which (from a >>>>>>> uniqueness
> > >>>>>>> point of view) is fine. A separate issue exists needs to be
> > discussed >>>>>>> around swift ACLs and whether username potentially
> > becoming unique >>>>>>> only >>>>>>> within a domain will have an
> > impact.
> > >>>>>>>
> > >>>>>>
> > >>>>>> For AuthN, you are correct, in that it only relies on
> > tenant/project >>>>>> ID. So, nothing has to be changed from that
> > perspective. AuthZ is a >>>>>> little more tricky. For ACLs with
> > keystone, they are set as >>>>>> TENANT:USER in any of the following
> > patterns:
> > >>>>>>
> > >>>>>> *:user_name - that user from any tenant has access >>>>>>
> > tenant_id:user_name - that user from that tenant id has access >>>>>>
> > tenant_name:user_name - that user from that tenant name has access
> > >>>>>> >>>>>> If project_name will not be unique in v3, then the
> > >>>>>> tenant_name:user_name format may have to be deprecated.
> > >>>>>>
> > >>>>>> I would be interested to hear from providers that are using
> > keystone >>>>>> with swift and hear which of the above use cases they
> are using.
> > >>>>>>
> > >>>>>>
> > >>>>>>> 2) Given that keystone identity v3 domains are likely to be
> > usually >>>>>>> used >>>>>> >>>>>> >>>>>> to >>>>>>> >>>>>>>
> > >>>>>>> represent an enterprise (or "account holder" in common cloud
> > >>>>>>> terminology) >>>>>>> and contain the collection of projects
> > owned by that enterprise, is it >>>>>>> important for Swift to have
> > that domain knowledge? Will there be >>>>>> >>>>>> >>>>>>
> > operations >>>>>>> >>>>>>> >>>>>>> either within swift (or more
> > likely layered on top of swift) that need >>>>>> >>>>>> >>>>>> that
> > >>>>>>> >>>>>>> >>>>>>> information? E.g. How would someone layer a
> > billing engine on top of >>>>>> >>>>>> >>>>>> swift >>>>>>>
> > >>>>>>> >>>>>>> that could collate all the swift containers that were
> > part of one >>>>>>> domain?
> > >>>>>>> Obviously that engine could call keystone with each
> > project_id in turn >>>>>>> and >>>>>>> find the domain_id.....but
> > that sounds pretty inefficient.
> > >>>>>>>
> > >>>>>>
> > >>>>>> As is, containers can already be collated for a given
> > tenant/project >>>>>> id. The containers for a domain is then an
> > aggregate of the project >>>>>> ids associated to that domain.
> > >>>>>>
> > >>>>>> I think the default should be that domains are not mapped in
> swift.
> > I
> > >>>>>> believe that this will also be required to facilitate
> > backwards >>>>>> compatibility, which brings up another interesting
> > question -- Is >>>>>> there an expectation that people will be able
> > to run keystone auth >>>>>> v2.0 and v3.0 side by side?
> > >>>>>>
> > >>>>>> --
> > >>>>>> Chuck
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> 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
> > [attachment "smime.p7s" deleted by Alexandra Shulman-Peleg/Haifa/IBM]
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130201/3197aa58/attachment.html>
More information about the OpenStack-dev
mailing list