Open Stack

On 11/14/2013 10:03 AM, Steven Hardy wrote:
> On Wed, Nov 13, 2013 at 10:04:04AM -0600, Dolph Mathews wrote:
>> I guarantee there's a few things I'm forgetting, but this is my collection
>> of things we discussed at the summit and determined to be good things to
>> pursue during the icehouse timeframe. The contents represent a high level
>> mix of etherpad conclusions and hallway meetings.
>>
>> https://gist.github.com/dolph/7366031
> Looks good, but I have some feedback on items which were discussed (either
> in the delegation session or in the hallway with ayoung/jlennox), and are
> high priority for Heat, I don't see these captured in the page above:
>
> Delegation:
> - Need a way to create a secret derived from a trust (natively, not via
>    ec2tokens extension), and it needs to be configurable such that it
>    won't expire, or has a very long expiry time. ayoung mentioned a
>    credential mechanism, but I'm not sure which BP he was referring to, so
>    clarification appreciated.
I am not sure this is pointing the right direction.  Trusts assume 
authentication from an separate source, like the token the trustee 
passes in when executing the trust.  Long term credentials should be 
used in conjunction with a trust, but separate to it.  I suspect that 
there is something that could be done with X509, Trusts, and Token 
Binding that would make sense here.

Something like:

1.  Identify client machine
2.  Generate new Cert for Client machice (Key stays on client, gets 
signed by CA)
3.  Generate trust, and link trust to new cert.
4.  Client machine uses cert and trust to get tokens.




>
> Client:
> - We need a way to get the role-tenant pairs (not just the tenant-less
>    role list) into the request context, so we can correctly scope API
>    requests.  I raised this bug:
A token is scoped to something;  project, domain, whatever. Providing 
tokens that are scoped wider is somewhat suspect.  What you want to do 
is to query the data from Keystone using an unscoped token.  But any 
token from a user sent back to Keystone (except a trust token) should be 
able to access this information.

Put another way: you need to query the role information for additional 
requests to Keystone.  A token is specifically for proving that you have 
access to the information to a third party. Since anything that is going 
to be done with this information is going to be validated by Keystone,  
it is OK to do it as a query against Keystone itself.

So, I think what you want is a way to query all roles for a user on all 
projects in all domains.  This can be done taody doing individual calls 
(enumerate domains, enumerat projects)  which is chatty.  If it proves 
to be a performance bottleneck, we can optimize it into a single call.

>
>    https://bugs.launchpad.net/python-keystoneclient/+bug/1250982
>
>    Related to this thread (reminder - which you said you'd respond to ;):
>
>    http://lists.openstack.org/pipermail/openstack-dev/2013-November/018201.html
>
>    This topic came up again today related to tenant-scoped nova flavors:
>
>    http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.html
>
>    Closely related to this bug I think:
>
>    https://bugs.launchpad.net/keystone/+bug/968696
>
>    I'd welcome discussion on how we solve the request-scoping issue
>    openstack-wide, currently I'm thinking we need the role-tenant pairs (and
>    probably role-domain pairs) in the request context, so we can correctly
>    filter in the model_query when querying the DB while servicing the
>    API request.
>
> Thanks,
>
> Steve
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev