openstack team mailing list archive

["pat" <pat@xxxxxxxxxxxx>]

Hello,

Comments inline.

On Mon, 18 Feb 2013 19:56:00 -0600, Dolph Mathews wrote
> On Mon, Feb 18, 2013 at 9:59 AM, pat <pat@xxxxxxxxxxxx> wrote:
>Hello,
>
> Sorry to disturb, but I have some questions regarding keystone middleware.
>
> Some introduction to problem: I need to integrate OpenStack to our existing
> infrastructure where all systems are integrated on REST and Web level using
> SSO-like system (there&#39;s generated a token string with specific information).
> Required behavior is to allow users log-in once in existing infrastructure and
> without additional log-in access OpenStack components.
>
>
> I assume this is something completely proprietary then?

Well, it&#39;s inspired by common SSO, with some changes/simplifications.

> 
> I assume this is possible by implementing custom keystone drivers for identity
> and token. Is that correct?
> Should I also implement new policy and/or catalog driver?
>
>
> If you&#39;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.

Well, both. So for folsom, I need to implement (change existing) only identity driver. So this means that identity driver is responsible for generation of the token? And token driver only checks existing token for its lifetime?

>
> In grizzly, we&#39;re also introducing pluggable authentication drivers that do nothing more than authenticate users, which is probably more in line with what you&#39;re looking for. Your driver could simply authenticate with your existing system, and then create/update a user in keystone&#39;s SQL backend, for example. We&#39;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&#39;ll need corresponding client-side support as well).

Sounds good to me, but is a custom folsom driver compatible with grizzly? I hope so :-)

>
> [1]: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#the-password-authentication-method
> 
> If this is possible I expect the keystone token is the token generated by my
> middleware driver(s) and such token is used by all other OpenStack parts. Is
> that correct?
>
>
> You actually won&#39;t need to write any middleware. Rather, keystone is designed to abstract existing, external authentication systems from OpenStack&#39;s internal approach to auth (tokens). By writing a driver in keystone, you&#39;re just redefining that abstraction.

Well, I&#39;ve probably didn&#39;t get the naming :-\ So the driver is enough and the driver has to be specified in keystone.conf in [identity] section. Just checking if I&#39;ve finally get it.

> Does this affect way how the OpenStack internally validates token? Now when
> validating token the admin token has to be passed to validation request too. I
> expect not.
>
>
> Your expectations are correct.
> 
> Is there possible to chain more keystone authentication drivers? E.g. first
> check my custom and if this one fails then check SQL one.
>
>
> We don&#39;t have that today (even with pluggable authentication). This is something I&#39;d like to see implemented... I think it&#39;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&#39;s built-in password driver first, then your own driver).

That&#39;s nice-to-have feature for me.

> 
> I&#39;ve searched internet to find some example of keystone middleware, but I
> didn&#39;t succeed :-\ Is there an example or step by step documentation
> (something for an ... :-))? I&#39;ve read "Middleware Architecture" documentation
> and my questions are based on this.
>
>
> That&#39;s the best documentation I&#39;m aware of for the middleware architecture, other than reading the source code of keystoneclient.middleware.auth_token itself.

OK.

Thanks a lot for your help.

Pat

> 
> Thanks a lot for your help.
>
> Pat
 


----------------------------------------
Freehosting PIPNI - http://www.pipni.cz/