caching changes
by Bill Burke
I'm still working on stuff, but here is a summary of things so far:
* ConcurrenyTest is passing
* Caching implementation is now a pessimistic locking style based on
versions. Locking never happens on reads, only writes. There are two
caches. One cache holds the actual data, and is pretty much a vanilla
invalidation cache. The other cache olds versioning information and is
a local-only cache and just is an id->version map. Given an id, what is
the current version of it. Hopefully, the implementation makes sure
that you never are able to add or obtain a stale version of an object
from the cache. Locking happens for updates. At the end of a
transaction, all registered invalidations are iterated on, and a version
cache lock on that id is obtain. The db is updated, and after that the
locks are released. A lock is also obtained whever something is added
to the cache. Again a lock is only obtained on the version cache, so
any reads will never block.
* KeycloakTransactionManager now has an enlistPrepare method.
* There is a new RealmProvider.getClientByClientId() method. Clients now
have a clientId "index" in the cache.
* There is a new RealmProvider.removeClient() method. This was needed
to support getClientByClientId()
Some other things that were done:
* Unnecessary @JoinTables were removed for certain @OneToMany relationships.
* getId() will no longer cause a DB query if you are invoking on a
reference to a JPA adapter
* RealmModel.getClients() and getClientNameMap() is no longer used to
implement getClientByClientId() :)
* CachedRealm now stores PrivateKey, PublicKey, and Certificate in a
transient variable. We were actually unmarshalling from the cached pem
format every time these things were access, which is like few times per
login.
Next steps:
* Create a client list cache for each realm. Currently, if you
add/remove a client, this invalidates the realm cache and its doing a
big query for each client.
* Do some profiling to see if there's other things we can do.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 9 months
Moving modules to modules/system/layers/keycloak and modules/system/add-ons/keycloak
by Stian Thorgersen
Currently all our modules are in module/system/layers/base. This is not
good from a patching perspective.
Modules for the standalone server should be in
modules/system/layers/keycloak.
Modules for adapters and server overlay should be in
modules/system/add-ons/keycloak.
I've asked Marko to sort this out so that it's fixed for 1.9.0.
7 years, 9 months
Need to remove built-in themes from standalone/configuration/themes
by Stian Thorgersen
Currently we include built-in themes in the themes jar as well as extracted
to standalone/configuration/themes. We have to remove the extracted files.
This is due to patching. The patching tools only supports patching modules,
not files. If we need to patch the theme templates (quite likely we will)
we can then only patch the jar. As the extracted themes override the jar it
won't work unless we remove them.
The main problem with removing the extracted files is that they are useful
for someone that needs to modify the templates. I think the best would just
be to give people instructions on how to extract these from the jar. It's
just a zip after all.
Thoughts??
7 years, 9 months
Protecting/encrypting realm keys
by Nagaraj,Vikas
Hello,
We've been integrating Keycloak into one of our applications, and so far it's been a pretty good experience. I'm looking now at how realms' signing keys are protected. Currently Keycloak stores the private key in a database table, but we'd like to explore protecting it with a Hardware Security Module (HSM).
A couple of years ago there was a discussion on this list on this topic (thread starts here: https://lists.jboss.org/pipermail/keycloak-dev/2014-January/001124.html). One suggestion was to have an EncryptionSpi interface that could be overridden to provide the desired crypto operations; another was to use a master key sourced from somewhere outside the DB to encrypt the private keys stored with the realm. Has there been any discussion about either of these alternatives since?
I'm happy to help with the implementation, but would appreciate some guidance from more experienced Keycloak devs on the best way to go about it.
Thanks,
--
Vikas Nagaraj
vikas.nagaraj(a)safenet-inc.com<mailto:vikas.nagaraj@safenet-inc.com>
--
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
7 years, 9 months
unmodifiable ok?
by Bill Burke
I've gone through the cache and model Realm Adapters and reduced copying
as much as possible and made every collection returned unmodifiable. Is
that ok with everybody?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 9 months
advice on back button
by Bill Burke
The current thinking for browser back button is to set:
Cache-Control: no-store, must-revalidate, max-age=0
There are possible security issues with this that I don't know if we
should do this or not. Don't know if you remember how ClientSessionCode
works, it uses a hash of the client session id and the action key
currently stored in the. When you switch from authentication to
required actions, the action key changes. Now, if you hit the back
button on a required action page, it would take you back to an
authentication screen. The code check would fail because the action
keys don't match.
Do we actually need this action key stuff? Can we just let the flow
manager put the browser in the correct state? So if an "authenticate"
url is hit and the flow is on required actions, just redirect to the
required actions URL. I just worry that this is some sort of security
hole somehow. Maybe we're better off just reseting and restarting the
flow entirely.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 9 months
stress/soak test/benchmarking framework
by Bill Burke
I've started implementing a stress test/benchmarking frameork. The idea
is that we have a pallet of operations that can be plugged in to run
randomly over a period of time to see what the effects are. Its all
under testsuite/stress
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 9 months
Users with duplicated emails
by Fabricio Milone
Hi,
I've been trying to solve an issue with my Federator for a few days now
when I import users that don't exist in Keycloak (but they do exist in my
Federator DB).
I'm getting a duplicated value constraint violation error on
email_constraint attribute from user_entity table. So I looked into the
source code and found that the emailConstraint attribute is being set to
the email value when I'm calling UserEntity.setEmail(String email).
public void setEmail(String email) {
this.email = email;
this.emailConstraint = email != null ? email :
KeycloakModelUtils.generateId();
}
Also I saw this comment in UserEntity.java:64:
// Hack just to workaround the fact that on MS-SQL you can't have
unique constraint with multiple NULL values TODO: Find better solution
(like unique index with 'where' but that's proprietary)
@Column(name = "EMAIL_CONSTRAINT")
protected String emailConstraint = KeycloakModelUtils.generateId();
My system allows duplicated email addresses and that cannot change.
Is there any way to allow duplicated email addresses on Keycloak?
Are you planning on an improvement to add support for a configurable unique
key for users?
What would be the best way to get rid of that constraint?
As a reference, I'm using Keycloak 1.7.0 and Informix as a DB.
Any help would be appreciated.
Thanks in advance.
Regards,
Fab
--
*Fabricio Milone*
Developer
*Shine Consulting *
30/600 Bourke Street
Melbourne VIC 3000
T: 03 8488 9939
M: 04 3200 4006
www.shinetech.com *a* passion for excellence
7 years, 9 months
How to use an offline token to get access token
by mhashim.gm＠gmail.com
Hello,
I have a javascript application with keycloak javascript adapter, I use
direct grant to get the initial offline token and save to database and
it works great, the problem is when I want to get an access token the
adapter fails silently. Here is how I initiate the adapter
keycloak.init({
refreshToken: response.refresh_token,
checkLoginIframe: false
})
.success(authenticated => {
if(!authenticated)
dispatch(loginFailure())
else {
....
}
then I tried to get the token directly from google chrome "postman"
tool:
POST
http://localhost:8080/realms/sisdn-realm/protocol/openid-connect/token
headers:
Content-Type: application/x-www-form-urlencoded
body:
grant_type=refresh_token
refresh_token=eyJhbGciOi...
client_id=sisdn
but the server responds with not-found, what am I doing wrong?
7 years, 9 months
