[openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift

Adam Young ayoung at redhat.com
Fri Feb 1 20:46:30 UTC 2013


On 02/01/2013 01:27 PM, Dolph Mathews wrote:
> It's not; we dropped it from the list of required attributes, but you 
> can still provide one.
According to GYee's latest submission, it would be in

  extra:{email:address}

But we haven;t yet nailed down that proposal



>
>
> -Dolph
>
>
> On Fri, Feb 1, 2013 at 11:56 AM, Ali, Haneef <haneef.ali at hp.com 
> <mailto: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
>     <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 <mailto:guang.yee at hp.com>>
>     > To: OpenStack Development Mailing List
>     > <openstack-dev at lists.openstack.org
>     <mailto: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
>     <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 <mailto: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
>     <mailto: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 <mailto: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
>     <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 <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto: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/17a82b0c/attachment.html>


More information about the OpenStack-dev mailing list