Scenario

We came across a requirement while implementing Citrix Netscaler as a central authentication instance for web applications, which was described with several needs on the customer site.

• User are going to start a cloud web application for example from SAP or other cloud providers
• This application will create a SAML request and send it to a Netscaler AAA service to authenticate the users from an on-premise repository (LDAP)
• Netscaler will validate the request, based on the certificate and the existing sessions
• If there no active session the users must authenticate on the Netscaler before they can start the web application
• Netscaler authenticates the users on the central Active Directory
• Users are separated in different Active Directory groups by roles.
  • Users can have user rights
  • Users can have administrative rights
• Users with administrative rights in the application must log in with a second factor, in our case RADIUS
• After a successful authentication, Netscaler will create a SAML assertion and redirect the user to the application

Authentication Flow

In the following article, I like to describe a authentication flow, which is simplified from the origin requirements, but still shows the need to distinguish different user groups before they have access to the application. The following diagram will show this flow.

I would like to recommend always to start which such a draft, so clarify the needs and the dependencies of the different components and the way we need to implement them.

Prerequisites

In my lab environment, I have the following components in place and working well:

• Application to create SAML request and process assertions
• Central Active Directory, with at least two different user groups for the application
• Second authentication instance, RADIUS
• Netscaler 11.1 50.10 Enterprise

Implementation

The following steps are in that order I found it’s the logical and easiest way to put the components together in the last steps:

Create Authentication Servers and Policies for the local site (LDAP, RADIUS)

1. LDAP Server and Policy for Group Extraction

As we could see in the flow chart we need the possibility to extract groups from LDAP to decide, if an user is a member of the admin groups or not. The way Netscaler will accomplish this to create a separate LDAP Server, which has authentication disabled.

	Navigate to the menu AAA, Policies, Authentication and basic policies, LDAP.
	Create a LDAP Server with the preferred settings and uncheck the checkbox for authentication.
	Nevertheless, make sure the communication is working.
	In the other settings fill the server logon name attribute, group attribute and sub attributes.
	Create Advanced LDAP Policy for Group Extraction.
	Action type is LDAP and action is the previous created LDAP server.

2. LDAP for Authentication

	Create a second LDAP server, where the checkbox for authentication is enabled. The rest of the settings can be the same.
	Create Advanced LDAP Policy for Authentication

4. Create Advanced for decision if user needs a second factor or not

After the Group extraction step Netscaler needs to identify if an user is Admin or not. This can be done by extracting the „IS_MEMBER_OF“ attribute in the HTTP request.

	In a first policy check if user is App-Admin. Regardless of the result, we don’t want to authenticate in this step. So the Action Type in „NO_AUTH“
	The second policy will search for the „App-User“ group.

Create Logon Schemas

Login Schema is an XML construct that is aimed at providing sufficient information to the Netscaler Logon mask so that it can generate individual screens for different use-cases Put another way, LoginSchema is a logical representation of logon form in XML medium.

1. Logon Schema to query the username

	Go to the „Security / AAA / Logon Schema menue and select profiles. Here start with add.
	Insert a name and select the Authentication Schema with the pen icon.
	Go to the folder LogonSchema, with reprensent the templates from the appliance.
	First we need a schema for the user name input. There is a template. Select it on the left panel and click edit.
	Here we have to insert a name and can modify the given filed. Click save to finish.
	In the background Netscaler will create a copy of the template in the /nsconfig/logonschema folder.
	Important: Click select and Create.

2. Logon Schema to query the LDAP password for standard user

For the authentication flow we need a logon schema, where the information of user name and LDAP password are needed. (Represented on the left side of the flow)

	Insert a name and start the editor.
	Select the singleauth.xml and click on edit.
	Set a name and change fields if needed.
	In the background Netscaler copies the template
	Click on select and create.
	To avoid the need to insert usernames twice we can start a WinSCP client to modify the XML files directly. Search for <ReadOnly>false</ReadOnly><InitialValue/> and replace it with

<ReadOnly>true</ReadOnly><InitialValue>${HTTP.REQ.USER.NAME.TYPECAST_LIST_T('@').GET(0).TO_LOWER}</InitialValue>

 

3. Logon Schema to query the LDAP and RADIUS password for admin user

	Create a third schema for the two factor authentication, in the same way.
	Select DualAuth.xml and click on Edit
	Set a name and change fields if needed.
	In the background Netscaler copies the template
	Click on select and create.
	Close the dialog by clicking on create.

4. Logon Schema for background tasks (noSchema)

	The last logon schema is kind of dummy, we need if no other xml is need. Here you can use the „noschema“ template.
	For the described flow we need four schemas.

Create Authentication Label

Authentication policy label is a collection of authentication policies for a particular factor, which also can have a „next factor“.

With nFactor, there is no single „secondary“ cascade. There could be „N“ secondary factors based on configuration. A label consists of at least a loginSchema and one authentication policy.

	Start the Authentication Policy label creation with add.
	From the view of our flow we should start from the bottom. So we have to begin with the two factor. Insert a name and select the previous created login schema. Go ahead with continue.
	Now we are able to bind the authentication policy.
	In this case we bind the previous created LDAP and RADIUS Policy. Important: If we want to have multiple authentication in turn we need the GoTo Expression.
	The second label is the LDAP only label for the user authentication.
	There we just bind the LDAP policy.
	A third label is used to find the membership of a given user and select the appropriate „nextFactor“ So input a name and select the noSchema.
	Now we select the policy to check if a user is member of the App-User and select the next factor. Which represents the LDAPonly label.
	Same is done with the Admin user check. Here the two factor label is selected as „nextFactor“
	In the end the label should look like this.
	So in the end we have three labels.

Create AAA vServer

To put the things together we need a AAA server.

	Click on add
	First we have to set a name and an IP address as well as a port.
	Select a certificate.
	Continue
	Now select a default logon schema for the vServer.
	For the default schema a schema policy is needed. This can be set to true and profile is the LGS_QueryUsername
	With bind the schema is active.
	Now the authentication policies are bound.
	The first policy has to be the group extraction with the next factor for check the user or admin label.

 

Create IdP Profile and Policy

Create a Session Policy with the home page with is the cloud web app

Demo Authenication

Logon with user privileges

Logon with admin privileges

If the user has no rights, the following error is displayed.