When transferring execution content with Citrix Application Streaming, the source of the copy for execution image comes from the Application Hub, which is a fancy name for a file server or web server.  There is no Citrix code on the App Hub which makes it even more mysterious to give it a fancy name.  The name though is growing on me.

In the beginning, there was only UNCaccess to the Application Hub contents and this made authentication pretty simple, the LAN requester takes care of it.  In streaming client 1.2, we added web server support (http streaming), which engages a bunch of new use cases as administrators have lots of tools for managing web servers.

Here’s the big picture view.  

The piece we care about here is the upper right circled item.  Notice that all the publishing information comes from the XenApp publishing infrastructure; this information is ultimately delivered to the streaming client via the Web Interface and a slight detour through the online plug-in, the artist formerly known as PNAgent.
Eventually, the streaming client is told to “run something” and when this happens, the application execution material is “sucked down” from the Application Hub and placed into the RadeCache for execution.

There are multiple aspects to authentication. 

In a UNC / LAN Manager configuration, this question of access is easily tied to the publishing.  The network file sharing client software takes care of validating file servers and validating user access to file servers. 

Administrators generally put all the applications onto a single App Hub and each profile gets its own sub-directory. 

Since profile directories are “one directory” per profile, access lists can be maintained on the directory and everything associated with the profile is controlled in a single spot.  In the XenApp Access Management Console, administrators publish the application to a “user group”, the XenApp IMA, WI, PNAgent will deliver icons to the user based on their membership in the group.  At the same time, the DACLs on the directories on the file share can also be tied to the same GROUP. 

Add a user to the group, they get the app and all access concerns are taken care of automatically. Awesome stuff.

Admins are free to not lock down the App Hub content at all, but XenApp admins are not known for being “information free” type of people and they tend to lock down everything and then open up where needed. 

What happens at runtime
When the user runs the application using a file server based App Hub, the streaming client will attempt to open the streaming target files on the file server.  This is the profilename.profile file and the GUID_version.cab file that is the streaming target.  On the first access, if the user does not already have a connection to the server, the file sharing client code will create one and authenticate the user to the server. 

Here’s the cool part – the LAN code takes care of this and even prompts the user for credentials, presumably securely.  The streaming system is completely oblivious that any of this occurs, but eventually, the connection is established and the application is run.  Remember the prompt for credentials…

Web Server App Hub

If the App Hub is web based, the streaming system does the same thing to open the .profile file and open the CAB file that represents the execution target.  BUT, the authentication steps are different.  The streaming system never ever has the user credentials; to be clear, we never have the user credentials.  It also never triggers a prompt for those credentials, BUT the web libraries could still have credentials and can still use these credentials to establish a connection with the web server.

Should the user’s credentials be transferred?  What does that even mean?  Stick with me.

When the streaming client establishes a connection with the web server, authentication may be required.  I note that it is optional, the web server COULD be wide open for world access, but again, XenApp admins tend to be “lock it down” kind of people.  The streaming client will make this connection using the “user context”, but there’s still an authentication.  Does the user have access?  How’d you decide that?

Here, the authentication falls onto WinHTTP library from Microsoft.  The streaming system though is still involved to set up parameters for the connection.  If the environment is Active Directory and the Web Server is IIS and authentication is based on logged in user, then … no problem.  Everything happens based on the user logon TOKEN and all access is securely controlled and no user secrets were transferred in the clear.  Happy days.

What if other techniques are used?  What if Apache web server?  What if no AD?  Answer: The streaming system does not prompt for credentials and this can mean that authentication will fail.  It also means more things.

HTTPS connection

Do you need to authenticate that the web server is “legit”?  Given the web server has SSL certificates, the validity of the web server can be authenticated.  This is good and it is automatic if you use “HTTPS” as the prefix for the App Hub location.  It still doesn’t validate that this user has access to the application bits that are stored on the web server (app hub).  But at least you know that the web server is legit.

Questions I have

Do you lock down your HTTP based App Hubs?  Or is this reserved just for file server based execution?

If all your users are allowed to see all your profiles, then no worries.  Authenticate the web server and you’re done.  This though means that all the application profiles are available in vision to all users, so likely not the right answer. 

How bad is the cost of the HTTPS connection vs. HTTP?

If you DO prevent users from seeing profiles to which they are not authenticated, then user authentication is required.  If this is not tied to the user authentication, web authentication system, then it’s more complicated.  The streaming system never has the credentials, but it can trigger the WinHTTP library to send them.  Most of this is automatic from the HTTP libraries in the OS, but there’s still work to get it good.

Credentials in the clear

I have received a request that the streaming system should PREVENT any web authentication that would EVER send user credentials “in the clear”.   It seems to be a reasonable request and we can/could do this by configuring the connection when it is created, a relatively small amount of programming. 

All we need is a release vehicle, which conveniently, is coming up.

The downside is that if you’re using methods which would require credentials in the clear, you’ll be … broken after the upgrade.  I mean broken as in “nothing streams”.  I expect we’ll include a registry override to say that “yes, I want to shoot myself in the foot”, but most admins though will likely say “wow!, thanks for helping me find that mistake!”.

The proposal is to require at least SPNEGO user authentication for any web server that requires authentication.

I appreciate any Jedi Web-Master feedback on how this should be “properly done”.  THANKS!

NOTE: This post originally posted January 19th, but it disappeared.

NOTE 2: Since writing this post, streaming development team have implemented the change and it will occur in the “next” streaming client.  This could break some people; if it does and you’re okay with credentials in the clear, there will be a registry item to turn off the improved behavior.  Reg item not yet named.

Joe Nord

Citrix Systems Product Architect – App Streaming and User Profile Manager