openstack team mailing list archive

["pat" <pat@xxxxxxxxxxxx>]

Hi,

Expecting single external user store which is RO for keystone. In common the
users store is LDAP. As I wrote the key thing here is the generated token.

     Pat

On Tue, 19 Feb 2013 10:44:59 +0000, David Chadwick wrote
> 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/
> >
> 
> ----------------------------------------
> Freehosting PIPNI - http://www.pipni.cz/


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