When working on export/import, I did some changes to reps. Specifically:
- Remove "roleMappings", "applicationRoleMappings" and "socialMappings"
from RealmRepresentation and instead adding it directly under
UserRepresentation. So for user, we will have something like:
"realmRoles": [ "admin" ],
"Application": [ "app-admin" ],
"OtherApp": [ "otherapp-admin" ]
The main reason is that for big number of users, we may need to paginate
them (For example add first 10k users of realm into one file and then
another 10k users into another file etc), so it will be nice to have all
info related to user in one place.
- Added optional fields "hashedValue" and "salt" to
CredentialRepresentation. The thing is that if we want to do export, we
can't use plain-text "value", but we need to export it into
"hashedValue" . I am still keeping the "value", so it will be still
possible to import users with plain-text password as it is now. The main
usecase for "hashedValue"+"salt" is really just export/import (Import
passwords, which were previously exported)
Let me know if you see some issues with it.
I've implemented JPA realms, users and sessions, as well as mem sessions. It also works fine with the cache.
I still have a bit of work to do before I can commit it though. I'd like to do some clean-up as well as implement Mongo providers.
In the mean time if anyone needs to do any minor changes to the model just go ahead, and I'll merge it once I'm ready (hopefully early next week).
I propose we add a title for Realm, Applications, Clients and Roles. In admin console, login forms and account management we should then use the title if specified, otherwise use the name.
This allows having a URL friendly name (for example "realm-one") while having a human friendly title for interfaces (Realm One).
Good morning guys,
Do you know if is possible to customize the label of
referrer URLs on account management interface. I would like to change
to something like "Back to UnifiedPush server". The change is based on
discussions started here
I tried several approaches:
- Change the application name to something like "UnifiedPush server"
- Include "UnifiedPush+server" on referrer and also
- Make use of referrerURI with the admin URL, instead of referrer
Looking at account.ftl it seems like whitespaces are not accepted.
Thanks in advance.
Wanted to write up how the cache works. Its not very efficient on how
it decides to do invalidations, but this was the easiest approach.
* There are RealmAdapter, UserAdapter, etc. in the cache module just
like any other adapter
* These adapter objects are created once per session and reused with
* Any non-read method invoked will cause a persistence adapter to be
found for that model. The cache adapter object will then, from then on,
delegate to that persistence adapter.
* Invalidations happen at the end of a transaction
* Any create, update, or delete method invoked will cause a invalidation
event to be registered.
* If you call RealmModel.removeOAuthClient(), RealmModel.addRole(),
etc...this also causes the realm to be registered for invalidation.
Same thing with applications etc. This is true for everything but user
sessions and users.
* Anything registered for invalidation will cause the cache provider to
return a persistent model for any top level lookups.
* persistent adapter methods should never try and typecast a Model
reference to an adapter class. This is problematic for JPA as you need
to set up entity relationships. To get around this,
EntityManager.getReference() is used. Doesn't seem to be as much a
problem in the mongo one.
JBoss, a division of Red Hat
I've sent PR https://github.com/keycloak/keycloak/pull/490 with first
prototype of Keycloak performance test with JMeter. For now it's using
embedded Undertow (reused KeycloakServer stuff from testsuite) also with
performance-tools, so it's easy to add new users. Most of the stuff is
configurable through System properties, which allows to easily switch
different databases and models without any needed changes in
configuration files (For example PostgreSQL, MySQL, Mongo,
enabled/disabled simple cache etc), which is also good for easy setup of
performance test in Jenkins to have it in CI. Some details in README:
If you like the approach, I can continue and possibly setup CI. For now,
I've tried some testing on my laptop with 10.000 users in database and
each user having 1 realm role (available through scope to tested web
application) and 0 application roles... (I guess having configurable
number of roles, scopes per user might be useful as well and I can
possibly add it? )
Each test is using 50 clients (each client having different username, so
using users like user-0, user-1, user-49 ) and each client doing 50 test
iterations. Each iteration is doing:
- Redirect to KC login screen
- Login into KC
- Exchange code for token
- Refresh token 2 times
Some results from test on my laptop:
PostgreSQL with simple cache disabled:
uri count total min
"Login request" 2500 381151 10 152 1168
"Confirm Login request" 2500 1202384 39 480 1505
"Exchange code request" 2500 1162489 28 464 1677
"RefreshToken request" 5000 1992961 22 398 1630
"Logout request" 2500 786237 21 314 1383
PostgreSQL with simple cache enabled:
uri count total min average
"Login request" 2500 168819 6 67 857
"Confirm Login request" 2500 412464 18 164 1205
"Exchange code request" 2500 670047 21 268 1121
"RefreshToken request" 5000 997389 10 199 976
"Logout request" 2500 475672 17 190 1328
Mongo model with simple cache disabled:
uri count total min
"Login request" 2500 171976 6 68 1014
"Confirm Login request" 2500 412258 11 164 981
"Exchange code request" 2500 512125 12 204 1144
"RefreshToken request" 5000 923467 11 184 1073
"Logout request" 2500 367173 10 146 1108
Mongo model with simple cache enabled:
uri count total min average
"Login request" 2500 135489 5 54 1085
"Confirm Login request" 2500 224540 7 89 1318
"Exchange code request" 2500 343649 9 137 905
"RefreshToken request" 5000 556202 8 111 750
"Logout request" 2500 292986 10 117 1574
I'd like to have a hangout this week to talk about cache, clustering and splitting of the model. I'd like to do this a.s.a.p. so we can decide on what we're going to do for 1.0.final.
Last week I experimented with splitting the model into 3 parts: config, users and sessions. I've got something close to working at the moment. The basic idea is to create a new hybrid model provider that delegates to 3 different providers:
* Config SPI - realms, apps, clients, roles and scope mappings
* Could quite easily do a json file implementation. However, what about clustering? Could we just reload the whole realm whenever it's changed?
* Not considering clustering, is there even any reason to store config in a database? Dropping support for DBs and Mongo for config would make things significantly simpler.
* Can we load everything into mem on startup? How would that affect clustering?
* Should we add a revision to realms to make it easy to track consistency across servers in a cluster?
* In the long run we could move code from managers into KeycloakSession and HybridModelProvider (and also extract more shared code from the stores themselves)
* Does it make sense to have a read and read/write mode for config. For example admin uses read/write config, while logins and such use the read only config
* We could add a batch mode to the admin console. An admin can perform a number of changes that are kept in a draft version of the config on the server. Once the admin has done all the changes, he can then choose to review the changes through a page in the admin console and click push if he's happy with it. This could be taken further and have some users that are allowed to perform changes, but not push the changes.
* Users SPI
* Stores users, credentials and role mappings
* I expect this is the only one users of Keycloak could want to implement themselves
* What implementations do we provide? DBs, Mongo, LDAP?, Files?. Does it make sense to use PicketLink here (could provide jdbs, files, ldap, etc..)
* Sessions SPI
* Stores sessions (and probably login failures as well)
* In-mem implementation makes sense here. However, what about clustering?
* Do we still want JPA and Mongo implementations?
I've combined KeycloakSession and ProviderSession into KeycloakSession. There's a single implementation of this (DefaultKeycloakSession).
Model implementations now implement ModelProvider instead of KeycloakSession.