On Mon, Feb 18, 2013 at 9:59 AM, pat <p...@xvalheru.org> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
