Branches for the quickstarts
by Bruno Oliveira
While working today on the fix of some quickstarts. I'm
considering to create a separated branch only for stable versions of the
quickstarts.
In this way 'master' would be used only for development based on the
latest bits from Keycloak repo. And 3.1.x, to the latest stable
release on Maven central.
Does it make any sense?
--
abstractj
8 years, 7 months
Authorization with Springboot adapter
by Crafton Williams
Hi All:
I’m trying to configure a basic springboot app using the springboot keycloak adapter. Authentication works as expected but I’m a bit confused as to how to configure the policy enforcer in yaml. The documentation shows configuring the policy-enforcer as a json document however the springboot config implies a only policy-enforcer-config. In any case, I did try the json doc but it wasn’t picked up by the adapter.
I’m using 3.0.0.Final and tried the following in my yaml file(omitted the rest of the path info for brevity):
Policy-enforcer-config:
Enforcement-mode: ENFORCING
paths:
* name: blah
The exception I got was:
org.springframework.context.ApplicationContextException: Unable to start embedded container; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'tomcatEmbeddedServletContainerFactory' defined in class path resource [org/springframework/boot/autoconfigure/web/EmbeddedServletContainerAutoConfiguration$EmbeddedTomcat.class]: Initialization of bean failed; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.keycloak.adapters.springboot.KeycloakSpringBootConfiguration': Unsatisfied dependency expressed through method 'setKeycloakSpringBootProperties' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'keycloak-org.keycloak.adapters.springboot.KeycloakSpringBootProperties': Could not bind properties to KeycloakSpringBootProperties (prefix=keycloak, ignoreInvalidFields=false, ignoreUnknownFields=false, ignoreNestedProperties=false); nested exception is org.springframework.beans.InvalidPropertyException: Invalid property 'policyEnforcerConfig.paths[0]' of bean class [org.keycloak.adapters.springboot.KeycloakSpringBootProperties]: Illegal attempt to get property 'paths' threw exception; nested exception is java.lang.UnsupportedOperationException
Is there an example project somewhere that can guide me in configuring the policy enforcer for the springboot adapter?
Cheers,
Crafton
8 years, 7 months
Sharding and smart proxy
by Stian Thorgersen
Scaling to a huge amount of load (realms, users and/or sessions) is only
going to be feasible through sharding. This could be handled by users
themselves by having clusters of clusters, but we could also consider
adding this as a built in feature.
We could enable sharding at different levels:
* Realm
* Users
* Sessions
Then have smart routers that are able to route requests accordingly.
We could also enable the option to configure what DCs a specific realm
should be replicated to. For example one realm is only replicate to EU,
while another to both EU and US.
Maybe this could be relatively easy to implement? Not sure, it depends on
how much work it would be in the cache layer. We'd also need to implement a
smart router. That could probably borrow/share code with a lightweight
proxy option.
8 years, 7 months
Keycloak as stateless broker
by Leo C
Hi,
We would like to use keycloak as an identity broker in such a way that the identity collected from the identity provider are not permanently stored, so to avoid a build-up of identities stored on the broker.
Ideally, we would like:
· Keycloak, as identity broker to accept SAML assertion from one of several identity providers
· To use (custom) authentication flows to normalise or transform some of the attributes to create a new UserModel and consequentially a new SAML response back to the service provider
· To not bring the UserModel (or any other personal details to rest in the database), though we would accept storing just the unique ID of the user if we could avoid storing other attributes, whilst still propagating them back to the service provider
· Ideally to make authorisation decisions based on groups or roles during the process – and stopping the authentication if those fail
Leo
8 years, 7 months
add-user-keycloak.bat broken?
by Stan Silvert
I don't have time to look into it right now, but it's not working on my
Windows box.
Hoping someone touched this recently and might know what the problem
is? Biggest clue is that it spits out "null" instead of the usual "file
created" message.
c:\GitHub\keycloak\distribution\server-dist\target\keycloak-3.2.0.CR1-SNAPSHOT\bin>add-user-keycloak
-u admin -p admin
null
Press any key to continue . . .
8 years, 7 months
Slight refactoring of InfinispanUserSessionProvider
by Marek Posolda
In today's call with Stian and Hynek, we discussed the possible
refactoring of InfinispanUserSessionProvider to be reliable in
cluster/cross-dc environment.
Current implementation has tightly couple between the model
(UserSessionAdapter) and underlying infinispan entity. For example when
you call "userSessionModel.setLastSessionRefresh(123)" it directly
delegates this call to infinispan entity and calls
"entity.setLastSessionRefresh(123)" .
Some issues with this approach:
1) Possibility of lost updates in cluster - It can happen that there are
more concurrent requests updating same userSession. There is a fix by
Bill [1], which adds the thread-safety to UserSessionEntity and fixes
the issue in local environment. However in cluster with more nodes, it
can still happen that there is "lost update". I've created the JIRA [2]
for this with details. In shortcut, what can happen is, that there is
request1 processed on node1 and request2 processed on node2 in parallel.
Both requests read the sessionEntity and then both perform concurrent
update and commits their transaction. Then the latter update wins and
overwrites the first update as the state when it read the entity didn't
yet contain the first update.
2) Rollback doesn't work correctly. Basically when we do this:
{code}
userSession.setLastSessionRefresh(123);
session.transaction().rollback();
{code}
the keycloak transaction should be rolled-back and session in infinispan
cache shouldn't be updated to lastSessionRefresh 123. However in current
implementation, rollback doesn't work and entity is always updated in
local environment and may be updated in cluster too (in case that
calling node is the owner of session entity). That's because we are not
using infinispan transaction API and calling
"entity.setLastSessionRefresh(123)" directly updates the entity instance
referenced by infinispan storage.
3) Cross-dc support with good performance
Ideal is to fix all issues and ensure consistency, but have the
same/similar performance at the same time and not introduce additional
uneccessary locking.
Possible solution:
- Every change to UserSessionModel won't delegate directly to infinispan
sessionEntity as it's now. Instead it will track the change through
changelogs/events, which are saved locally in our infinispan transaction
(eg. AddClientToSessionEvent, LastSessionRefreshUpdateEvent).
- During Keycloak transaction commit are changelogs applied to
sessionEntity. It may use atomic operation "cache.replace(key, oldValue,
newValue)" and the pattern like this:
{code}
boolean replaced = false;
while (!replaced) {
SessionEntity oldSession = cache.get("123");
// Will update session entity based on the changes tracked in
infinispan transaction
SessionEntity updatedSession = applyChanges(oldSession);
replaced = cache.replace("123", oldSession, updatedSession);
}
{code}
- In cross-dc environment are changes sent to another datacenter. That
will receive changes (eg. AddClientToSessionEvent) and apply changes
locally in the datacenter and update the sessionEntity in the
infinispan. It shouldn't be a problem that those events are sent between
datacenters through the asynchronous channel. The changes may not be
guaranteed in same order in every DC, but all of them will be triggered
and there won't be lost updates. So the cache "sessions" won't be
directly replicated through the cross-dc, but instead the changes will
be sent between datacenters.
What do you think? Can you see some issues with this approach?
Thanks,
Marek
[1] https://issues.jboss.org/browse/KEYCLOAK-4821
[2] https://issues.jboss.org/browse/KEYCLOAK-4898
8 years, 7 months
Authentication sessions & Action tokens PR
by Marek Posolda
I've finally sent the PR https://github.com/keycloak/keycloak/pull/4132
with the work for $subject. This includes the work by Hynek and me on
Authentication sessions and action tokens. We finally managed to sort
various kinks and have all tests passing.
Some things and concepts were already discussed in some previous threads
[1], [2], [3] and during presentations. So I won't repeat everything.
Just some highlights:
- authenticationSession replaces the old ClientSessionModel. There is
separate AuthenticationSessionProvider and separate infinispan cache
"authenticationSessions" . This cache typicaly won't be replicated over
all the datacenters, but instead it will rely on browser sticky
sessions, hence browser will be redirected by loadbalancer to correct
node in correct datacenter. So typicaly there won't be cross-dc
communication needed during authentication.
- I've added some support for sticky sessions already. In cluster
environment, the authentication session cookie is created in the format
like "sessionId.routeId" . For example
"aabf27e6-7945-4d3a-a023-c1c64f7fdab4.node1". Pretty much same format
like JSESSIONID cookie used as a cookie in classic java web
applications. One side-effect of this PR is, that it also covers the
support for running clustering tests on embedded undertow and from IDE.
- Support for browser back/forward/refresh buttons was improved since my
presentation last month. There are no browser redirects after the form
submit, but instead there is a change of browser history through the
javascript history.replaceState function. This pretty much removes all
the POST requests from the browser history and helps with having good
experience regarding browser buttons. In case that you have old browser
not supporting this, the behaviour is same like before. Hence default
browser "Page expired" page after clicking back from POST request (same
behaviour like latest master). There are no additional redirects.
- For action tokens, Hynek will likely add more. For quick summary, I
can just mention that action token is JWT signed by realm secret key.
You can generate it in your authenticator or requiredActionProvider and
send it somehow to user. Typically through email. Once user opens the
actionToken URL from the email, it is processed on LoginActionsService
endpoint, which provides most of the common basic functionality and
verifications. LoginActionsService then finds the correct implementation
of ActionTokenHandler, which is separate SPI. This allows to specify the
details how can be actionToken handled, whether it's single use or not
etc. There is support for the scenario if user opened link in the same
browser when he started authenticationSession or in different browser etc.
- Regarding PR, I've tried to squash the commits a bit. However PR still
consists of more commits to track at least what was done by me and what
by Hynek. Do you think it is the issue to have more commits in the PR?
- This is hopefully the bigest task for the cross-dc support. My hope is
that PR can be reviewed and merged soon as the work is more and more
unsynced with the latest master and rebasing is a bit of pain. But I
understand that this will require time. There is change in 324 files :)
There are still a lot things to cover for cross-dc, but I think those
can be done in smaller pieces and commit more often.
[1] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009066.html
[2] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009121.html
[3] http://lists.jboss.org/pipermail/keycloak-dev/2017-March/009125.html
Marek
8 years, 7 months
Clearing AuthZ Cache
by Pedro Igor Silva
May I add a "Authorization Cache" to realm's "Cache" tab ?
Regards.
Pedro Igor
8 years, 7 months
Trying to ADD WS-Fed support for both protocol and broker into keycloak
by Sébastien Pasche
Hello,
We are a small team starting to develop/assembly an open source CASB solution.
We just wanted to say we will start to work on the code developed by
dbarentine On PR “KEYCLOAK-2000 WS-Fed support for both protocol and
broker”. https://github.com/keycloak/keycloak/pull/1766
The idea is to first work on a module to improve the current code
until it reaches WS-FED protocol support & quality level to make a new
proper PR (or keep it a module if it’s should be that way).
@dbarentine offered the latest version of his code (target 2.5.5.Final)
The new repository is here : https://github.com/cloudtrust/keycloak-wsfed
We will start to work on making it run on the latest version of
keycloak then start to complete it.
Anyone who want to help us is welcome :-)
Best
Sebastien
8 years, 7 months
