[keycloak-dev] SaaS login

Tue Aug 6 10:29:07 EDT 2013

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
* 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
* Mobile/web bundled app
* CLI
* Programmatically

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?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 6 August, 2013 2:03:46 PM
> Subject: Re: [keycloak-dev] SaaS login
> 
> Feel free to keep arguing, but I don't agree yet.  The admin UI is not a
> remote application, it is served up by the same web app as where the
> REST services driving it are deployed.  This is a very important
> distinction.  Because of this, the protocol can be much more efficient.
> 
> OAuth requests:
> 
> 1. GET app URL
> 2. redirect from app to token service, display login screen
> 3. submit login
> 4. redirect back to app
> 5. Make a separate non-browser HTTP request to obtain access code
> 
> Also, in steps 1-5 a client is involved.  This client is requesting
> access on behalf of the user.  So, step 2 requires knowledge of the
> client id.  It actually checks to see if the client is even allowed to
> display a login screen.  Step 3 needs to check if the client requires
> the OAuth Grant page, it also registers an access code which is
> transmitted to the client in step 4  The client will turn this access
> code into a token in step 5.
> 
> Also, step 2 involves setting a "state" cookie who's value is also
> embedded in the redirect url in step 2.  The state value is
> retransmitted in the redirect URL in step 4.  And step 5 validates the
> "state" cookie
> 
> Saas login
> 
> 1. Get login screen
> 2. submit login, response is the admin UI
> 
> This algorithm doesn't involve a client at all.  Also, if you look at
> the admin UI it has no knowledge of a token.  It just makes REST
> requests which are authenticated by a session cookie.  Remote
> applications actually work in the same exact way after they obtain their
> token.  They set a session cookie and store identity in the server's
> HttpSession.  For keycloak, we store the identity in the session cookie
> so we can have stateless backend.
> 
> 
> 
> 
> 
> 
> On 8/6/2013 4:23 AM, Stian Thorgersen wrote:
> > IMO that's a mistake, there's a lot of duplicated code, and you'll also
> > want to support social login etc. (so more duplicated code) or SaaS
> > when/if it comes to a free "trial" online.
> >
> > As admin is a JavaScript application it is clearly a remote application and
> > could login the same way as any other remote application does, i.e.
> > through TokenService. The only difference in the two scenarios is that for
> > the admin rest endpoints it would be a small optimization to allow
> > validating the token without a remote call, which would be beneficial for
> > folks that wants to use keycloak for smaller internal deployments (e.g. a
> > single app server running a rest/js style app).
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 5 August, 2013 7:26:06 PM
> >> Subject: Re: [keycloak-dev] SaaS login
> >>
> >> TokenService is really for a remote service that is using keycloak to
> >> authenticate.  Its all the same server so no need for the extra
> >> redirects and thus no need for the Token Service endpoints.
> >>
> >> On 8/5/2013 11:14 AM, Stian Thorgersen wrote:
> >>> I was wondering why there are separate login/logout endpoints in
> >>> SaasService? Should this not use the standard mechanism to do this (i.e.
> >>> TokenService)?
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >> --
> >> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 