Open Stack

On 12/01/2012 02:13 AM, 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.
>

Yes, this is the kind of use case we want to support.  I was not 
originally going to put a time out in the trust, but it looks like there 
is enough of demand for it that I will add it in.

> 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

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