Open Stack

Has anybody thought of extending this notion of trust to pass access to objects in swift across tenants?
Limited read access say for a day/week etc, something that could be revoked.
This could provide a mechanism in OpenStack to support access to digital media .. pay per view style.

Regards
Malini

From: Dolph Mathews [mailto:dolph.mathews at gmail.com]
Sent: Friday, November 30, 2012 9:12 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Keystone] Trusts (Preauth) and LDAP


On Fri, Nov 30, 2012 at 8:53 AM, Adam Young <ayoung at redhat.com<mailto:ayoung at redhat.com>> wrote:
On 11/28/2012 11:05 AM, David Chadwick wrote:
Hi Adam

I have seen your spec and commented on it. This is yet another case of delegation is it not?
OK,  we've had a long discussion on this, and I think I can clarify.

1.  We've used "delegation" to mean many things.  I was using it to mean delegation from one Keystone server to another, in a(n) hierarchy. Maybe I am showing the effects of my time in the Army, but to me delegation is something that goes down from superiod to subordinate.

Federation?


2.  There are two related Legal terms I considered: Proxy and Trusts.  I ruled out the term "Proxy" due to its compete overuse.

3.  Regardless of whether we call it delegation or trust, we are discussing the same thing.

The concept is "delegating authorization to trusted entities," no? Modeling it in the API as a "trust" between "users" sounds fine to me.

>From David Chadwich"

"Keystone is the Delegation Service that handles all the delegations for users. It is trusted to ensure that

i) a delegator cannot delegate an attribute he has not already been assigned
ii) a delegator cannot delegate once the delegation depth has been consumed
iv) a delegator cannot delegate outside the validity period of his own delegation.

In other words, a delegator can only delegate less than (or equal to) what he already has, and not more than it. "

I think that is a great prelude to the design discussion.

Right now, a user delegates in a short term fashion using tokens. Once a token has been granted to a user, he hands that off to another (service) user in order to prove his identity and authorization to perform some set of actions.  In addition, since tokens are not scoped to a specific endpoint, they are currently passed on from one endpoint to another.  This is not a secure approach.  If any endpoint along the way is compromised, all the tokens in that endpoint are usable against any other service that accepts tokens.

So  we limit the scope of tokens to only that single endpoint, and we remove the attack.  As a result, we also remove the ability of the remote service user  to request additional operations from additional remote services on behalf of the original user.  This is a problem that the trusts are designed to serve.

A trust is a promise to allow delegation at some point in the future.  The actual delegation is performed in the token.  The trust is used to get the token.

Now,  as far as implementation goes, I would like to propose two phases.

1.  Trusts get implemented today "hard wired" with the attributes that are currently exposed in a token:  (trustor) user, tenant, roles, endpoints.
2.  Tokens that get generated from the trusts will look just like normal tokens.  They will have an additional field "trustee".  This will allow the current consumers of tokens to continue to use a trust token just like they do now.

Phase 2.
1.  Modify the token architecture to allow arbitrary sets of attributes.
2.  Modify the trust architecture to specify arbitrary sets of attributes to be used in a token.



Regarding my original question, I am going to move the trust driver into the token back end.  It has become apparent that this is where it belongs, as it has the exact same dependencies and usage patterns as the tokens, and it is the Keystone "application specific" data.







regards

David

On 28/11/2012 15:45, Adam Young wrote:
I have a very rudimentary Trust  (what I used to call Preauth
https://blueprints.launchpad.net/keystone/+spec/trusts) implementation
working with the SQL backend for Identity.

With LDAP, I am not sure where I would store the trust information. The
data for the trust itself is simply the uuid user_ids for the trustor
and  trustee and tenant Id.  There is also a table for the roles, and a
second table for the endpoints associated with the trust.While we could
shoehorn this into the user object, I am not sure that there is an
intuitive way to implement it in LDAP.

I see three choices.

1.  Leave the Trusts in the identity schema.  This has the nice effect
of keeping the user-ids as foreign keys.  It has the drawback of forcing
an LDAP backend solution.
2.  Move the Trusts into the Token backend.  This will get avoid the
issue of LDAP support.  It does mean that tokens, which is a schema that
is high volume, read intensive, and populated by short lifespan
entities, gets mixed with trusts, which is low volume, and long lived.
3. Move it into its own backend.  This seems a little heavy weight.


Thoughts?

_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121201/d81e180b/attachment.html>