I agree pretty much across the board. <br><br><div class="gmail_quote">On Mon, Oct 8, 2012 at 11:45 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div class="im">
<div>On 10/02/2012 04:33 PM, Matt Joyce
wrote:<br>
</div>
<blockquote type="cite">The fundamental question I still have is tracking
posix user data. Is that something we want to pass forward from
directory services backending openstack or is it outside of the
scope of keystone?<br>
</blockquote></div>
I think for some deployments yes, others no, so we need to be
aware. I think that the cases where Keystone is used to add users
to a posix compliant backend, we need to make sure we can pass
values other than those required strictly by Keystone, and we need
to make sure we can tie in with, say, a backend UID generation
scheme.<div class="im"><br>
<br>
<blockquote type="cite"><br>
If it is in scope do we want to provide an internal directory and
if so do we want to optionally allow keystone to provide on the
fly posix data for backends lacking posix schemas.<br>
</blockquote>
<br></div>
So for "centralized authentication, local authorization " my guess
is the policy for synchronization needs to be configurable. Even
where all the group info is maintained in a backend local to
keystone, we may need to sync some local group info from a remote
system. Getting that right will be, I think iterative, so p[lease
record what your thoughts are, and lets make the blueprints as
comprehensive as possible. After that, we can prioritize the work.<div><div class="h5"><br>
<br>
<br>
<blockquote type="cite">
<br>
This is "relevant to my interests".<br>
<br>
-Matt<br>
<br>
<div class="gmail_quote">On Tue, Oct 2, 2012 at 12:01 PM, Adam
Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>On 10/02/2012 01:58 PM, Ralf Haferkamp
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Oct 02, 2012 at 01:06:44PM -0400, Adam Young
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/02/2012 12:07 PM, Ralf Haferkamp wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Sep 27, 2012 at 01:52:25PM -0400, Adam Young
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/27/2012 04:15 AM, Ralf Haferkamp wrote:<br>
</blockquote>
[..]<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
BTW, has anybody else been working on this
already? Does this even sound like a<br>
feature worth adding?<br>
</blockquote>
</blockquote>
</blockquote>
Yes, I have, but you are aehad of me. Please post
your patch. It<br>
is the right approach.<br>
</blockquote>
I have just pushed the code to the "external-branch"
in my github clone at:<br>
<a href="https://github.com/rhafer/keystone/tree/external-auth" target="_blank">https://github.com/rhafer/keystone/tree/external-auth</a><br>
<br>
Feel free to review and comment. It still needs
quite a bit of testing. But the<br>
basics seem to work for me. Currently, to use
external authentication you need<br>
to POST something like this to the /tokens URL (as
with username/password<br>
authentication the "tenantName" is optional):<br>
<br>
{<br>
"auth": {<br>
"external": "True",<br>
"tenantName": "test"<br>
}<br>
}<br>
</blockquote>
Good first take. However, I would prefer to add an
else block on:<br>
</blockquote>
Yes, this seems to make sense. I'll rework the code
accordingly. (It might take a<br>
little while though as I'll be afk for a few days)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
if auth is None<br>
if 'REMOTE_USER' in context:<br>
#assume external request for unscoped token<br>
if 'passwordCredentials' in auth:<br>
#UserID and Password passed explicitly here will
trump REMOTE_USER<br>
elif 'token' in auth:<br>
...<br>
else<br>
if 'REMOTE_USER' in context:<br>
if 'tenantName' in auth:<br>
# allocate scoped token<br>
#not 100% sure I want to allow this, but
that is a different discussion<br>
</blockquote>
I was thinking about that as well, but then I could not
really come up with a<br>
reason for not allowing it :). Do have one?<br>
</blockquote>
<br>
</div>
</div>
My feeling is that a user should use an unscoped token like a
TGT. It ties in with the delegation blueprint:<br>
<br>
<a href="http://wiki.openstack.org/keystone/Delegation" target="_blank">http://wiki.openstack.org/keystone/Delegation</a>
<div>
<div><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">
else:<br>
#assume external request for unscoped token<br>
#don't fail just because there is an auth
block.<br>
<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Of course you need keystone be backed by apache and
apache configured to do<br>
somekind of authentication (up to now I just tested
with mod_auth_kerb).<br>
Additionally the ExternalAuthMiddleware needs to be
added to keystone's service<br>
pipelines in keystone.conf<br>
</blockquote>
Fantastic. Thanks for doing that.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I didn't have time yet to implement anything on the
client side. Up to now I<br>
just used curl for testing. E.g. this works to
request a scoped token using<br>
kerberos authentication:<br>
<br>
curl -u : --negotiate
<a>http://</a><keystone-server>:5000/v2.0/tokens \<br>
-d '{"auth": {"external": "True",
"tenantName": "test"}}' \<br>
-H "Content-type: application/json"<br>
</blockquote>
Yeah, lets Iron out the API before chasing the CLI.<br>
<br>
Nice work.<br>
</blockquote>
thanks for the feedback,<br>
Ralf<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a 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>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a 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>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a 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>
<br></blockquote></div><br>