Migration from 2.4.0 to 2.5.5
by Wim Vandenhaute
Hello list,
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
UserFederationProvider.validateAndProxy hook.
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?
Kind regards,
Wim.
9 years
Update to WildFly 11 for 3.2
by Stian Thorgersen
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?
9 years
KEYCLOAK-4521: Error getting userinfo via access token obtained by offline token
by Heide, Marc
Hi,
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.
Best Regards
Marc
9 years
Frontchannel logout based on iframes?
by Marek Posolda
I went through the OIDC frontchannel logout specification draft [1] 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:
<iframe src="frontchannel_logout_uri">
I wonder if we should add some support for the iframes based approach
for SAML too? It looks that many vendors including shibboleth (see [2])
are using it as it seem to have lots of advantages over the redirection
based. Like:
- 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
the clients.
- 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.
Possible disadvantages:
- iframes may be blocked on the SP side.
- It will require some javascript though as for SAML-SP initiated
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
LogoutResponse.
- 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
form through javascript etc).
- Anything else?
WDYT? Do we want to add some support for iframes based logout to our
SAML clients?
[1] http://openid.net/specs/openid-connect-frontchannel-1_0.html
[2] https://www.switch.ch/aai/support/presentations/update2016/07_logout.pdf
Marek
9 years
Support rfc6750 Form-Encoded Body Parameter for access tokens in Keycloak
by Alexander Schwartz
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
a JavaScript frontend.
https://tools.ietf.org/html/rfc6750#section-2.1
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.
Comments welcome!
Regards,
Alexander
--
Alexander Schwartz (alexander.schwartz(a)gmx.net)
http://www.ahus1.de
9 years
