[openstack-dev] [Keystone] Trusts (Preauth) and LDAP
Adam Young
ayoung at redhat.com
Mon Dec 3 02:01:29 UTC 2012
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>
More information about the OpenStack-dev
mailing list