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
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.
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
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.
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
3. RADIUS as second factor authentication
|In preparation for the second factor, a RADIUS authentication can be created.
|Also, here we can check if the communication is ok
|Afterward the server is created.
|Create Advanced RADIUS Policy for Authentication as second factor
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
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)
3. Logon Schema to query the LDAP and RADIUS password for admin user
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.
Create AAA vServer
To put the things together we need a AAA server.
Create IdP Profile and Policy
|The last step is to create a SAML Policy, to have
|The profile is a SAML IdP Profile to create an assertion, which can be customized to insert different attributes.
Create a Session Policy with the home page with is the cloud web app
Logon with user privileges
Logon with admin privileges
|When an admin user is inserted
|The group extraction finds the user in the App-Admin group and will start the Two-Factor schema.
If the user has no rights, the following error is displayed.
Marco Klose works as a Technical Consultant, Architect and CTO focused on Application & Desktop virtualization as well as application delivery with the Citrix product portfolio. He is specialized in Citrix virtualization, Citrix networking and Microsoft products. He has +10 years experience and holds the latest Citrix certifications and is member of the Citrix Partner Expert Council EMEA (PTEC). Since 2021 he is also a Citrix Technology Advocate (CTA).