[keycloak-dev] SaaS login

Bill Burke bburke at redhat.com
Tue Aug 6 11:48:22 EDT 2013



On 8/6/2013 10:29 AM, Stian Thorgersen wrote:
> I will do :)
>
> Example use cases for using TokenService to login to the SaaS endpoints (to manage realms, applications, users, etc.):
>
> * Remote deployment of admin - with angular there's no strict need to deploy the admin console to the same server as the keycloak instance itself

Given that the admin console is all static html/css/.js pages, then this 
will definately be true.  But if they are not under the same domain 
name, then you're going to have to require CORS which opens additional 
security risks and browser support issues.

I can definitely see that you'd want to deploy the Token Service (and 
SSO login/OAuth grant pages) on a separate machine than the admin.  But, 
IMO, the admin UI and admin REST interfaces should reside under the same 
logical domain name.


> * In the not so distant future the admin console has to be split into UberFire panels, which can then be reused. For example the console for a MBaaS/IPaaS product may want to embed the Keycloak console. In this case it is highly likely that the console won't be deployed to the same server

I think this point may be irrelevant.  An MBaaS/IPaaS falls into the 
remote application catagory  So the MBaaS/IPaaS would use the OAuth 
login to Keycloak.  Then, any REST calls made to the Keycoak Admin REST 
interface by the MBaaS/IPaaS browser app will have the necessary cookies 
all set up.  CORS should be handled by the browser, correct?

> * Mobile/web bundled app
> * CLI
> * Programmatically
>

Right now, even before this email, the admin REST interfaces can be 
authenticated with either a cookie or a bearer token.  So the admin REST 
interfaces already support all the use cases you list above.

For the admin UI itself, if we don't hardcode the URLs, it doesn't care 
where the REST servers live.  CORS is all handled by the Browser and 
servers involved correct?  There's nothing that needs to be done in 
Javascript, right?

So all this is strictly an issue with login.  For applications that have 
access to the


> In the end of the day there's a need to support oauth login to the SaaS endpoints as well.
>
> Also, for an enterprise that installs it locally won't they want to use the same realm for the SaaS and their applications and have SSO between them?
>

That's probably something that should be supported.

So in summary, I *still* think the SaaS Admin UI login doesn't need the 
Token Service, but I do think what exists now needs refactoring to 
support all the use cases you mention here.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the keycloak-dev mailing list