Default roles for realms and applications
by Stian Thorgersen
At the moment we only have support for default roles for realms and I was planning to add the same for applications.
Currently when a new user registers the list of default roles for the realm is added. This means that if you create the default roles for the realm, roles for old users won't automatically reflect the changes. When adding default roles for applications the problem becomes even worse as now applications themselves can be added/remove after a user has been added.
As I see it we have two options:
1. Try to keep the default roles for realms and applications in sync with the roles for users
2. Add the default roles for realms and applications to tokens directly
To me option 2 seems the simplest/best
10 years, 6 months
I'm refactoring admin files
by Bill Burke
I'm refactoring all the admin UI files. Some of the files are too big.
ALl the code is under examples/ too so I want to move that to a
web-fragment project. Finally I want to create a dev distro script
that, when pointed to a $JBOSS_HOME env variable will generate an
exploded WAR with soft links to all the .css, .html, and .js source trees.
If you are working on any part of the admin console, let me know, as
we'll need to coordinate. Specifically the files under examples/.../server
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 6 months
Utils for playing around with Keycloak
by Stian Thorgersen
I've added some utils to testsuite to help playing around with Keycloak.
It includes:
* A very simple way to start a basic Keycloak server - including the ability to import one or more realms from a json file (testrealm.json's)
* A basic mail server - starts a SMTP server that simply prints received emails to stdout
* A google authenticator simulator
Look at testsuite/README.md to find out how to use them..
One know issue is that if the Keycloak server is ran using 'mvn exec:java' stylesheets and images doesn't work, but works fine when I run it from Eclipse...
What do you all think? Stupid waste of time, or useful? If no-one else uses them it's probably not worth the effort...
10 years, 6 months
Usability / Design improvements
by Gabriel Cardoso
Hi Bill,
can we have a Hangout tomorrow so I can present some suggestions to improve the usability / visual design of your prototype?
What time are you free tomorrow?
Thanks,
Gabriel
--
Gabriel Cardoso
GateIn Portal | User Experience Designer
10 years, 6 months
HTML5/JS applications
by Stian Thorgersen
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.
10 years, 6 months
usability vs. security
by Bill Burke
I'd like to have it that when an application is created in the admin
console, the admin can view the exact configuration files needed to
install in their application to enable security.
Unfortunately, this would involve populating application credentials in
the config file which would require exposing the application credentials
through a REST interface albeit secure REST interface.
Do you think it is such a big security hole to allow for this? I've
been trying to keep the mantra to not expose credentials anywhere if
possible, yet this is a very nice security usability feature. We could
even have it that an application password, totp, and/or cert is auto
generated.
Thoughts?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 6 months
Feedback on Oauth Clients
by Bill Burke
I need some feedback on how to handle OAuth Clients. OAuth clients are
like Applications in that Keycloak is used to log in, but OAuth clients
are required to be forwarded through the OAuth Grant Page. Users must
directly grant permission to the OAuth client to access stuff. OAuth
clients will also not be hooked into Single Logout or the session
management facilities I hope to incorporate into Keycloak. OAuth
clients will also not have roles associated with them.
The way google does it is that they require you to login using your
Google account, then you create applications within their cloud service
app. Applications get their own unique client-id and password and you
then assign permissions to this application.
I was thinking we should do something similar for Keycloak.
For our first release, we'll have a specific Admin UI in which you can
create OAuth clients in much the same way you create applications.
For phase 2, I was thinking that the user account management would be
expanded to have an option (if allowed by the realm) for creating and
registering an OAuth client. The user would then have a client-id
generated for them and they would have to set up credentials for this
client-id.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 6 months
Server provisioning
by Stian Thorgersen
I've started work on a server bundle and an openshift quickstart. The server bundle contains a main class that starts Undertow with Keycloak deployed. It's available at:
https://github.com/stianst/keycloak/tree/server
Build it, unzip it and run:
# keycloak-server-1.0-alpha-1/bin/keycloak.sh
By default it starts on localhost:8081, but this can be set with system properties for example:
# keycloak-server-1.0-alpha-1/bin/keycloak.sh -Dkeycloak.host=hostname -Dkeycloak.http.port=8080
It doesn't support https yet.
This server bundle is the basis for the openshift quickstart. To start Keycloak on openshift run:
# rhc create-app keycloak diy-0.1 --from-code https://github.com/stianst/keycloak-openshift-quickstart.git
For provisioning on openshift there's 3 issues:
* Configuring mail settings - this is done through system properties atm, which is less than ideal for openshift
* Configuring social settings - same as above
* Deploy admin console
If social and mail settings was configured on a realm it could be configured through the admin console instead of through system properties. The admin console would be easier to deploy if it was moved into a separate jar module (web fragment). As a jar it can be included on the classpath and the css/htmls will be available (this is how forms is "deployed").
10 years, 6 months
