Jump to content
Welcome to our new Citrix community!

Determine nFactor flow based on SAML IDP profile


Ross Bender

Recommended Posts

We have a AAA server where we have configured multiple SAML IDP profiles. We are also using nFactor on the AAA server.

 

We now have a security requirement to support different authentication scenarios based on the SAML IDP that is being invoked. How can I access the active SAML profile in a policy expression so I can trigger different nFactor flows? User attribute fields won't work: I need something like the SAML profile's assertion consumer service URL or the service provider ID in order to perform the logic.

 

I see in the latest v13 build there is the following available in policy expression:

AAA.USER.SAMLIDP_FLOW

However, there is no documentation on it either in the Netscaler GUI or on Citrix website. I tried adding it in a log policy but I cannot seem to get it to get my log statements to display in ns.log.

 

How can this be accomplished?

Link to comment
Share on other sites

  • 1 month later...

The best I've been able to do to accomplish this is use the NSC_TASS cookie, which the Netscaler sets when redirecting to the AAA server for authentication.

 

For IdP initiated SAML, we use traffic policies bound to SAML SSO profile. We invoke the traffic policies based on URL:

HTTP.REQ.URL.PATH.CONTAINS("/sso/vendor")

This results in the following cookie being set during redirect:

Set-Cookie: NSC_TASS=https://mycompany.test/sso/vendor&code=xxx;HttpOnly;Path=/;Secure

Then our nFactor/authentication policy performs logic based on the cookie:

HTTP.REQ.COOKIE.VALUE("NSC_TASS").CONTAINS("/sso/vendor")

 

It's definitely a hacky solution depending on an undocumented feature, but it gets close to accomplishing what we need. We had previously filed NSHELP-19764 as a feature enhancement back in 2019, but it's been two years with no movement so we needed to come up with a solution.

 

Hopefully it helps someone else!

  • Like 1
Link to comment
Share on other sites

We also found that for SP-initiated SAML flows, the NSC_TASS cookie contains a base64 encoding of the SAML IDP profile instead of the initial URL (the one to which the service provider sends the SAML request):

Set-Cookie: NSC_TASS=TXlTYW1sU3NvUHJvZmlsZe+/uUlEPWFiYzEyMyZiaW5kPXBvc3QmQUNTVVJMPWh0dHBzOi8vdmVuZG9yLXVybC50ZXN0L3NhbWwvYWNzP2lkcGVudGl0eWlkPWh0dHBzOi8vbXlvcmctaWRwLWlkLnRlc3Tvv7k=;HttpOnly;Path=/;Secure

Base64 decoded, the cookie contains the name of the SAML IDP profile (MySamlSsoProfile in this example).

 

For this case we had to adjust our authentication policy to account for decoding the value for our logic:

HTTP.REQ.COOKIE.VALUE("NSC_TASS").B64DECODE.CONTAINS("MySamlSsoProfile")

 

  • Like 1
Link to comment
Share on other sites

  • 2 years later...
On 3/10/2021 at 4:30 PM, Ross Bender said:

We also found that for SP-initiated SAML flows, the NSC_TASS cookie contains a base64 encoding of the SAML IDP profile instead of the initial URL (the one to which the service provider sends the SAML request):

Set-Cookie: NSC_TASS=TXlTYW1sU3NvUHJvZmlsZe+/uUlEPWFiYzEyMyZiaW5kPXBvc3QmQUNTVVJMPWh0dHBzOi8vdmVuZG9yLXVybC50ZXN0L3NhbWwvYWNzP2lkcGVudGl0eWlkPWh0dHBzOi8vbXlvcmctaWRwLWlkLnRlc3Tvv7k=;HttpOnly;Path=/;Secure

Base64 decoded, the cookie contains the name of the SAML IDP profile (MySamlSsoProfile in this example).

 

For this case we had to adjust our authentication policy to account for decoding the value for our logic:

HTTP.REQ.COOKIE.VALUE("NSC_TASS").B64DECODE.CONTAINS("MySamlSsoProfile")

 

Ross - Thank you! This helped me a lot. I posted several times about how to differentiate SP initiated SAML requests to a AAA IDP server with little feedback. When there are several IDP policies on a AAA server, and no way to target other policies like LDAPS at those requests, Citrix' answer was "TRUE". I felt like this could allow users to access SP's they were not designated for (especially if auto-provisioning was configured) and could lead to insane recursive LDAPS lookups. I tested this in my environment, and it works great. I am closing 2 open threads about this very thing.

 

https://discussions.citrix.com/topic/419586-netscaler-as-a-global-idp/#comment-2102245

 

https://discussions.citrix.com/topic/414240-adc-as-saml-idp-need-sp-info-from-assertion/#comment-2083639

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...