Its up to the application how it wants to secure itself with the
browser. For JBoss applications, they can just use regular servlet
security. Adding a valve and a keycloak configuration file to their WAR
is all they have to do to secure their application. A session cookie is
set up and the token and role mappings are stored in the session.
Security is all handled in a standard Servlet way.
Our admin console is a little different in that it is one servlet app
managing multiple domains so it uses its own custom HttpOnly cookie.
That way it is not available in Javascript land, but will be sent on
REST invocations back to the server.
IMO, this is all we should support at the moment as there is a ton of
minor features we still need to implement and a lot of refactoring and
repolishing we need to do all over the place. Not to mention all the
testing that still needs to be done.
That being said....
I don't see why there would be a need for a keycloak.js with all the
methhods you suggest. These is not information that should be exposed
to clients. The Access Token should be opaque to client code. How the
application wants to represent a user is up to the application. IMO,
the client should have obtain the access token via a REST call to the
application's server. The response should be text/plain to protect
against XSS attacks. Embedding the access token in Javascript is a
security hole.
On 10/8/2013 9:38 AM, Stian Thorgersen wrote:
I'm working on a HTML5 SDK + example for Keycloak and would like
some feedback on how it should work.
I've made the assumption that the application is a Keycloak resource, it uses
fragments for navigation (i.e. no page reloads on navigation) and that the credentials for
the application is not a secret.
I'd like to hide as much as of the complexity as possible in keycloak.js and make it
nice and simple to use. keycloak.js will provide the following functions:
* init(config, async) - config is the configuration available from keycloak - async is
optional (default is false)
* onAuthenticated(handler) - registers a handler for successful authentication - should
be used if async is set to true in init
* onAuthenticationFailure(handler) - registers a handler if failed to authenticate -
should be used if async is set to true in init
* login() - redirects to the keycloak login form
* register() - redirects to the keycloak registration form
* isAuthenticated() - returns true if user is authenticated
* getUsername() - returns the username (principal from token)
* getProfile() - returns the authenticated users profile
* getApplicationRoles() - returns the application roles
* getRealmRoles() - returns the realm roles
* getAccessToken() - returns the encoded access token
* isError() - returns if there was an authentication error
* getError() - returns the error query param
If the 'code' query parameter is present keycloak.init will remove it from the
URL (using window.history.replaceState) and request an access token from the server.
We could store the access token in HTML5 storage, but that is risky due to XSS hacks
(maybe it could be an optional feature to store in session or local storage). An
alternative is to just keep it in memory. Storing it in memory means that a page refresh
would loose the token so the user would have to click the login again. If cookies are
permitted by the realm the user wouldn't have to actually login, the user would just
be redirected back to the application.
An optimization would be to add a feature to TokenService that returns an access code if
the user is already logged in. This would also be useful for other types of applications
to automatically login users that are logged in to the sso realm.
We need to enable CORS support for the TokenService at least. We also need one more
feature in the TokenService to retrieve the user profile for the current user (supporting
'Authorization bearer' or keycloak identity cookie), again this is something all
applications will need.
Config passed to init should contain one or more redirect uri's and keycloak.js
should use the one that closest matches the current page for the redirect_uri param.
Further we can support loading a specific fragment after the callback has been processed
by keycloak.js. The specific fragment to load could be passed in to keycloak.login and
encoded into the state param (for example keycloak.login('#/secretpage')).
For application configuration we need to add one or more valid redirect uris and one or
more web origins. As the credentials for a HTML5 application is public it's even more
important that we validate that the redirect_uri param matches one of the pre-configured
redirect uris. In the past I proposed the idea of allowing a redirect uri to be a pattern,
but this is explicitly not recommended by the oauth2 spec, so we should require the
redirect_uri value to be an exact match of one of the pre-configured redirects.
We'd should probably also provide keycloak-angular.js that wraps keycloak.js up
nicely for Angular apps.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com