The design choice of keystone sso

Rafael Weingärtner rafaelweingartner at gmail.com
Mon Dec 24 02:20:23 UTC 2018


We have this very same design. Why not just use Keycloak (with either SAML
or OIDC) and OpenStack. At the end of the day, that is why you use
Keycloak. Remember, when using Keycloak or any other identity management
system, you are offloading the identity management to another system (out
of your application). Then, your applications/”service providers” only need
to worry about the service/resource being delivered, and the authentication
and identity management is executed in the identity management system
(Keycloak in your case).


On Sun, Dec 23, 2018 at 3:34 PM <guoyongxhzhf at 163.com> wrote:

> The problem is about  keystone with sso
>
> The situation:
> 1. the cloud based on OpenStack has use keystone to build its own user
> account system, and no third user account like ldap or google accounts
> 2. the cloud may have multi web application/entrance and have multi domain
> name, so we need sso
>
> So there are two choice to implement sso
> 1. use CAS or other open source components as sso service and use database
> authentication which query keystone database.(I think it's odd)
> 2. use cookies(including keystone token) between multi web
> application/entrance
>
> which is the better choice?  I think if we use only users from keystone,
> it's not necessary to use an extra sso service.
>


-- 
Rafael Weingärtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181224/23ede221/attachment-0001.html>


More information about the openstack-discuss mailing list