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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)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.

#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