Rethinking Web Based Access to Applications » ocb

Post to Twitter | Comments (8) | Views (22536) |

24 Nov 2006 12:00 AM EST

Rethinking Web Based Access to Applications

[ Tags: architecture , web interface , client detection , informed consent , nonspecific ]

I am delighted to report that Web Interface 4.5 has officially been published on MyCitrix this week, the fruit of 18 months of intense collaboration by a team extending more than halfway around the world, numbering well into the dozens. Another fruit of this effort is the first release of an officially supported WI portlet for IBM WebSphere, which follows the release of WI for Microsoft SharePoint almost a year ago. There were twists and turns aplenty throughout those 18 months, right up to the final hour before we pushed the "Go!" button, but in the end we had lift-off on schedule and WI is now safely in orbit - err, I mean you can download it. (We had a brief problem with a couple of loose tiles, but hey it was a bumpy ride!)

It is more than 2 years since I started working on initial planning for this release, looking at how Citrix could deliver a single Suite-wide web UI that provided a consistent front-end for all the 'premise-based' products we were then offering (Presentation Server, Secure Access Manager and Password Manager). Two of the original goals were to provide a consistent set of authentication methods for all web UIs, and the ability for individual product web UIs to be deployed together to form a single aggregate UI.

The second goal was realized with the release of WI 4.2 and Access Gateway Advanced Edition 4.2 last year, sporting an integration mode whereby WI renders the list of published applications in the AG 'NavUI' page, alongside the list of published web resources and file shares or documents. We implemented a custom single sign-on mechanism to support this integration, capable of sharing end point scan information collected by AG so that application and session policies on CPS can be triggered by the same information.

The first goal spawned our Callisto project which has evolved over time to put the focus on advanced single sign-on capabilities, since authentication support across AG and WI is now largely consistent and less of an issue than it was 2 years ago. ADFS and SAML have emerged as the key technologies and standards we are embracing for advanced SSO, and I know we will have more to say about this as our product capabilities increase and as the early adopters among our customers gain experience with the technology.

So, what's next?

For WI, our attention is now firmly focused on improving end user experience. First up is tackling how to provide remote access to applications when web browsers are becoming increasingly locked down and security conscious - it can no longer be taken almost for granted that a web site can provide remote access to CPS applications. The importance of this is being driven home by the release of Windows Vista last week, where some pretty major changes have been made to Internet Explorer affecting web sites with active content. WI essentially by definition is all about running active content, so this is crucial to us.

On top of the technical limitations to what can be achieved, the general climate in the industry is tightening. Spyware and concerns over malware generally have become a regular feature on front page news. Stringent guidelines have been published on how "goodware" (kindware?) should behave, to instill consumer and business confidence and protect both users and producers. Legislation is increasingly being adopted to back this up, just in case software producers haven't got the message.

Reconciling Security and Usability

So security and usability concerns are at the heart of what we are wrestling with at the moment. There is certainly tension between these concerns, but actually they are pulling the WI design in directions that are closer than you might suppose. For WI, usability is about making things simple and obvious, about providing resource access with as few questions and steps as possible. Security demands the user be informed about what is going on and in control so that things only happen with his consent. But consent requires understanding, and understanding requires speaking the user's language and presenting only choices that make sense and are relevant to him - ie. keeping it simple and obvious.

The real challenge is to figure out which choices can be reasonably decided automatically, and when and how to present and explain the choices that the user really needs to decide for himself.

Calling all clients: you need software!

Let me give an example. WI has three different software options to connect to CPS applications: the "native" ICA client (which can be used in two ways), the Java ICA client, and in some environments the Microsoft Remote Desktop Connection client.

These options mean nothing to most users. Actually, they are worse than nothing because the options are completely baffling to most users.

We found out recently that just using the term 'client' to refer to the software needed to access applications can be confusing. After all, in everyday life client refers to a customer receiving a service - lawyers and estate agents have clients. If I'm not dying, divorcing or moving house why do I need to install 'client software'?!

It is no wonder that a fair few Citrix deployments disable WI's client selection UI. (In 4.5 we made it easy to hide all the user preferences UI, including the Advanced Options on the login page.)

What we plan to do about client selection

What we are currently thinking would make more sense is the following. (This is very much work in progress; feedback is welcome and we will update you as we work through this design.)

Using all reasonable tricks and established techniques, we will silently detect as much as we can about the browser environment's ability to use each type of client software. This means checking for the ICA ActiveX control on Internet Explorer on Windows, checking if pop-up windows are allowed, if Java support appears to be enabled, and if an RDP ActiveX control appears to be available and the WI site is in a suitable IE security zone. (Currently we think we can detect pretty much everything we need to know in an essentially silent fashion, though there is the possibility we will have to prepare the user if a necessary test could trigger a browser warning prompt of some kind.)

So far so good, but now things start to get tricky.

If we don't detect a native ICA client, but do discover that Java is working, what should we do? Just because we didn't detect the native client doesn't mean it isn't installed - it might be that it is installed but our ActiveX check is blocked by IE security settings (which wouldn't necessarily stop us using the client for launches). Should we offer the user the chance to install the native client software (or confirm that it is already installed) before proceeding? But if it isn't installed and installation fails (or the user is unsure about installing it), how do we explain that there is another way to launch applications after all?

Our plan right now is to avoid this dilemma by making a reasonable decision without asking: if we can determine there is some way to launch apps, we will automatically use the best available method - in this case the Java client.

However, in doing this we've created another problem - the user experience with the Java client might be unsatisfactory or even broken in some way (say because drive mapping is disabled, or printing doesn't work well). We now need to indicate to the user somehow that they might experience difficulties, depending on what they are doing with the applications, but they might yet be able to resolve the difficulties (we can't be sure yet) by trying to install extra software.

To deal with this, we plan to continue using the "install caption" portion of the message area to flag that the user might experience problems launching or running applications, but there is potentially something he can do about it. The message will include a link to an explicit client detection and download wizard that will guide the user through the process of determining what options he has for accessing applications, including downloading and installing software and adjusting browser settings if appropriate.

There are many details of this wizard that we are working through right now; once we have some storyboards we are reasonably happy with, I'll post them here for comment. In the mean time, I would love to hear suggestions on what would work better or what might not work so well.

Cheers,
AndrewI

Labels

Comments (8)

Anonymous says:

Anonymous says:

Anonymous says:

Anonymous says:

Anonymous says:

Anonymous says:

Anonymous says:

Anonymous says: