SAML - redirect - responder policy not working

[Gijs Lemahieu1709159845]

Hi,

 

first of all some background. I have set up the Netscaler as SAML SP and multiple customers can logon and authenticate on their own IdP (similar to this blog : https://www.citrix.com/blogs/2020/04/23/multi-domain-citrix-gateway-nfactor-authentication-and-citrix-fas/).

 

This is working fine, but one of the customers wanted to avoid the first step (filling in the email address, so that the netscaler can filter out the domain and forward the request to the corresponding IdP) and they figured out an url (making use of browser developing tools) like:

https://samllogonurl.com/nf/auth/doSaml?act=Name_Of_Authentication_SAML_Server;nf=;wv=0

When using this URL, they were immediately forwarded from the Netscaler to the correct IdP (without the first step of filling in the email address).

 

Now, after upgrading the ADC (version 13, most recent version), this (static) link is no longer working. I figured out (also making use of browser developing tools) that the URL changed to something like:

https://samllogonurl.com/nf/auth/doSaml?ctx=nYe-yLRyJi7SKoeU35Fm3N7wIvroWbnNJpfi_mdoWyW5flT7Fr8Z4KRBw4XTh2YKiB2uXxguZmVbOr4BwHhsDmkDczBjF_IavWVO2tG00X-W7iP74BtF6a81Vs_vfpGtqXD9Qhi36d0ZbB4-rqP49sInptQJuUknhngJ5NZF6EgTCTq0ujOizVu22rsCVe8QtjX8uyRl0k6CTH9h65XqhMKxJr2jo4eI1yaSBRNM3BrczR3-FxCP3qLG-Q%3D%3D;wv=0

and this link expires after some time, so it is somehow dynamic. The static link though, is hardcoded in the endpoint setup of the customer and is not very easy to modify.

 

I'm looking for a way to get this solved, and my idea was to forward incoming requests on https://samllogonurl.com/nf/auth/doSaml?act=Name_Of_Authentication_SAML_Server;nf=;wv=0   to https://samllogonurl.com so they can follow the regular flow, making use of a responder policy.

I created a responder policy with this expression:

http.REQ.URL.EQ("/nf/auth/doSaml?act=Name_Of_Authentication_SAML_Server;nf=;wv=0") and this action:

redirect to https://samllogonurl.com"

 

and I tried binding this policy to the Citrix Gateway virtual server and also binding it globally.

 

If I evaluate the policy expression (making use of live headers when hitting the static url), then it should be working.

 

For some reason though, the responder policy doesn't work and I'm still redirected to the IdP of the customer when hitting the static url.

 

Has anyone an idea how I can solve this and if this should be working?

 

Thanks a lot!

[Rhonda Rowland1709152125]

Responder policies run after authentication. Which version of firmware are you on?

Previously this was solved by binding the policy to the aaa responder bind point which runs before authentication.  Then there is a cli option for the vpn vserver:

 

Try:

bind vpn vserver <vpnvserver> -policy <polname> -priority <priority> -type aaa_request

bind authentication vserver authvserver -policy <policyname> –pri <priority> –type aaa_request

 

Example for responder with rate limiting in 13.1:  https://docs.citrix.com/en-us/citrix-adc/current-release/aaa-tm/citrix-adc-aaa-session-and-traffic-management/rate-limiting-with-gateway.html

[Gijs Lemahieu1709159845]

Hi Rhonda,

 

thanks a lot for your quick reply!

 

I tried with the first command (bind vpn vserver <vpnvserver> -policy <polname> -priority <priority> -type aaa_request) and this solved my problem. I'm getting redirected immediatly to the default logon page (as requested).

 

So if I understand this correctly, by setting the flow type to 'aaa_request' instead of the default 'request', this runs before authentication and is working fine (this is only possible in CLI) ?

 

FYI, I'm upgrading from version 13.0.71.44 to 13.0.87.9

 

Regards,

 

Gijs.

[Rhonda Rowland1709152125]

Correct.  If you were pre 13.0 the option might not have been available.

Some background: standard processing flow for lb/cs stuff:  aaa events up front, then things like appfw, responder, caching, etc...

So, if you wanted to use responder to filter or blacklist traffic (or redirect an authentication) event, originally authentication happens first and then responder..so you can use responder to filter or fix authentication requests easily.

 

For gateway (vpn vservers), authe happens before responder as well (by default).  So, again, trying to use responder to filter unwanted gateway traffi "pre authe" or to fix a URL pre authe, doesn't work without a change.

 

For authentication vservers the responder aaa_request bind point is visible when binding responder policies to the authentication vserver in the GUI. But not on the vpn vserver.

So the cli aaa-request bind point is a responder specific bind point on aaa entities like authentication vserver and vpn vserver that allows responder to evaluate before authentication attempts. Otherwise, binding a responder policy to the vpn vserver normally would have a different bind point in the cli.