Previous versions of StoreFront supported SAML authentication for remote users, leveraging the SAML support in NetScaler. Now with StoreFront 3.9, the available use cases have been extended to include scenarios where direct SAML 2.0 authentication to StoreFront is required.
This article will discuss what aspects of SAML are supported, along with general information to help you be successful with this feature.
SAML Support
StoreFront 3.9 provides SAML 2.0 support, utilizing the Service Provider-initiated flow, with both redirect and post bindings for the initial SAML request. The initial request can be signed (the default) or unsigned. For the SAML response, only signed responses are accepted. The SAML response can be delivered as a plain response, or encrypted through the post, redirect or artifact resolution bindings. The deployment of the feature automatically creates signing and encryption certificates, but these can be managed through the PowerShell API.
StoreFront 3.9 also has support for metadata exchange to ease the burden of wiring up the SAML trust between the Identity Provider (IdP) and StoreFront as the Service Provider (SP). Each StoreFront authentication service is a separate Service Provider, with its own Service Provider Id, Assertion Consumer Service and metadata Urls. StoreFront 3.9 can also consume the metadata from the IdP, but only through leveraging the PowerShell API. Also note, that there is no monitoring on the IdP metadata endpoint, and updating from the metadata is a manual task.
StoreFront 3.9 has no support for SAML Single Logout.
Citrix Receiver Support
The most common use of SAML is with browsers, and Receiver for Web supports SAML authentication. However, SAML support to StoreFront 3.9 is also available from the native Receiver for Windows v4.5 and onwards.
Configuration with the StoreFront Administration Console
The trust wire-up between the StoreFront administration console also facilitates manual configuration of the trust between the IdP and StoreFront as the SP.
First open the StoreFront management console, select the store that you wish to use SAML with, and then select “Manage Authentication Methods”
In the “Manage Authentication Methods” dialog, select the “cog” next to the SAML Authentication method:
Select “Identity Provider” to configure how StoreFront communicates with the Identity Provider:
The “SAML Binding” defines at the http level how StoreFront initiates the SAML flow with the IdP, this can be either POST or Redirect. The “Address” is the IdP address where the initial request will be sent.
The “Signing Certificates” represent the trust configuration, and should contain information about the certificate used by the IdP to sign the SAML Assertion. “Add” allows the required information to be added manually. “Import” will determine the required information from a certificate, if it has been exported from the IdP.
Select “Service Provider” to manage the information required by the IdP
This dialog allows you to export the public parts of the signing certificate used by StoreFront to sign its SAML requests, and the encryption certificate used by StoreFront to decrypt, encrypted assertions.
The “Service Provider Identifier” is the identifier used by the IdP for this SAML Service Provider.
The information required by the IdP for trust can also be obtained using PowerShell as shown in the sample here: http://docs.citrix.com/en-us/storefront/3-9/sdk-overview.html#par_anchortitle_a8db
Test Page
StoreFront provides a test page that exercises the SAML flow outside of Receiver. This can be found at the Url /SamlTest relative to the authentication service associated with the store.
The test page, first redirects to the IdP for authentication, and then displays the identity of the user who logged in, along with the claims and the SAML assertion:
Upgrade from Earlier Versions
If you upgrade from a previous version of StoreFront, then the SAML authentication method will not be immediately available, and must be enabled by the administrator, as follows:
First open the StoreFront management console, select the store that you wish to use SAML with, and then select “Manage Authentication Methods”, as described above.
Next select the “Advanced” drop-down, followed by “Install or uninstall authentication methods”
In the resulting dialog, select “SAML Authentication”
SAML Authentication now appears in the list of available authentication methods:
Account Mapping
StoreFront 3.9 has no capabilities for either mapping accounts or managing “shadow” accounts. Instead it relies on the Identity Provider including the SAML NameID [http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier ] assertion whose value is the same as the userPrincipalName attribute of the Windows account that will be used.
StoreFront Authentication SDK
In common with the other authentication methods, SAML has been implemented using the StoreFront Authentication SDK https://www.citrix.com/community/citrix-developer/storefront-receiver/store-authentication-sdks.html . However, the SDK had to be extended to provide the capabilities required.
The SAML method has been modelled using the Receiver Common Forms protocol in order to extend it to native receivers. This has required a new credential type to be added: webview. This manages the transition from the Forms protocol to a browser based authentication method, such as SAML, and the transition back to Forms, once the user has authenticated.
The second change has been the introduction of Generic Forms. Each authentication method is uniquely defined by its protocol name. Both the server and client have to recognise the name used. However, it is clear that many authentication methods can be modelled as Receiver Common Forms. Rather than have to update clients and servers with new protocol ids, the concept of Generic forms has been introduced for protocols implemented by Citrix. The Receiver for Windows and Receiver for Web both have the knowledge that any protocol starting with “Forms-“ should just use the existing Form processing for that protocol.
Note, customisations that third parties or customers build, should still use the CustomForms protocol name.
More Information
Further information can be found on the Citrix Documentation site:
- Overview: http://docs.citrix.com/en-us/storefront/3-9/plan/user-authentication.html#par_anchortitle_904a
- PowerShell SDK Documentation: https://citrix.github.io/storefront-sdk/Citrix.StoreFront.Authentication.Saml/Citrix.StoreFront.Authentication.Saml/
- Metadata Exchange PowerShell sample: http://docs.citrix.com/en-us/storefront/3-9/sdk-overview.html#par_anchortitle_78af
- Service Provider information: http://docs.citrix.com/en-us/storefront/3-9/sdk-overview.html#par_anchortitle_a8db
