In this implementation, you integrate Access Policy Manager® (APM®) with Citrix XML Brokers and present Citrix published applications on an APM dynamic webtop.
APM integration with Citrix XML Brokers
For Citrix Receiver Windows and Linux clients: only Active Directory authentication is supported.
For Citrix Receiver clients for iOS, Android, and Mac: Active Directory, or both RSA and Active Directory authentication is supported.
For web clients, you are not restricted in the type of authentication you use.
A dynamic webtop enables Access Policy Manager® (APM®) to act as a presentation layer for Citrix published resources. APM communicates directly with Citrix XML Brokers, retrieves a list of published resources, and displays them to the user on a dynamic webtop.
The addresses of XML Brokers are configured in pools on APM. A pool includes addresses from one Citrix farm. You specify a pool as a destination in a Citrix remote desktop resource. Each resource logically represents a Citrix farm. You can assign multiple resources to a user, enabling the user to access Citrix applications from multiple Citrix farms.
The Client Type action determines whether the client is using a full browser, the BIG-IP® Edge Client, or another client to access the Access Policy Manager® (APM®). This action makes it possible to specify different actions for different client types in one access policy and, as a result, to use one virtual server for traffic from different client types. This figure shows the Client Type action as it looks when first added to an access policy.
By default, the Client Type action includes these branches:
APM supports the client types on multiple operating systems. Refer to AskF5™ (support.f5.com) to look up the supported operating systems and versions in the compatibility matrix for your version of APM.
A Citrix client bundle enables delivery of a Citrix Receiver client to a user's Windows computer when a client is not currently installed, or when a newer client is available. Access Policy Manager® (APM®) detects whether the Citrix Receiver client is present and redirects users to a download URL, or downloads a Citrix Receiver client that you have uploaded.
In Access Policy Manager, you specify the Citrix client bundle in a connectivity profile. By default, a connectivity profile includes the default Citrix bundle, /Common/default-citrix-client-bundle, which contains a download URL, receiver.citrix.com.
Access Policy Manager® (APM®) supports two single sign-on options for Citrix that provide password-less authentication:
These options work in APM only when:
An iApps® template is available for configuring Access Policy Manager® and Local Traffic Manager™ to integrate with Citrix applications. The template can be used on the BIG-IP® system to create an application service that is capable of performing complex configurations. You can download the template from the F5® DevCentral™ iApp Codeshare wiki at https://devcentral.f5.com/wiki/iApp.Citrix-Applications.ashx. A deployment guide is also available there.
Ensure that you configure the Citrix components in the Citrix environment, in addition to configuring the BIG-IP® system to integrate with Citrix XML Brokers.
Perform these tasks on the BIG-IP system so that Access Policy Manager® can present Citrix published resources on a dynamic webtop.
You should have an access policy that contains actions for both Citrix Receiver client types.
Example access policy for legacy Citrix Receiver clients and later Citrix Receiver clients
Here is a typical example access policy that uses Citrix SmartAccess filters to restrict access to published applications based on the result of client inspection. Client inspection can be as simple as IP Geolocation Match or Antivirus. The figure shows an access policy being configured with a Citrix Smart Access action to set a filter to antivirus after an antivirus check is successful.
Example access policy with Citrix SmartAccess action and an antivirus check
If you have configured Access Policy Manager® for smart card authentication and your users cannot enter a PIN before the SSL handshake times out, they can experience problems such as browser failure or errors because the BIG-IP® system sends a TCP reset after the SSL handshake times out. You can mitigate this problem by increasing the handshake timeout in the client SSL profile.
By default, a client SSL profile provides a 10-second SSL handshake timeout. You might need to modify the timeout to give users more or less time for the SSL handshake to complete.