sticky sessions
by Bill Burke
IMO, we need to highlight and document that when using a load balancer
in a cluster, sticky sessions should be enabled. We might even want to
consider adding support for sticky sessions for the code2token flow.
The obvious reason is performance. Login can span multiple HTTP
requests. If you have N nodes in the cluster with no clustering you
have the possibility of the same user being retrieved from the database
N times. One time for each authentication request (username/password,
OTP page, required actions) and finally for the code 2 token request.
Until I look into fixing it the auth SPI does a few extra redirects
right now too.
Code 2 token could simply have a callback URI so that the code 2 token
request hits the same machine the code was created on.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 9 months
Realm cache
by Stian Thorgersen
There's still some outstanding issues with the realm cache. It works, but
can and should be improved for 1.8.
One issue was that once the realm is updated any methods on clients, roles
or groups returns the underlying adapter instead of the cache adapters. As
a work around in 1.7 it now ejects all clients for a realm when it sees any
changes.
We have a few potential ways to solve this:
a) try to always return cache adapters - I went down this road attacking it
from a few different approaches, but was never successful as there was
always something that didn't work
b) only cache realms and have everything else hang off it - this is my
preferred option for now. As long as updating clients requires invalidating
the realm it seems a bit over the top to have separate caches for everything
c) make the cache smarter - instead of invalidating a realm, make sure we
add/remove the clients, etc..
We also need more automated testing around clustering. Late in 1.7 release
process I identified that caches where invalidated when other nodes loaded
things to it, so effectively the cache wasn't working at all in a cluster.
Thoughts?
10 years, 9 months
in-memory only federated users
by Bill Burke
I'm looking into in-memory only no-import federated users. What we
would want to do is allow the UserFederationProvider to create an
in-memory UserModel and allow for that UserModel to be cached via our
current architecture.
The current design assumes that all federated users are imported. This
includes our caching layer too! To add to that, the user isn't cached
until the 2nd request i.e.:
1. username/password page would hit the UserFederationProvider and the
user would be imported into Keycloak. This imported user is not cached,
only imported into the database for this request's KeycloakSession
2. OTP Page or code 2 token would then want to lookup the user by id as
that is what is stored in the ClientSession. It would hit the keycloak
database as it is not cached yet. This lookup loads the cache for the user.
Getting in-memory zero-import to work is even more tricky. The issue is
that ClientSession and UserSession need to lookup clients by id. If the
user is not in cache, then the cache needs to lookup the user by id
within storage. This lookup also needs to happen if a write operation
is performed on a cache user (getDelegateForUpdate()). So, Keycloak
needs to know that that ID is not in local storage and must be looked up
from a fed provider. The ID must be formed so that the provider fed
provider can resolve the lookup. I could use a URI for the ID i.e.
fed:{providerId}:{login-name}
The problem with this is that this id would need to be larger than 36
characters which is the current column size for UserEntity.id and any
other table that references users. I could possibly do:
fed:{providerAlias}:{login-name}
But its quite possible that combination would be larger than 36
characters. We could also just shrink it to:
fed:{login-name}
But then we would have to iterate over every federation provider to find
and load the user.
So in summary:
* IDs need to expand from 36 characters to something larger. (255
maybe). Don't some DBs have constraints on string primary key size? DB
scripts could possibly be
* CachedUserProvider and UserFederationManager interfaces would need to
be refactored
* I don't think UserFederationProvider interface would need to change.
But users would have to code for in-memory rather than throwing a switch
to just turn it on.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 9 months
Keycloak Client Provisioning Notifications.
by Thomas Darimont
Hello there,
are there any plans to provide a way to let client applications
know of new users before they actually try to login?
This could be used for triggering on-boarding mechanisms like e.g.
preparing a user environment (e.g. a tenant) for a particular
user.
I was thinking of a mechanism like web-hooks, as github and many other
services use in similar scenarios, where you could send a HTTP POST
requests to the client application in case of
a new user was registered in keycloak that was granted access to that
particular application and potentially others as well.
The POST request could contain some user data like:
login, email, userid, client roles, perhaps for multiple clients etc.
This would help client applications to associate a prepared environment
with the actual user from keycloak.
The intention is to keep an on-boarding experience fast as possible for the
user by doing some preprocessing as early as possible.
There is already a similar functionality to propagate logout events to
client admin URL.
Perhaps this could also be used for this - just send user created / user
update / user deleted
events to this endpoints as well.
Perhaps with keeping track whether the clients acknowledged the updated via
a HTTP 200 response-status with a retry with some back-off strategy
otherwise.
One often uses JMS topics for those scenarious but I think web-hooks would
be a bit easier here.
Cheers,
Thomas
10 years, 9 months
class not found
by Michael Gerber
Hi all,
I had to add the javax.mail.api module to the keycloak-services today, otherwise the reset password mail could not be sent. (Because the class javax.mail.Multipart could not be found)
I am using wildlfy 10 with the newest keycloak version.
Is this a known issue?
Michael
10 years, 10 months
Master bumped to 1.8
by Stian Thorgersen
1.7.x branch created and master bumped to 1.8.0.CR1-SNAPSHOT
10 years, 10 months
limiting users to access specific clients only
by sabir
I am building keycloak prototype apps that demonstrate authentication
against deployed keycloak server. I have 2 js client apps under the same
web-server with 2 different keycloak client JSON.
I have:
- Created realm -> poc-realm
- Created clients for poc apps to authenticate against -> app1 and app2
- Created roles in
app1 -> app1-user-role
app2 -> app2-user-role
- Created users -> app1-user and app2-user
- Assigned roles -> app1-user-role to app1-user, app2-user-role to app2-user
When I try to get redirected keycloak login for app1, I am able to login
with app1-user and app2-user, and similarly I am able to login into app2
with app1-user and app2-user.
Am I missing something? How do I ensure that app1-user isn't able to log
into app2, and app2-user into app1?
Although note that I have the same url patterns for *Valid Redirect URIs *of
both clients.
My JSON keycloak clients are correct:
{
"realm": "poc-realm",
"realm-public-key":
"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAryTAZE2+d/7uKduayhQlInhnD43jdPyBttVbERLXO7wN9juXIuO5SR5P75aIcy1Fpf5VTrL2Neb4iLeEGgTUHM7b0ycjNgK40CXcwhneSn0EIogDLqXfJ87efwH2UYG//3cWZsB9PjX440Yq4uh/pBs5aTw7hHhvlaF/LRTBibhpcy7N/cKPp2PRkhQbWX79EfIsFLg8IKDryazYkdsVoaVI20aeOyb9mfXSU+h7ZUZIKhY4hhtSK004ToD73HQvJ5U61Zv7UAEtKHOD928SO0/VijFkGCh7fHtOA4kNJhV6D7RehThz/llDE3rfs4wkO24L0j/hAss30OSQNnAD1QIDAQAB",
"auth-server-url": "[server URL]/auth",
"ssl-required": "external",
"resource": "app1",
"credentials": {
"secret": "e119ccf7-5c5a-4681-b4fa-fcca1b3de3b3"
},
"use-resource-role-mappings": true
}
and
{
"realm": "poc-realm",
"realm-public-key":
"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAryTAZE2+d/7uKduayhQlInhnD43jdPyBttVbERLXO7wN9juXIuO5SR5P75aIcy1Fpf5VTrL2Neb4iLeEGgTUHM7b0ycjNgK40CXcwhneSn0EIogDLqXfJ87efwH2UYG//3cWZsB9PjX440Yq4uh/pBs5aTw7hHhvlaF/LRTBibhpcy7N/cKPp2PRkhQbWX79EfIsFLg8IKDryazYkdsVoaVI20aeOyb9mfXSU+h7ZUZIKhY4hhtSK004ToD73HQvJ5U61Zv7UAEtKHOD928SO0/VijFkGCh7fHtOA4kNJhV6D7RehThz/llDE3rfs4wkO24L0j/hAss30OSQNnAD1QIDAQAB",
"auth-server-url": "[server URL]/auth",
"ssl-required": "external",
"resource": "app2",
"credentials": {
"secret": "e119ccf7-5c5a-4681-b4fa-fcca1b3de3b3"
},
"use-resource-role-mappings": true
}
Thanks for help.
10 years, 10 months
Direct access to forgotten password
by Fabricio Milone
Hi,
I'm doing some research on the project I'm working on and I need some help
on your side.
We are using keycloak from different client apps and in this particular
case, I have to add a forgotten password functionality for the (Native)
Android App using a direct access api. I've been reading through the
documentation but still I'm not sure which is the best approach to
implement this.
I know that on the documentation it is encouraged that I should make use of
the device's web browser to login/forgot password, but it is a project
requirement that has to be met, unfortunately.
Another desirable point on this is that we should avoid using form
submission for the forgot password functionality, but not sure if that's
even possible.
Thanks in advance, I'd really appreciate comments regarding this.
Regards,
Fabricio
10 years, 10 months
