openstack team mailing list archive

[David Chadwick <d.w.chadwick@xxxxxxxxxx>]

Hi Pat

do you expect the one central user store to be replicated, say in 
Keystone, or not replicated?

The approach we have taken is to assume that the user stores (we support 
multiple distributed ones) are external to Keystone, and will be managed 
by external administrators. When a user accesses OpenStack, a transient 
entry is created in Keystone's user database for the duration of the SSO 
token, and is then automatically removed afterwards. This does not 
effect role based access controls, but will effect ACLs that currently 
use user IDs to identify the user, since these will change for different 
login sessions. The solution is for the ACL to use a persistent identity 
attribute of the user which comes from the user store, rather than to 
use the transient Keystone user ID

regards

David

On 18/02/2013 16:16, pat wrote:
> Hi David,
>
> Well, it might be useful. I forget to add that I expect one (central) user store.
>
> Thanks
>
>       Pat
>
> On Mon, 18 Feb 2013 16:11:05 +0000, David Chadwick wrote
> > Hi Pat
> >
> > sounds like you need our federation software which was designed
> > specifically for this use case. We currently support SAML as the SSO
> > protocol, and have just added Keystone to Keystone SSO. I have also
> > written a blueprint to show how OAuthv2 and OpenConnect can be used
> > by writing custom plugin modules. So if you have your own
> > proprietary SSO protocol you can write plugin modules for this
> >
> > Kristy can let you Pat have an alpha version for testing if he wants
> > it.
> >
> > regards
> >
> > David
> >
> > On 18/02/2013 15:59, pat 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 possible by implementing custom keystone drivers for identity
> > > and token. Is that correct?
> > > Should I also implement new policy and/or catalog driver?
> > >
> > > 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?
> > > 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.
> > >
> > > Is there possible to chain more keystone authentication drivers? E.g. first
> > > check my custom and if this one fails then check SQL one.
> > >
> > > 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.
> > >
> > > 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
> >
> > ----------------------------------------
> > Freehosting PIPNI - http://www.pipni.cz/
>
>
> ----------------------------------------
> Freehosting PIPNI - http://www.pipni.cz/