Open Stack

yes, once you recognise that this is actually delegation, and that 
delegation can be recursive, then it is quite easy to extend the current 
system to support delegation chains. I have sent my ideas to Adam for 
him to incorporate in the spec

regards

David


On 01/12/2012 07:13, Bhandaru, Malini K wrote:
> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>