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

[Bill Burke]

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.

#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