Yes. We register a JAX-RS ContainerResponseFilter on the SamlService endpoint that does
what you said as far as extracting the parameter into the session context. The limitation
with this approach is that we cannot scope the filter registration to the specific realm
that we want to apply this filter too.
Instead we have to have code in the filter itself to check the incoming request for
whether we need to apply the logic for the realm or not. This isn’t ideal but we don’t see
a way around it.
On a slightly different tangent, this triggered us to consider the JS authenticator that
you’d suggested. It looks like the JS authenticator approach will work better because it
will be scoped to just the realm that we want it.
Thanks for your insight.
-sud
On November 20, 2018 at 7:04:48 AM, Dmitry Telegin (dt(a)acutus.pro) wrote:
Hello Sud,
On Mon, 2018-11-19 at 15:55 -0500, Sud Ramasamy wrote:
Thanks. This is a handy little tip to use the JS Authenticators.
We found another way accomplish this using a JAX-RS feature to parse the custom URL
parameter out in the first request and stuff it into the context where we could retrieve
it from in the second request processing flow. Please let me know if for any reason this
is approach is discouraged.
In fact I was thinking about something similar, but with servlet filter rather than JAX-RS
feature. Your solution seems even better. Do you register a JAX-RS interceptor on
SamlService endpoint and push the extracted parameter into a session context?
Dmitry
Regards
-sud
> On November 19, 2018 at 2:52:05 PM, Dmitry Telegin (dt(a)acutus.pro) wrote:
Hello Sud,
Please check out this thread:
http://lists.jboss.org/pipermail/keycloak-user/2018-November/016228.html
The problem under discussion is almost identical to yours, with the only exception being
OIDC instead of SAML. But I believe the general principle (fishing request parameters out
of the Referer header) remains the same.
Another question: is it possible to use SAML RelayState to pass the same parameter?
Custom authenticators have direct access to that field via client session note with the
same name ("RelayState"), which could let you avoid the hacks like above.
Cheers,
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training
Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
> E-mail: info(a)acutus.pro
On Fri, 2018-11-16 at 09:47 -0500, Sud Ramasamy wrote:
> Hi,
>
> We are using Keycloak as a SAML IdP and have plugged in a custom authenticator to
handle the browser flow. The authenticator relies on a custom URL parameter that is
present in the initial SAML Authn request to Keycloak.
>
> We found that when the Keycloak SAML IdP receives a SAML Authn request (which also
contains our custom URL parameter) it exchanges that request with a code and redirects the
browser to itself at which point the control reaches our custom authenticator. This
redirect causes our custom URL parameter from the initial request to not be available to
our custom authenticator. Is there anyway to propagate our custom URL parameter to this
second request and thereby have it available to our custom authenticator.
>
> Thanks in advance for your help.
>
> Regards
> -sud
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user