Open Stack

I guess I am going to echo David's concerns.

We chatted at the summit about how to implement an NSS ( Name Switch
Service ) module to operate against Keystone.  And what the problem came
down to was providing a read only interface to an instance at run time.
One that could be disposable.

Impersonation without limitations would not solve that need.  In fact what
it would do is allow any user with access to that tenant to impersonate the
users credentials that were used by the nss module.

I fear that for my needs in terms of this functionality set, direct
impersonation without limits would not be very useful.

There have been several discussions in recent days about how to properly
inject authentication credentials into instances.  Being able to produce an
NSS path to keystone would be the "right" way to solve a lot of these
issues.  Or at least the most correct path we can achieve without a major
restructuring of OpenSSH.

-Matt

On Wed, Nov 28, 2012 at 9:56 AM, David Chadwick <d.w.chadwick at kent.ac.uk>wrote:

>
>
> On 28/11/2012 17:38, Adam Young wrote:
>
>>
>>
>>>
>>>> However, Kerberos, X509 and most other mechanisms have a comparable
>>>> mechanism, and they are all fairly new.
>>>>
>>>
>>> Actually I am very familiar with X.509 delegation since I edited the
>>> 2001 spec in which it was first included using attribute certificates.
>>> So it is not new, its over 10 years old.
>>>
>>
>> Heh,  new in implementation, then.
>>
>
> No not really. Our PERMIS software has been implemented for over 10 years
> as well :-) and had thousands of downloads
>
> David
>
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/20121128/76d6501e/attachment.html>