[openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Adam Young
ayoung at redhat.com
Fri Jun 5 23:24:16 UTC 2015
On 06/05/2015 01:15 PM, Henry Nash wrote:
> I am sure I have missed something along the way, but can someone
> explain to me why we need this at all. Project names are unique
> within a domain, with the exception of the project that is acting as
> its domain (i.e. they can only every be two names clashing in a
> hierarchy at the domain level and below). So why isn’t specifying
> “is_domain=True/False” sufficient in an auth scope along with the
> project name?
The limitation of " Project names are unique within a domain" is
artificial and somethi8ng we should not be enforcing. Names should only
be unique within parent project.
This whole thing started by trying to distinguish a domain from a
project within that domain that both have the same name. We can special
case that, but it is not a great solution.
>
> Henry
>
>> On 5 Jun 2015, at 18:02, Adam Young <ayoung at redhat.com
>> <mailto:ayoung at redhat.com>> wrote:
>>
>> On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
>>> Hi David,
>>>
>>> There needs to be some form of global hierarchy delimiter - well
>>> more to the point there should be a common one across OpenStack
>>> installations to ensure we are providing a good and consistent (and
>>> more to the point inter-operable) experience to our users. I'm
>>> worried a custom defined delimiter (even at the domain level) is
>>> going to make it difficult to consume this data outside of the
>>> context of OpenStack (there are applications that are written to use
>>> the APIs directly).
>> We have one already. We are working JSON, and so instead of project
>> name being a string, it can be an array.
>>
>> Nothing else is backwards compatible. Nothing else will ensure we
>> don;t break exisiting deployments.
>>
>> Moving forward, we should support DNS notation, but it has to be an
>> opt in
>>
>>>
>>> The alternative is to explicitly list the delimiter in the project (
>>> e.g. {"hierarchy": {"delim": ".", "domain.project.project2"}} ). The
>>> additional need to look up the delimiter / set the delimiter when
>>> creating a domain is likely to make for a worse user experience than
>>> selecting one that is not different across installations.
>>>
>>> --Morgan
>>>
>>> On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
>>> <d.w.chadwick at kent.ac.uk <mailto:d.w.chadwick at kent.ac.uk>> wrote:
>>>
>>>
>>>
>>> On 03/06/2015 14:54, Henrique Truta wrote:
>>> > Hi David,
>>> >
>>> > You mean creating some kind of "delimiter" attribute in the domain
>>> > entity? That seems like a good idea, although it does not
>>> solve the
>>> > problem Morgan's mentioned that is the global hierarchy delimiter.
>>>
>>> There would be no global hierarchy delimiter. Each domain would
>>> define
>>> its own and this would be carried in the JSON as a separate
>>> parameter so
>>> that the recipient can tell how to parse hierarchical names
>>>
>>> David
>>>
>>> >
>>> > Henrique
>>> >
>>> > Em qua, 3 de jun de 2015 às 04:21, David Chadwick
>>> > <d.w.chadwick at kent.ac.uk <mailto:d.w.chadwick at kent.ac.uk>
>>> <mailto:d.w.chadwick at kent.ac.uk
>>> <mailto:d.w.chadwick at kent.ac.uk>>> escreveu:
>>> >
>>> >
>>> >
>>> > On 02/06/2015 23:34, Morgan Fainberg wrote:
>>> > > Hi Henrique,
>>> > >
>>> > > I don't think we need to specifically call out that we
>>> want a
>>> > domain, we
>>> > > should always reference the namespace as we do today.
>>> Basically, if we
>>> > > ask for a project name we need to also provide it's
>>> namespace (your
>>> > > option #1). This clearly lines up with how we handle
>>> projects in
>>> > domains
>>> > > today.
>>> > >
>>> > > I would, however, focus on how to represent the
>>> namespace in a single
>>> > > (usable) string. We've been delaying the work on this
>>> for a while
>>> > since
>>> > > we have historically not provided a clear way to delimit the
>>> > hierarchy.
>>> > > If we solve the issue with "what is the delimiter"
>>> between domain,
>>> > > project, and subdomain/subproject, we end up solving the
>>> usability
>>> >
>>> > why not allow the top level domain/project to define the
>>> delimiter for
>>> > its tree, and to carry the delimiter in the JSON as a new
>>> parameter.
>>> > That provides full flexibility for all languages and locales
>>> >
>>> > David
>>> >
>>> > > issues with proposal #1, and not breaking the current
>>> behavior you'd
>>> > > expect with implementing option #2 (which at face value
>>> feels to
>>> > be API
>>> > > incompatible/break of current behavior).
>>> > >
>>> > > Cheers,
>>> > > --Morgan
>>> > >
>>> > > On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
>>> > > <henriquecostatruta at gmail.com
>>> <mailto:henriquecostatruta at gmail.com>
>>> > <mailto:henriquecostatruta at gmail.com
>>> <mailto:henriquecostatruta at gmail.com>>
>>> > <mailto:henriquecostatruta at gmail.com
>>> <mailto:henriquecostatruta at gmail.com>
>>> > <mailto:henriquecostatruta at gmail.com
>>> <mailto:henriquecostatruta at gmail.com>>>> wrote:
>>> > >
>>> > > Hi folks,
>>> > >
>>> > >
>>> > > In Reseller[1], we’ll have the domains concept
>>> merged into
>>> > projects,
>>> > > that means that we will have projects that will
>>> behave as domains.
>>> > > Therefore, it will be possible to have two projects
>>> with the same
>>> > > name in a hierarchy, one being a domain and another
>>> being a
>>> > regular
>>> > > project. For instance, the following hierarchy will
>>> be valid:
>>> > >
>>> > > A - is_domain project, with domain A
>>> > >
>>> > > |
>>> > >
>>> > > B - project
>>> > >
>>> > > |
>>> > >
>>> > > A - project with domain A
>>> > >
>>> > >
>>> > > That hierarchy faces a problem when a user requests
>>> a project
>>> > scoped
>>> > > token by name, once she’ll pass “domain = ‘A’” and
>>> > project.name <http://project.name/> <http://project.name
>>> <http://project.name/>>
>>> > > <http://project.name <http://project.name/>> = “A”.
>>> Currently, we have no way to
>>> > > distinguish which project we are referring to. We
>>> have two
>>> > proposals
>>> > > for this.
>>> > >
>>> > >
>>> > > 1.
>>> > >
>>> > > Specify the whole hierarchy in the token request
>>> body, which
>>> > > means that when requesting a token for the child
>>> project for
>>> > > that hierarchy, we’ll have in the scope field
>>> something like:
>>> > >
>>> > > "project": {
>>> > > "domain": {
>>> > > "name": "A"
>>> > > },
>>> > > "name": [“A”', “B”, “A”]
>>> > > }
>>> > >
>>> > >
>>> > > If the project name is unique inside the domain
>>> (project “B”, for
>>> > > example), the hierarchy is optional.
>>> > >
>>> > >
>>> > > 2.
>>> > >
>>> > > When a conflict happen, always provide a token
>>> to the child
>>> > > project. That means that, in case we have a name
>>> clashing as
>>> > > described, it will only be possible to get a
>>> project scoped
>>> > > token to the is_domain project through its id.
>>> > >
>>> > >
>>> > >
>>> > > The former will give us more clarity and won’t
>>> create any more
>>> > > restrictions than we already have. As a con, we
>>> currently are not
>>> > > able to get the names of projects in the hierarchy
>>> above a given
>>> > > project. Although the latter seems to hurt fewer
>>> people, it
>>> > has the
>>> > > disadvantage of creating another set of constraints
>>> that might
>>> > > difficult the UX in the future.
>>> > >
>>> > >
>>> > > What do you think about that? We want to hear your
>>> oppinion, so we
>>> > > can discuss it at today’s Keystone Meeting.
>>> > >
>>> > >
>>> > > [1]
>>> > >
>>> >
>>> https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst
>>> > >
>>> > >
>>> > >
>>> >
>>> __________________________________________________________________________
>>> > > OpenStack Development Mailing List (not for usage
>>> questions)
>>> > > Unsubscribe:
>>> > >
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>> >
>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>>
>>> > >
>>> >
>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>>
>>> > >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> __________________________________________________________________________
>>> > > OpenStack Development Mailing List (not for usage questions)
>>> > > Unsubscribe:
>>> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>> >
>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>>
>>> > >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> > >
>>> >
>>> >
>>> __________________________________________________________________________
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>> >
>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> >
>>> __________________________________________________________________________
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150605/2843eee9/attachment.html>
More information about the OpenStack-dev
mailing list