Jump to content
Welcome to our new Citrix community!

Netscaler as a global IDP


Joseph Tuttle

Recommended Posts

Working on a project to use Netscaler AAA as an IDP for on-prem LB/CS apps, Gateway, SAML for cloud apps, etc. We stood up the AAA server and created the first set of policies for on-prem OWA. This is bound to the VIP and functions as expected. The next step is to setup the first SAML SP. In this case Sharefile/Citrix Files. This works, but there is some clarity missing in regard to overly broad auth policies and such. I present the following scenario:

 

For example:

 

 - The auth policy/profile/TM Profile for OWA on-prem all target the /owa/ URI-STEM to target when the policy should be applied. There is only a single LDAPS policy combined with TM policies for this function. This works perfectly.

 - When adding the SAML IDP for Sharefile/Citrix Files, I must add 2 policies to the AAA server. The SAML IDP policy and the related LDAPS policy.

 - The expressions supporting these 2 policies must be overly broad in order to function. For example, I must bind the LDAPS policy with a simple "true" statement or it will not function. The profile behind is a specific LDAPS group.  I can target the assertion from SF/CF with the /saml/ URI-STEM.

 - The IDP profile targets the ACS URL just fine. Even though the AAA.LOGIN.SAML_REQ_ACS_URL.SET_TEXT_MODE(IGNORECASE).CONTAINS("mysharefile.sharefile.com") methods ARE available at the policy level, they simply do not work at the policy level. Neither the LDAPS policy nor the SAML policy itself are able to use what I know for sure is valid ACS data to target policy application. They apply, but just simply do not work. The same value from the SAML IDP profile which DOES work.

- My concern is that over time as more LDAPS/SAML/oAUTH applications are added, the "true" statements for these policies and the inability to target incoming SP's specifically for policy application will overly burden our LDAPS environment with useless LDAPS queries looking for a match.

 - This would appear to be mostly a SAML related thing as on-prem apps can target URL's, cookies, etc. The SAML HTTPS POSTS really contain no uniquely identifying information, but the SAML data does. It would make sense to target policy to the ACS data, but this just appears to not function at the policy level. 

 

I would be super interested to hear of a way to target incoming SAML requests to specific LDAPS and SAML policies for application. Perhaps I am looking at this the wrong way as well.

 

Version 13.1-49.15

 

Thanks!

 

 

 

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...