For quite some time now Web Interface has supported a "single sign-on" feature where the user is shown their published application icons without ever having to provide a username and password.
The way this works, in a nutshell, is the following:
- From a domain workstation, the user points IE to an IIS domain member web server. IIS performs Integrated Windows Authentication (using either NTLM or Kerberos) to ascertain the user's identity.
- Web Interface reads the user identity and performs a lookup to determine which domain groups the user belongs to.
- The list of groups (SIDs) is sent to the Presentation Server XML broker and the applications published to those groups is returned to Web Interface.
That takes care of getting the icons painted on the web page, but connecting to one of those application uses an entirely different authentication method: the ICA client must eavesdrop on the user's workstation logon, store the credentials in memory (ssonsvr.exe) and then replay those credentials (or send a Kerberos ticket) through an ICA virtual channel when connecting to a Presentation Server.
As you can see, the initial web server authentication does nothing to help with the ICA session authentication. If you have ever struggled with a deployment of Web Interface that uses the "Pass-through" authentcation method, you are all too familiar with the pain-points that this situation creates:
- Users require changes to their appsrv.ini file in order to support the sending of their password or Kerberos ticket through an ICA virtual channel (SSOnUserSetting=On and EnableSSOnThruICAFile=On)
- After installing the client, users must log out of their workstation and then log back in again so that ssonsvr.exe can learn their credentials
You can eliminate those pain points by leveraging the ADFS-enabled version of Web Interface. This is available today as a special post-4.2 release, and ADFS support will be part and parcel of Web Interface 4.5 when it ships.
Active Directory Federation Services (ADFS) was designed to federate user identity across organizational boundaries. It allows a user's identity, validated in their home domain, to authorize them for applications in a foreign domain. If you're new to ADFS, start here. The short story is that users in Domain A can access resources in Domain B with no trust relationships required.
ADFS is typically regarded as a single sign-on tool for .NET web applications, but the ADFS-enabled Web Interface release empowers you to deliver the same degree of federated single sign-on for applications hosted on Citrix Presentation Server. You can read more about the current ADFS WI release here:
Web Interface with ADFS Support Administrator's Guide
If you're still reading at this point, congratulations! We're past the obligatory intro material and here's where it starts to get interesting. The administrator's guide referenced above explains that you must create "shadow accounts" for users in the foreign domain, complete with an alternate UPN suffix in your domain. For example, if the CPS servers are in the treyresearch.com domain and the users are in the adatum.com domain, the treyresearch Active Directory domain would have to be configured to support adatum.com as an alternate UPN suffix, and then accounts for each ADatum user would have to be created, using the adatum.com suffix, in the TreyResearch domain.
You're supposed to set up a federation server in both domains, one for the account partner domain (where users are authenticated) and one for the resource partner domain (where CPS resides). But the technology behind identity federation can be used for more than just the typical B2B type scenarios.
Interestingly, you can treat a single domain as both the account partner and the resource partner. If you set up a federation server in your CPS domain but forego the whole process of defining an Account Partner, users within the CPS domain can still point to the ADFS-enabled web interface site and get signed on automatically. What's more, creating the so-called "shadow accounts" is not necessary in this scenario, as WI will use the pre-existing domain user accounts when it validates your federated identity.
The end result is a Web Interface site that displays application icons automatically AND signs the user onto a Presentation Server without requiring the client to send credentials or Kerberos token through the ICA client. Client machines need not have any special settings in their appsrv.ini because a new Kerberos token is generated by the federation server, handed to Web Interface and then passed on to the CPS XML broker.
Can you say zero help desk calls?! If you want to try this, be aware that you'll need Windows Server 2003 R2 for the federation server and Web Interface server. (The WI and Federation servers can be hosted on the same machine if you are short on boxes.) The requirements are all spelled out in the administrator's guide referenced above, but I want to emphasize that you do not need to upgrade your CPS servers to R2. They just need to be CPS 4.0 with Hotfix rollup pack #2 or better.
This example of using ADFS without an external account partner is a slightly abnormal application of the ADFS feature, and it's only the tip of the iceberg in terms of the new possibilities that federation brings to the table. I've also toyed with a scenario where the user authentication can be performed by a soft certificate stored in the user's profile:
Take a workstation that does not belong to your domain and install a user certificate in the web browser on that workstation. Then configure the ADFS account federation server web agent scripts to require SSL Client certificates and enable the directory service mapper in IIS. When WI redirects the user to their account federation endpoint URL, they get challenged for a user certificate. The ADFS web agent reads the certificate, maps it to an AD account and then passes your identity claims up to web interface. Users can log on from any workstation, regardless of the workstation's domain membership, and authenticate to Presentation Server using only their certificate. Without ADFS, the only certificate-based logon that CPS can support is using a physical smart card where PC/SC calls can be redirected through an ICA virtual channel.
There's no end to the authentication challenges you can solve by leveraging ADFS. It's a real game-changer! No wonder Andrew Innes, the WI architect, referred to the WI ADFS integration as a "monumentally huge tectonic shift ".
Are you using ADFS in creative ways yet for your Citrix users? If so, I'd love to hear about it.
Jay