[keycloak-dev] what's next for Alpha 3?

Marek Posolda mposolda at redhat.com
Thu Feb 20 04:36:37 EST 2014


Some possible features I can think of:

-- Clustering support -- For example if I have load-balancer and two 
keycloak servers "kc1" and "kc2" and client application doesn't 
communicate directly with keycloak servers but it uses loadbalancer. 
Then login request could be redirected by loadbalancer to "kc1" where is 
created accessCode entry in TokenManager. But when client application 
sends another request to load-balancer for exchanging code for 
accessToken, it could be served by "kc2", which doesn't have this code 
entry --> error. I did not test this scenario, but I am assuming that it 
probably won't work due to this... Do we want to support this? I've also 
created JIRA https://issues.jboss.org/browse/KEYCLOAK-323 which could be 
related to this.

-- Importing realm from JSON file in admin console - When I choose file, 
it displays me that I choosed file "testrealm.json". How about 
displaying the content of this file instead of just file name? I think 
it would be more user-friendly and also people will be able to edit the 
content on the fly.

-- Importing data from JSON file into already existing realm - For 
example I want to add 100 new users into realm, which already exists. Or 
add new application, oauth clients or role mappings. I can imagine some 
format like:
{
   "realm": "test",
    "strategy": "IGNORE_EXISTING",
    "users" : [
         {
             "username" : "newUser",
             "enabled": true,
             "email" : "newUser at localhost",
             "credentials" : [
                 { "type" : "password",
                     "value" : "password" }
             ]
         }
    ],
    "roleMappings": [
         {
             "username": "newUser",
             "roles": ["user"]
         }
     ],
}

The strategy could be something like IGNORE_EXISTING (Ignore particular 
user/application entry if it already exists) or MERGE (update attributes 
of existing user/application). But maybe "strategy" is overcomplicated 
and we can simply ignore existing entries?


-- Test coverage -- Keycloak has good testsuite for covering server-side 
scenarios, but the test-coverage of real client-side adapters for AS7 or 
Wildfly is closed to 0. It seems that testsuite should be enhanced to 
test also with "real" applications like customer-portal, product-portal 
etc. I can imagine that this will require start of AS7 and Wildfly, so 
probably won't be tested during each build? Also it seems that there is 
not much test coverage of admin console.

-- DB2 support - This is only remaining DB, which is certified by other 
RH products. Probably not so important, but I will try to look at it 
sooner during spare time. If we later need to support it and it will 
require some changes of DB schema, there might be issues with backwards 
compatibility... I hope that at this stage backward compatibility is 
still not something important as Keycloak is still in development and 
there will be some more features (like secured storage of realm private 
keys) which will require DB schema changes?

Marek


On 20.2.2014 05:21, Bill Burke wrote:
> I'd like to work on OpenID connect support as well as refresh tokens.
> We also need to help meet Aerogear's requirements, probably mostly
> around bootstrapping on Openshift.
>
> Like Alpha 2.  I'd like each one of us to do one thing major, then do
> another quick release 3-4 weeks from now.



More information about the keycloak-dev mailing list