[openstack-dev] [Keystone] Trusts (Preauth) and LDAP
Adam Young
ayoung at redhat.com
Thu Nov 29 15:22:04 UTC 2012
On 11/29/2012 09:59 AM, Dolph Mathews wrote:
> It seems like I should just have to know the User ID of the person
> that trusts me, not an ID of the relationship. I'm not even sure the
> relationship needs an ID, unless there's some metadata involved (e.g.
> expiration).
Hmmm, we could add that to the query interface. I want the trusts to be
immutable for audit purposes. If the end user changes the defintion of
the trust, to either add or remove a role, that should be a new trust
ID. We should always be able to go back and audit what roles and
endpoints were assigned to a trust when a given action was taken. I was
thinking that the user would register the trust ID with with remote
service when setting up the contract for some future action. The only
thing is if we want to be able to designate different trusts for
different actions by the same trustee.
>
>
> -Dolph
>
>
> On Thu, Nov 29, 2012 at 8:49 AM, Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
>
> On 11/28/2012 06:21 PM, heckj wrote:
>
> On Nov 28, 2012, at 2:53 PM, Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
>
> On 11/28/2012 05:23 PM, heckj wrote:
>
> To be a little more specific, what I'm trying to
> understand is the workflow beyond the initial request
> to a service with the trust concept already set up -
>
> Say Joe requests a snapshot to be taken of a volume,
> and wants that dumped into object storage. The service
> doing the snapshot takes a while (sorry, it's just
> slow) - and 30 minutes later the service (cinder in my
> little example) wants to write data to object storage
> (swift) - what allows this to happen? What
> interactions and with what data stored where?
>
> OK, let me get a better write up going. I'll try to post
> something in the next couple of days as far as how I think
> this is supposed to work, but the short form:
>
>
> user joe creates a trust. trustor is joe, trustee is
> cinder, tenant is joes_restaurant (eat at Joes!) and the
> role is what ever is required to write to swift, so we
> will call it swift_write.
>
> when cinder goes to perform the action for joe, it
> authenticates to keystone passing its service token and
> the trust id. In return, it gets back a token that has
> joe as the user_id, as well as all the other information
> specified by the trust. It uses that token to write to swift.
>
> So swift would have to be modified to know about trusts.
>
> swift or the auth_token middleware pieces?
>
>
> Swift. It has to know how to fetch the token to use for its call.
> Anything that is currently cacheing a userid/password in order to
> create a token will, in the future, use a Trust ID and its own
> credentials to get a token instead.
>
>
>
> so the APIs would be something like
>
> POST v3/trusts (create a new one)
> DELETE v3/trusts/<id> (create a new one)
> POST v3/tokens (get a token for a trust)
>
> But I'll write it up in more detail.
>
>
> On Nov 28, 2012, at 2:14 PM, heckj <heckj at mac.com
> <mailto:heckj at mac.com>> wrote:
>
> Hey Adam -
>
> so what I'm missing on all of this is
>
> 1) what's the API and how does a service and user
> interact with it?
>
> 2) what's the gist of the code - have it in a
> github repo or something to see your initial
> implementation?
>
> Trust, delegation, impersonation - whatever - the
> need that you laid out in your blog post is great.
> Glance and Nova have the exact same needs
> (the blog post isn't a spec, by the way - you
> should update the BP to point to something other
> than your motivations for making it)
>
> In terms of the choices, I'd like to see the API
> and how you've taken a stab at implementing it to
> suggest some possible solutions. With no other
> knowledge, I'm tempted to assert it should be it's
> own backend, even knowing that's relatively heavy
> weight.
>
> -joe
>
> On Nov 28, 2012, at 7:45 AM, Adam Young
> <ayoung at redhat.com <mailto:ayoung at redhat.com>> 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
> <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
> <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/20121129/abd6ecca/attachment.html>
More information about the OpenStack-dev
mailing list