Open Stack

@Renat, They are conceptually different:
- regular tokens are created for the owner of addressed resource
- trust scoped tokens are for trustees and have some security restrictions.
The case is about disallowing a trustee to aquire a regular token allowing
him anything the trustor is allowed. It'd be an exploit.

On Thu, Feb 19, 2015 at 9:01 AM, Renat Akhmerov <rakhmerov at mirantis.com>
wrote:

> Hi,
>
>
> > On 18 Feb 2015, at 23:54, Nikolay Makhotkin <nmakhotkin at mirantis.com>
> wrote:
> >
> > Nova client's CLI parameter 'bypass_url' helps me. The client's API also
> has 'management_url' attribute, if this one is specified - the client
> doesn't reauthenticate. Also the most of clients have 'endpoint' argument,
> so client doesn't make extra call to keystone to retrieve new token and
> service_catalog.
> >
> > Thank you for clarification!
>
>
> I want to say an additional “thank you” from me for helping us solve this
> problem that’s been around for a while.
>
> And just a small conceptual question: in my understanding since trust
> chaining has already landed this kind of reauthentication doesn’t make a
> lot of sense to me. Isn’t trust chaining supposed to mean that trust-scoped
> tokens a regular tokens should be considered equal? Or we should still
> assume that trust scoped tokens are sort of limited? If yes then how
> exactly they must be understood?
>
>
> Thanks!
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind Regards,
Alexander Makarov,
Senoir Software Developer,

Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia

Tel.: +7 (495) 640-49-04
Tel.: +7 (926) 204-50-60

Skype: MAKAPOB.AJIEKCAHDP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150219/85b08a87/attachment.html>