Changes in reps
by Marek Posolda
Hi,
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:
{
"username": "admin",
...
"realmRoles": [ "admin" ],
"applicationRoles": [
"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.
Thanks,
Marek
10 years
Renamed loginName to username
by Stian Thorgersen
We had both username and loginName at various places in the code. To make it consistent I've renamed loginName to username.
10 years
Status on model splitting
by Stian Thorgersen
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).
10 years
Add title for Realm, Applications, Clients and Roles
by Stian Thorgersen
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).
Any objections?
10 years
Removing UserModel#NotBefore
by Stian Thorgersen
I've removed NotBefore from the Users. User sessions takes care of this, so it's not needed.
10 years
How the cache works
by Bill Burke
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
each lookup
* 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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
JMeter Performance test
by Marek Posolda
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:
testsuite/performance-web/README.md .
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
- Logout
Some results from test on my laptop:
PostgreSQL with simple cache disabled:
uri count total min
average max
"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
max
"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
average max
"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
max
"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
Marek
10 years
Hangout this week to talk about cache and model splitting
by Stian Thorgersen
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?
10 years
Refactoring to KeycloakSession and ProviderSession
by Stian Thorgersen
I've combined KeycloakSession and ProviderSession into KeycloakSession. There's a single implementation of this (DefaultKeycloakSession).
Model implementations now implement ModelProvider instead of KeycloakSession.
10 years
