[keycloak-dev] changes to admin ui login/bootstrap

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 17 October, 2013 11:30:08 PM
> Subject: Re: [keycloak-dev] changes to admin ui login/bootstrap
> 
> 
> 
> On 10/17/2013 4:42 AM, Stian Thorgersen wrote:
> > I strongly feel this is a mistake. We need to find a way to make the admin
> > console use Keycloak without any hacks. In my opinion the admin console
> > should use keycloak.js as it's a client-side application. For client-side
> > applications the credentials should be public so can just be
> > pre-configured to a well-known string.
> >
> > Safety of client-side applications are provided by two things: firstly the
> > application credentials themselves don't give you any privileges, secondly
> > the redirect uri should be verified by Keycloak preventing unauthorized
> > use of the credentials.
> >
> > If we can't come up with a good and safe approach to using Keycloak with
> > HTML5 and mobile applications the project is a huge fail! If we're not
> > using it directly ourselves for our HTML5 console that doesn't sound right
> > to me.
> >
> 
> #1  I want Keycloak ready to use out of the box and be as secure and
> locked down as possible.  This requirement may or may not effect the
> implementation of the admin ui or admin REST interfaces.
> 
> #2 We don't support CORS yet so doing keycloak.js approach is not an
> option at the moment.  I'm going to tackle that now as I don't think its
> that much work and this would be a really cool core feature.

I've already started work on keycloak.js + CORS support. As I mentioned on our Hangout having a good way to support HTML5 applications is a strong requirement for MBaaS so that is something I'm look at now

> 
> #3 If application credentials are public you can have client
> impersonation when you do the Authorization Code Grant protocol (the
> redirect protocols):
> 
> http://tools.ietf.org/html/rfc6749#section-10.2
> 
> http://tools.ietf.org/html/rfc6749#section-4.1
> 
> This may not be an issue when CORS support is implemented.
> 
> #4  Native apps (mobile or desktop) may be better off using direct
> grants and doing the login themselves.
> 
> http://tools.ietf.org/html/rfc6749#section-4.3
> The token service supports direct grants.  IMO, though, this should be
> turned off by default as this protocol is vulnerable to a multitude of
> attacks.
> 
> #5 HTML5-only and native apps that want to use keycloak auth server
> login and acct management pages via the redirect protocol may be better
> off being public Keycloak *OAUTH* clients instead of actual
> applications.  This would require the user going through the OAuth Grant
> Page for the initial login.  We could then extend the protocol by
> automatically generating a client_id and credentials for the native app
> and have the app store this information on disk for later use.
> 
> #6 The javascript of the admin console, as it currently is constituted
> has zero knowledge of the access token.  The access token is hidden from
> Javascript by an http-only cookie.  It is transmitted automatically by
> the browser when the admin UI makes REST calls back to the server.  I
> just don't see how this is *AT ALL* a bad thing.  We're protecting
> ourselves from a lot of unforeseen attacks by doing this approach, IMO.
>   A side effect is that it saves an extra HTTP request.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>