<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/28/2012 01:29 PM, Matt Joyce
wrote:<br>
</div>
<blockquote
cite="mid:CAGYSk8fh3A9xT=Qzpb=9u4W1c7sH=ptBewvR9rJzjgzz=VR8TA@mail.gmail.com"
type="cite">I guess I am going to echo David's concerns.<br>
<br>
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.<br>
<br>
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.<br>
</blockquote>
These are limited impersonations. You specifically designate the
roles and/or endpoints to which the trust applies. Anye tokens
requested will have exactly those limitations.<br>
<br>
<blockquote
cite="mid:CAGYSk8fh3A9xT=Qzpb=9u4W1c7sH=ptBewvR9rJzjgzz=VR8TA@mail.gmail.com"
type="cite"><br>
I fear that for my needs in terms of this functionality set,
direct impersonation without limits would not be very useful.<br>
</blockquote>
That is a different use case.<br>
<br>
<blockquote
cite="mid:CAGYSk8fh3A9xT=Qzpb=9u4W1c7sH=ptBewvR9rJzjgzz=VR8TA@mail.gmail.com"
type="cite">
<br>
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.<br>
<br>
-Matt<br>
<br>
<div class="gmail_quote">On Wed, Nov 28, 2012 at 9:56 AM, David
Chadwick <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
On 28/11/2012 17:38, Adam Young wrote:<br>
</div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, Kerberos, X509 and most other mechanisms have
a comparable<br>
mechanism, and they are all fairly new.<br>
</blockquote>
<br>
Actually I am very familiar with X.509 delegation since
I edited the<br>
2001 spec in which it was first included using attribute
certificates.<br>
So it is not new, its over 10 years old.<br>
</blockquote>
<br>
Heh, new in implementation, then.<br>
</blockquote>
<br>
</div>
No not really. Our PERMIS software has been implemented for
over 10 years as well :-) and had thousands of downloads<span
class="HOEnZb"><font color="#888888"><br>
<br>
David</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>