At the moment there's a compilation error trying to build master. This is
caused by an issue in SAMLParserTest. It was not caught by Travis because
it doesn't run unit tests at all.
I've updated Travis so it runs unit tests and fixed the compilation error
Just waiting for it to pass then I'll merge.
When migrating a custom user federation provider it seems the
validateAndProxy callback from the UserFederationProvider SPI no longer has
an alternative since it has been removed.
Before whenever a UserModel was pulled from Keycloak, this callback was
made and our custom user federation provider could add some transient
attributes each time.
In 2.5.5 it is my understanding that implementing the
ImportedUserValidation SPI is the way to go yet whenever the
authorization/access code is exchanged (
TokenEndpoint.buildAuthorizationCodeAccessTokenResponse ) the
ImportedUserValidation.validate is never called as the UserSessionAdapter
always goes straight to the UserCacheSession userprovider implementation
instead of the UserStorageManager.
Before whenever the TokenEndpoint was called, it always went to the
UserFederationManager class which fetched the UserModel but afterwards
check if the user had a federation link and then called the
So my questions are:
1. What is the right way to go to make sure a customer user federation
provider can always add some custom attributes to the UserModel via a
delegate, even if the UserModel comes from the keycloak cache.
2. Or do we have to disable the keycloak cache for this and if so how?
WildFly 11 is due to be released before we are releasing Keycloak 3.2.
I would like to upgrade to WildFly 11 Alpha11 now so we can see if we find
any issues with the plan that we will upgrade to WildFly 11 Final before we
release Keycloak 3.2.0.Final.
There's a slight chance that it would be delayed, but in that case we can
simply delay 3.2.
Any objections? Or can I go ahead and upgrade master?
Regarding this issue, is it ok to send PR?
I have tested the solution proposed my Marek in the description. In fact I have implemented it as a fallback if the session is null.
Seems to work for our use case. Testsuite has passed so far on my side.
Sorry if I forgot something. It’s my first contribution.
I went through the OIDC frontchannel logout specification draft  and
realized that it relies a lot on the iframes instead of browser
redirection. Basically OP would render HTML page with the hidden iframes
containing the logout URL of clients like:
I wonder if we should add some support for the iframes based approach
for SAML too? It looks that many vendors including shibboleth (see )
are using it as it seem to have lots of advantages over the redirection
- More reliable. With the redirection based approach used by SAML, the
IDP needs to redirect browser to the client1, which then need to
redirect back to IDP, which continues with redirection to client2 etc.
Problem is, that if any client is broken, then whole flow will break and
logout won't be finished properly.
- Better performance. Logout requests would be sent concurrently to all
- Better for cross-dc as there is no need for more writes to userSession
cache. IDP would just render the html with iframes in single request and
then remove userSession entirely.
- iframes may be blocked on the SP side.
logout, the IDP needs to send the LogoutResponse back to the SP, which
initiated logout. Which means that once HTML with iframes is rendered
and all the iframe requests are finished, there would need to be some
callback, which will automatically redirect browser back to SP with
- POST binding for logout. Not sure if this would work with iframes, but
I suppose there are some ways how to solve that (automatically submitted
- Anything else?
WDYT? Do we want to add some support for iframes based logout to our
Hi Keycloak Developers,
RFC6750 allows the access token to be submitted as part of a POST
request. I found that this is the only good way to do file downloads in
Excerpt: When sending the access token in the HTTP request entity-body,
client adds the access token to the request-body using the
"access_token" parameter. [...] Resource servers MAY support this method.
I don't remember a thread on this mailing list. The only place I could
find in the code was the User Endpoint that does this quite manually.
Currently Keycloak only supports the query parameter using
QueryParamterTokenRequestAuthenticator. A similar class will be needed
to support a Form Parameter. Like the
QueryParamterTokenRequestAuthenticator it will be part of the request
processing and it will not be configurable.
I'd like to open a JIRA issue for this as part of the Java Keycloak
Clients to track the efforts and thoughts.
Alexander Schwartz (alexander.schwartz(a)gmx.net)