Dynamically add new users/roles
by Bruno Oliveira
Good morning guys,
Does exist any way to programatically add new users and roles with
Keycloak?
--
abstractj
11 years, 10 months
top level cache implemented
by Bill Burke
I implemented a non-clustered simple cache for realms, apps, oauth
clients, and roles. Its backed by ConconcurrentHashMaps and is in
memory. It is on by default and the model tests use it.
If you want to disable it, go into keycloak-server.json and change the
modelCache provider to "none". I'll probably disable it for the release.
For a simple perf test of loading the login page and doing the access
code flow to obtain a token, performance improved by 20-25%. I'm
guessing this improvement would be much higher with a non-embedded DBMS.
The only SQL which ran was loading users, load/update of UserSessions,
and load of roles. I could do more work to avoid loading roles.
Next steps?
* I need to work on stuff needed by Aerogear and other bugs and release
beta 3.
* Should Hibernate 2nd level cache be investigated before more work is
done here?
* Implement optional user caching to "simple" cache to see the
performance benefits.
* Create a comprehensive integrity test that runs multiple threads that
update/read concurrently to bang on cache implementation/ keycloak in
general.
* make the cache clusterable. Meaning secure invalidation messages. I
don't know if this means using Infinispan. Might be more work to
incorporate, configure, deploy, and bootstrap infinispan, than to
provide simple HTTP invalidation messages. Turning off the cache
entirely if communication between nodes fails.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 10 months
refactored model for caching
by Bill Burke
I'm almost done with a caching implementation. Had to do some
refactoring though
* Some methods were moved from RealmModel to ClientModel and UserModel.
scope mapping methods, role mapping methods, stuff that really belonged
* I moved a lot of queries up to the KeycloakSession interface. The
reason I did this is so that a caching layer could make queries without
having to do a DB query to load a realm, app, client, or whatever.
I wanted to commit this stuff now as I changed a lot of files and didn't
want tons of merge conflicts after you guys get back. Hopefully I can
have a cache working in the next few days.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 10 months
Retrieving the current logged in username
by Bruno Oliveira
Good morning guys,
Which way is the best to retrieve the current logged in username? I'm
trying with KeycloakSecurityContext, but no luck.
Thanks in advance.
--
abstractj
11 years, 11 months
License on source
by Stan Silvert
I see a lot of Keycloak source that doesn't declare a license. Shall I
add the Apache license to source in the module I'm working on?
Stan
11 years, 11 months
Testing Undertow Adapter
by Stan Silvert
I'm creating a pure Undertow Adapter that doesn't rely on the Servlet
API. It requires some changes to the existing Undertow/Servlet adapter.
I want to make sure I don't break anything. How do you guys test this
adapter?
Stan
11 years, 11 months
investigating caching
by Bill Burke
I think I have a decent way of doing caching, but it is going to take a
refactoring of the Model API and KeycloakSession API so that caching can
be layered (i.e. that we can cache realms/apps, but not cache users).
For instance, the JPA adapter pretty much is hard-wired to have a loaded
entity before it makes queries like "select user where user.realm = ?
and user.name = ?". We need to move things like user queries up to the
KeycloakSession level so that we can use things like
EntityManager.getReference() so that we're not making extra DB calls if
we need to query a user.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
profile results
by Bill Burke
I ran 10 threads each running 100 threads. I get a rate of about 31ms
per loginpage/processLogin/accessCode2Token flow.
According to JProfiler, 65% of time is spent in the password hashing
algorithm. I guess this is not surprising because this password hashing
algorithm is *supposed* to eat up CPU, right?
BTW, running 20 threads concurrently I start to get deadlocks in the
database around UserSession processing. Going to look into that.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 11 months
