Global writable config
by Dmitry Telegin
Hi,
While developing a KC extension, I've faced the requirement to
implement global writable persistent configuration. That means, 1) it
should not be bound to any particular realm, 2) it should be accessible
from providers, 3) it should be updatable from the Admin console and
via REST. Additionally, there exists an (independent) requirement to
process INI-style files. With all the above, introducing Apache Commons
Configuration as a dependency would be an obvious choice.
But before that, I wanted to know if there are any plans to introduce
the same on the Keycloak side? If so, I think we could save ourselves
some time.
>From the "business" side, most configuration in Keycloak is per-realm.
But if we take a look at the similar software, like Atlassian Crowd or
WSO2 Identity Server, we'll find most of them have some sort of global
settings, for example:
- auto-update settings;
- periodic tasks;
- scheduled backups;
- plugin-specific global settings.
At the moment, I don't think any of the above is of high priority for
Keycloak, but I'm pretty sure there's a good chance things will change
in the future.
>From the technical side, we currently have global config in
standalone.xml which is read-only, and a lot of per-realm stuff that is
persisted into the database (including e.g. components). We also have
org.keycloak.Config stuff that is also read-only and only supports
system properties; and trying to make it writable and persistent will
inevitably result in the reinvention of "ad-hoc, informally-specified,
bug-ridden, slow implementation of half of" Apache Commons
Configuration.
With the above, please let me know what do you think of the idea of
introducing unified global config service backed by (tentatively)
Commons Configuration, with the following features (here's what's most
important in the context):
- support for multiple config sources under single API, most
importantly system properties, XML and JDBC;
- automatically selecting writable backend (e.g. JDBC) when writing to
a combined/composite config;
- events and notification;
- synchronization & thread safety.
If this is not topical for Keycloak proper, I'd appreciate any ideas on
how to do it the right way on the extension side.
Thanks in advance,
Dmitry
6 years, 4 months
[Improvment Request] Add context for an permission requests
by Tomek
Hello guys,
we would like to propose an improvment that can be added to the *Entitlment
API*. This topic was already opened in this mail: link
<http://lists.jboss.org/pipermail/keycloak-user/2017-February/009391.html>.
The main purpose of this improvment is to add an optional contextual data
for an permission requests.
Let's take into account an examle bussines case: evaluate permission to
orders in the context of specific shops. Those shops can be added to
the *Keycloak
*as a specific resources or scopes inside the *Order* resource. In our
point of view this is an overhead when we must synchronize all shops from
DB with *Keycloak*.
We have prepared a simple improvment. Here is an example of entitlment
request:
*POST /auth/realms/{realmName}/authz/entitlement/{clientName}*
*{*
* "permissions": [*
* {*
* "resource_set_name": "Orders Resource",*
* "context": {*
* "shops": ["shop1", "shop2"]*
* }*
* },*
* {*
* "resource_set_name": "Shop Resource"*
* }*
* ]*
*}*
The *context* is a map: *Map<String, Collection<String>> *and it could be
injected to the *Attributes* inside the *EvaluationContext* class before
policy evaluation.
The result of this request is an *RPT* token that also contains the
contextual data, so it can be later re-used. An example encoded *RPT* token:
*{*
*.....*
* "authorization": {*
* "permissions": [*
* {*
* "resource_set_id": "76bb1db0-b3c3-47a1-9d06-8f3b98d2ba10",*
* "resource_set_name": "Default Resource",*
* "context": {*
* "shops": ["shop1", "shop2"]*
* }*
* }*
* ]*
* }*
*.....*
*}*
The reason for this improvement is the overhead that arises when we have a
lot of resources to handle and they are added dynamically.
I have already implemented a working proof of concept, that is accessible
in the following link
<https://github.com/nocotom/keycloak/tree/feature/permission-context>.
(the context in the returned *RPT *token is missing, but the input context
is propagated to the policy evaluation)
Is this something *Keycloak *might have implemented?
What you think, guys?
Regards,
Tom Nocoń
6 years, 4 months
Keycloak Realm Count Upper Limit
by John D. Ament
We did some capacity and stress testing on keycloak recently. One of the
tests was to identify a breaking point for the realm count that would
result in the system breaking. We identified that once Keycloak hits 470
realms, regardless of scaling up the box and having caching enabled,
Keycloak simply becomes unusable.
Right now, this is a higher number than we need, but wanted to see if there
are any plans or enhancements to look at in newer versions to see if we
should test differently? We're on Keycloak 3.2 presently.
John
6 years, 4 months
Keycloak metrics with Prometheus
by David Martin
Hi,
We're working on an Ansible Playbook Bundle for Keycloak, for the Ansible
Service Broker [0].
As part of a cohesive Mobile backend solution on OpenShift, we're adding
prometheus metrics endpoints to our own (mobile specific) services, and
have had some success with adding a metrics endpoint to Keycloak.
However, we're not convinced the approach for adding the metrics endpoint
is the best approach.
The first approach used the jboss/keycloak-openshift image as a base image,
then added in the necessary parts (jar file & config), producing a new
image.
I'm not a fan of this approach as it means we'll have to maintain the new
image, keeping it up to date as the keycloak-openshift image gets updated.
The second approach (PR in [1]), also uses the jboss/keycloak-openshift
image, but copies the JAR file at APB provision time into a mounted
Persistent Volume in the keycloak-openshift running container.
This approach addresses the image maintenance issue, but feels a bit hacky.
A couple of questions:
* Do you have any thoughts on either of the appraoches so far
* Would it make sense for us to create a PR for keycloak upstream that adds
the necessary bits to expose a prometheus metrics endpoint. This would be
disabled by default, and enabled based on an env var.
Any thoughts or help are welcome.
Thanks
[0] https://github.com/feedhenry/keycloak-apb
[1] https://github.com/feedhenry/keycloak-apb/pull/35/files
--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)
6 years, 4 months
Skip updateAllTimeStamps of offline sessions on init
by javier.roman-navarrete＠daimler.com
Upon startup, all offline sessions timestamps are updated (both in the client and user tables). This can be quite time consuming, and we are trying to find out the real purpose of it. There is even a comment on the source code
// TODO: check if update of timestamps in persister can be skipped entirely
That hints it might be superfluous. What would be the downside of avoiding this update?
Regards,
Javier Román Navarrete
If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.
6 years, 4 months
offlineSessions data in cache vs db
by Tonnis Wildeboer
Hello Keycloak Devs,
[I posted this to keycloak-user, but got no response.]
Ultimately, what we want to do is migrate three nodes from one namespace
to another within a Kubernetes cluster as follows:
Start with three nodes in one Kubernetes namespace that define a
cluster. Then add three more nodes to the cluster in a new namespace
that shares the same subnet and database, then kill off the original
three nodes, effectively migrating the cluster to the new namespace and
we want to do all this without anyone being logged out. The namespace
distinction is invisible to Keycloak, as far as I can tell.
What we have tried:
* Start with 3 standalone-ha mode instances clustered with
JGroups/JDBC_PING.
* Set the number of cache owners for sessions to 6.
* Start the three new instances in the new Kubernetes namespace,
configured exactly the same as the first three - that is, same db, same
number of cache owners.
* Kill -9 the original three (I know now that it should be a kill -3,
but don't know if that matters in this case).
But it seems this caused offlineSession tokens to be expired immediately.
I found this in the online documentation
(http://www.keycloak.org/docs/latest/server_installation/index.html#server...):
> The second type of cache handles managing user sessions, offline
tokens, and keeping track of login failures... The data held in these
caches is temporary, in memory only, but is possibly replicated across
the cluster.
> The sessions, authenticationSessions, offlineSessions and
loginFailures caches are the only caches that may perform replication.
Entries are not replicated to every single node, but instead one or more
nodes is chosen as an owner of that data. If a node is not the owner of
a specific cache entry it queries the cluster to obtain it. What this
means for failover is that if all the nodes that own a piece of data go
down, that data is lost forever. By default, Keycloak only specifies one
owner for data. So if that one node goes down that data is lost. This
usually means that users will be logged out and will have to login again.
It appears, based on these documentation comments and our experience,
that the "source of truth" regarding offlineSessions is the data in the
"owner" caches, is NOT the database, as I would have expected. It also
seems to be the case that if a node joins the cluster (as defined by
JGroups/JDBC_PING), it will NOT be able to populate its offlineSessions
cache from the database, but must rely on replication from one of the
owner nodes.
Questions:
1. Is the above understanding regarding the db vs cache correct?
2. If so, please explain the design/reasoning behind this behavior.
Otherwise, please correct my understanding.
3. Is there a way to perform this simple migration without losing any
sessions?
Thanks,
--Tonnis
6 years, 4 months
Better support authenticationSessions in multiple browser tabs
by Marek Posolda
I am looking at https://issues.jboss.org/browse/KEYCLOAK-5797 issue now.
It's about the fact, that when user has opened browser with multiple
browser tabs, then after successful login in tab1 (clientA), he may be
redirected to the incorrect client (clientB, which was opened in tab2).
The thing is, that authenticationSession was tracked by the cookie and
didn't support multiple clients. So both browser tabs "tab1" and "tab2"
used same authenticationSession, which can reference just one of the
clients, hence there could be the conflict and one of the tabs
redirected to incorrect client after authentication.
I am working on a fix, that allow better support for multiple clients.
What I am doing is, that there is "RootAuthenticationSessionModel",
which is now referenced by the ID from the cookie. That root session can
reference more actual authentication sessions through the map like
"Map<String, AuthenticationSessionModel>" . The key is the client UUID.
In the Authentication SPI, there are no changes. Those still use the
AuthenticationSessionModel as before.
This is easily possible as we have "client-id" parameter already
available during authentication flows in every tab. So every browser tab
can reference correct client and redirect to it.
However even with the fix, there is another corner case about support
for multiple browser tabs with *same* client. This will be still an
issue, especially for the javascript clients. I've created another JIRA
https://issues.jboss.org/browse/KEYCLOAK-5938 with the example issue,
which can be simulated with our admin console. To properly support
multiple tabs of same client, the key will need to be like: "client-id +
state" instead of just "client-id" The "state" will need to be either
the OIDC/SAML state or some randomly generated string (As in both the
OAuth2 and SAML, the state/relayState parameter is not mandatory AFAIK),
which will need to be added to the URL during authentication flows as well.
Fixing this will take me another few days of work (maybe 2?) as there
will need to be change in many files for adding the new parameter + some
more authenticationSession model changes etc. So I wonder if we want to:
1) Fix this in 3.4.1 . Will likely mean to delay the release?
2) Fix this in 3.4.2. It will affect many files and there is some chance
of regression (hopefully not big as we have lots of the tests for
various other corner cases)
3) Fix this later in 4.X .
My vote is 1 or 2. WDYT? Any other possibility?
Marek
6 years, 4 months
SAML token authentication
by Buda, Mikolaj
Hello,
I would like to debug my local keycloak 1.9.2 instance. I'm looking for the
class which is responsible for SAML token authentication during log in
using IDP url. Which class is it?
Best regards,
Mikołaj
6 years, 4 months
