[keycloak-dev] SaaS login

[Bill Burke]

https://github.com/keycloak/keycloak/wiki/Keycloak-Admin-Deployment-Requirements

Tried to capture this here.

On 8/6/2013 11:48 AM, Bill Burke wrote:
>
>
> 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