<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 18, 2013 at 9:59 AM, pat <span dir="ltr"><<a href="mailto:pat@xvalheru.org" target="_blank">pat@xvalheru.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hello,<br>
<br>
Sorry to disturb, but I have some questions regarding keystone middleware.<br>
<br>
Some introduction to problem: I need to integrate OpenStack to our existing<br>
infrastructure where all systems are integrated on REST and Web level using<br>
SSO-like system (there's generated a token string with specific information).<br>
Required behavior is to allow users log-in once in existing infrastructure and<br>
without additional log-in access OpenStack components.<br></blockquote><div><br></div><div style>I assume this is something completely proprietary then?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
I assume this is possible by implementing custom keystone drivers for identity<br>
and token. Is that correct?<br>
Should I also implement new policy and/or catalog driver?<br></blockquote><div><br></div><div style>If you're looking at folsom, you should only need to implement identity, nothing more. You could even extend one of the existing drives (e.g. SQL) and only implement certain methods.</div>
<div style><br></div><div style>In grizzly, we're also introducing pluggable authentication drivers that do nothing more than authenticate users, which is probably more in line with what you're looking for. Your driver could simply authenticate with your existing system, and then create/update a user in keystone's SQL backend, for example. We're providing password authentication out of the box at the API level [1], but you could even implement your own authentication at the API level (you'll need corresponding client-side support as well).</div>
<div style><br></div><div style>[1]: <a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#the-password-authentication-method">https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#the-password-authentication-method</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
If this is possible I expect the keystone token is the token generated by my<br>
middleware driver(s) and such token is used by all other OpenStack parts. Is<br>
that correct?<br></blockquote><div><br></div><div style>You actually won't need to write any middleware. Rather, keystone is designed to abstract existing, external authentication systems from OpenStack's internal approach to auth (tokens). By writing a driver in keystone, you're just redefining that abstraction.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Does this affect way how the OpenStack internally validates token? Now when<br>
validating token the admin token has to be passed to validation request too. I<br>
expect not.<br></blockquote><div><br></div><div style>Your expectations are correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
Is there possible to chain more keystone authentication drivers? E.g. first<br>
check my custom and if this one fails then check SQL one.<br></blockquote><div><br></div><div style>We don't have that today (even with pluggable authentication). This is something I'd like to see implemented... I think it'd be trivial to extend our keystone.conf definitions for authentication method drivers to simply be a prioritized list that keystone could query in order, until a driver authenticates successfully (e.g. keystone's built-in password driver first, then your own driver).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I've searched internet to find some example of keystone middleware, but I<br>
didn't succeed :-\ Is there an example or step by step documentation<br>
(something for an ... :-))? I've read "Middleware Architecture" documentation<br>
and my questions are based on this.<br></blockquote><div><br></div><div style>That's the best documentation I'm aware of for the middleware architecture, other than reading the source code of keystoneclient.middleware.auth_token itself.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks a lot for your help.<br>
<br>
     Pat<br>
<br>
<br>
----------------------------------------<br>
Freehosting PIPNI - <a href="http://www.pipni.cz/" target="_blank">http://www.pipni.cz/</a><br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote></div><br></div></div>