[keycloak-dev] SaaS login

[Stian Thorgersen]

I could imagine many use cases where developers would deploy REST services (and web applications) on the same server as Keycloak. Would it make sense to provide this "optimized protocol" as a generic solution, instead of specific to the SaaS admin console?

It would also be nice if changing between the two "protocols" wouldn't require changes to the application itself. Could it simple be done as a configurable optimization in the standard protocol?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 6 August, 2013 5:07:32 PM
> Subject: Re: [keycloak-dev] SaaS login
> 
> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>