openstack team mailing list archive

[Dolph Mathews <dolph.mathews@xxxxxxxxx>]

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'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?


>
> 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'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.

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).

[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'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.


> 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'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).


>
> I've searched internet to find some example of keystone middleware, but I
> didn't succeed :-\ Is there an example or step by step documentation
> (something for an ... :-))? I've read "Middleware Architecture"
> documentation
> and my questions are based on this.
>

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.


>
> Thanks a lot for your help.
>
>      Pat
>
>
> ----------------------------------------
> Freehosting PIPNI - http://www.pipni.cz/
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>