The Security Assertion Markup Language (SAML) provides a standard for transmitting authentication information between organizations. In particular, SAML can allow users to access resources from an entirely separate domain using their own credentials.

With the latest release of StoreFront, Citrix can now provide the benefits of SAML alongside the app store experience of StoreFront for the first time. This solution can be used to help a service provider’s clients access hosted applications, provide a fast way to onboard new employees after a merger or acquisition, deliver critical applications to external healthcare clinics, and more. Ultimately, Citrix’s SAML support adds another layer of flexibility to address today’s fast-paced IT environment.

Recently, I have been involved in a number of discussions with customers that were looking to know more about how to use SAML with StoreFront.

I quickly realized that there was a lack of consolidated information on the subject–something I hope to help resolve today. The guide below provides an example of how SAML support can be configured with NetScaler, StoreFront, and XenApp. For simplicity’s sake, I have assumed that those reading this are aware of Kerberos, certificates, configuring Active Directory Federation Services (ADFS), installing the core Citrix components involved, and configuring a basic vServer on NetScaler Gateway. I also need to mention that this solution is currently only supported for StoreFront 2.6 and XenApp 6.5 with XML IIS Integration installed.

Before we get started, I’d like to extend a special thank you to Michael Colson, Nelson Esteves, James Hsu, and the StoreFront product team for providing support during various projects that led to the creation of this guide.

The Environment

To provide an easier way to keep track of the two domains involved in this configuration, the guide will reference two fictional entities. The Hosting Environment (the.lab) contains a single instance of NetScaler 10.5, StoreFront 2.6, XenApp 6.5 with XML IIS Integration, and a certificate authority. Xirtic (xirtic.lab) is acting as the Identity Provider (IdP) in this scenario and contains a single instance of ADFS 2.0 and a certificate authority. Because the guide uses local domains in a lab environment, I have opted to use certificates generated from internal certificate authorities. In the real world, using signed certificates from trusted public certificate authorities to secure external communications is recommended.

Communication Workflow

saml-architecture

Configure Kerberos Delegation Rights

  1. Configure the XenApp server for delegation
    1. On THE’s domain controller, open the Active Directory Users and Computers MMC console
    2. Ensure that Advanced Features are enabled by navigating to View > Advanced Features
    3. Navigate to the computer account for the XenApp server and select Action > Properties
    4. Select the Delegation tab, click Trust this computer for delegation to specified services only, click Use Kerberos only, and then click Add
    5. Click Users or Computers in the Add Services dialog box
    6. Search for the XenApp server’s name in Active Directory and click OK
    7. Select the HOST service type and then click OK
    8. Click Add and then Users or Computers again
    9. Search for the domain controller’s name in Active Directory and click OK
    10. Select the cifs and ldap service types and click OK (if multiple entries exist for ldap choose the one matching the domain controller’s FQDN)
    11. Apply the changes and close the dialog box

step-1-2

  1. Configure the StoreFront server for delegation
    1. On THE’s domain controller, open the Active Directory Users and Computers MMC console
    2. Ensure that Advanced Features are enabled by navigating to View > Advanced Features
    3. Navigate to the computer account for the StoreFront server and select Action > Properties
    4. Select the Delegation tab, click Trust this computer for delegation to specified services only, click Use any authentication protocol, and then click Add
    5. Click Users or Computers in the Add Services dialog box
    6. Search for the XenApp server’s name in Active Directory and click OK
    7. Select the http service type and then click OK
    8. Apply the changes and close the dialog box

step-2

Configure XenApp 6.5

  1. Allow THE’s XenApp server to trust incoming XML requests
    1. On the XenApp server, open the Citrix AppCenter console
    2. Expand the XenApp farm and click the Policies node
    3. In the Computer tab, select New… to create a new policy
    4. Name the new policy and select Next
    5. Navigate to the XML Service category and click Add on the Trust XML requests policy
    6. Select Enabled, click OK, and then click Next
    7. Add a worker group or Active Directory organizational unit filter that contains the XenApp servers involved with SAML access and click Next
    8. Ensure Enable this policy is checked and click Create

step-3

Configure StoreFront 2.6

  1. Enable Smart Card Authentication on the StoreFront store
    1. On the StoreFront server, launch the Citrix StoreFront administration console
    2. Select the Authentication node
    3. In the Actions Pane, click Add/Remove Methods
    4. Check Smart card and then click OK

step-4

  1. Enable smart card authentication on StoreFront’s NetScaler Gateway
    1. On the StoreFront server, launch the Citrix StoreFront administration console
    2. Navigate to the NetScaler Gateway node and select the Gateway that will be used for SAML authentication
    3. In the Actions Pane, click Change General Settings
    4. Select Smart Card for the Logon Type field and click OK

step-5

  1. Enable Kerberos Constrained Delegation on StoreFront
    1. On the StoreFront server, launch the Citrix StoreFront administration console
    2. Select the Stores node and then select the store that will be used for Kerberos authentication
    3. In the Actions Pane, click Configure Kerberos Delegation
    4. Check Use Kerberos Delegation to authenticate to delivery controllers and then click OK

step-6

  1. Apply NTFS permissions for StoreFront’s Protocol Transition service
    1. On the StoreFront server, navigate to C:\Program Files\Citrix\Receiver StoreFront\Services\ProtocolTransitionService
    2. Open the file properties of AccessList.txt and navigate to the Security tab
    3. Select Edit and then Add…
    4. Type the users or group that need SAML access (this guide uses the Domain Users group for simplicity), click OK, and then apply Read permissions to all users or groups that need SAML access

step-7

Configure NetScaler Gateway

  1. Import the public key of Xirtic’s ADFS signing certificate into THE’s NetScaler
    1. Login to THE’s NetScaler appliance
    2. Within the Configuration tab, navigate to Traffic Management  > SSL > Certificates, and click Install
    3. Give the certificate key-pair a name, select the down arrow next to the Browse button for the Certificate File Name field, and then click Local
    4. Select the public key of Xirtic’s ADFS signing certificate and then click Install

step-8-3

  1. Create a SAML authentication policy for NetScaler Gateway
    1. Login to THE’s NetScaler appliance
    2. Within the Configuration tab, navigate to NetScaler Gateway  > Policies > Authentication > SAML
    3. Select the Servers tab and then select Add
    4. Fill out the form with the following values:
      • Give the server profile a name
      • IDP Certificate Name: Select Xirtic’s ADFS signing certificate from Step 8
      • Redirect URL: Enter the ADFS server’s federation URL (Default: https://<ADFSServiceURL>/adfs/ls/)
      • User Field: Type Name ID
      • Signing Certificate Name: Select the NetScaler’s existing Gateway certificate
      • Issuer Name: Type NetScaler
    5. Click OK
    6. Select the Policies tab and then select Add
    7. Give the policy a name, select the SAML server configured previously in the Server field, type ns_true in the Expression field, and click Create

step-9-1-2

  1. Bind the SAML authentication policy to an existing Gateway vServer
    1. Login to THE’s NetScaler appliance
    2. Within the Configuration tab, navigate to NetScaler Gateway  > Virtual Servers
    3. Select an existing Gateway vServer that will be used for SAML authentication, and then click Edit
    4. Click the plus sign located in the top right corner of the Authentication section
    5. Choose SAML as a policy type and then click Continue
    6. Select the SAML policy created in Step 9, click OK, and then click Bind
    7. Remove the bindings for any other authentication policies bound to the Gateway vServer. While it is possible to use multiple authentication policies on a single Gateway vServer, this is not covered in this guide.

step-10

Configure an ADFS Relying Party Trust

  1. Use Citrix Support article CTX140562 as a guide to manually configure ADFS to trust NetScaler as a Relying Party
    1. Although the guide is written with Windows Server 2012, the ADFS configuration within Windows Server 2008 is similar
    2. The Relying party SAML 2.0 SSO service URL field maps to the URL of the NetScaler Gateway vServer with /cgi/samlauth appended to the end
    3. The Relying party trust identifier should match the Issuer Name given with the NetScaler Gateway’s SAML policy configured in Step 9
    4. For the purposes of this guide, only the SAM-Account-Name / Name ID LDAP attribute needs to be mapped to a claim rule
    5. The signature certificate for the relying party should match the public key of the certificate used for the Signing Certificate Name field in Step 9
  2. Configure the trust to use SHA-1 encryption
    1. Open the properties of the Relying Party Trust configured in Step 11
    2. Navigate to the Advanced tab, select SHA-1 as the Secure hash algorithm, and click OK

step-12

Add Shadow Accounts to THE’s Domain

  1. Shadow accounts are used by StoreFront to map an incoming user’s credentials to an internal Windows identity. This Windows identity is then used by StoreFront and XenApp to launch applications. In order to launch applications using a SAML authenticated user, we must create shadow accounts in THE’s Active Directory that mimic the usernames of Xirtic’s users. More information on how to create shadow accounts can be found here.

Issues Seen During Implementation

Caution! Using Registry Editor incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.

  • Issue: When launching an application, a user may be shown an “Access is denied” message from Windows before Receiver closes.
    Resolution: On the XenApp server, add the IgnoreRegUserConfigErrors DWORD with a hexadecimal value of 1 to the following location:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\

It’s Here! The Federated Authentication Service for XenApp & XenDesktop

0