Open Stack

You can't delegate something you don't have. Both trustee and trustor IDs
are on the token so you should be able to use that information accordingly.

As for authentication policies, the second part of your BP, we also have
similar requirements (i.e. returning different token based on the mechanism
in which the user is authenticated.) Hopefully, we'll be addressing that in
the very near future.


Guang


-----Original Message-----
From: Mark Washenberger [mailto:mark.washenberger at markwash.net] 
Sent: Monday, December 10, 2012 11:42 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Keystone] Trusts and Explicit Impersonation

So, in the case of this feature, the trustor (end user) is going to
delegate to the trustee (Glance) a role that the trustor himself does
not have? (Namely, some role that allows image uploads.) That seems to
violate the spirit of the the spec.

I must be missing something. Thanks in advance for correcting me!

markwash

On Mon, Dec 10, 2012 at 10:56 AM, Yee, Guang <guang.yee at hp.com> wrote:
> I think the current trust BP should cover your use case.
>
> http://wiki.openstack.org/Keystone/Trusts
>
> In your case, the trustee would be Image Service or endpoint.
>
>
> Guang
>
>
> -----Original Message-----
> From: Mark Washenberger [mailto:mark.washenberger at markwash.net]
> Sent: Monday, December 10, 2012 10:36 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [Keystone] Trusts and Explicit Impersonation
>
> David, Adam, (other Trusts/Auth folks. . .),
>
> Any thoughts on this?
>
> Thanks!
>
>
>>> From: Mark Washenberger [mailto:mark.washenberger at markwash.net]
>>> Sent: Friday, December 07, 2012 8:53 PM
>>> To: OpenStack Development Mailing List
>>> Subject: [openstack-dev] Trusts and Explicit Impersonation
>>>
>>>
>>>
>>> Hi auth guys!
>>>
>>>
>>>
>>> As we continue to make progress towards large service providers exposing
>>> their Glance deployments as public services, one critical feature we
need
> to
>>> support is the ability to limit certain actions (mostly image uploads,
> also
>>> possibly image downloads) to use by Nova or other trusted services, and
>>> restrict users from taking those actions directly. Of course, this
> feature
>>> would only be turned on by configuration, and not likely by default.
>>>
>>>
>>>
>>> I had figured we could do this using some features piggy-backed on
>>> keystone pki, and documented the use case in this blueprint:
>>>
>
https://blueprints.launchpad.net/keystone/+spec/keystone-explicit-impersonat
> ion
>>>
>>>
>>>
>>> I've been following the discussion of Keystone Trusts with interest, and
>>> some questions have presented themselves. Is there some way we could
>>> manipulate the Trust mechanism to provide the auth feature Glance needs?
>>> Another (scarier for me) question: does the Trusts proposal conflict
with
> my
>>> feature request?
>>>
>>>
>>>
>>> Thanks!
>>>
>>> Mark
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121210/e85dbfe7/attachment.bin>