[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