Thoughts and opinions from Citrix architects
In my last post, I talked about our plans of moving XenApp farm settings, server settings and session policies into Group Policy Objects. This time, I want to describe our plans on a related topic: how to migrate XenApp 4.x farms into this new management model.
XenApp 4.5 Administrators have two options to migrate their farms: either upgrade the existing farm over time, running the farm in mixed-mode; or create a new farm and move users and applications over time.
The mixed-farm approach seems to be the easier of the two, but it has an important drawback: the migration cannot be staged. The recommended first step is to upgrade the Zone Data Collectors, which in turn affects all users and applications in the farm. If anything wrong happens - which is usually detected once users start to login and use their applications - there is no way to rollback without creating a farm outage.
The new farm approach is safer, as it allows Administrators to perform an "in-production" validation, migrating users and applications to the new version over time. The old production farm is not touched, which allows quick rollback of users to the previous farm if anything wrong is detected.
However, creating a new farm from scratch is not realistic in many environments. The reasons:
- Farm configuration documents may not exist, or be out-dated.
- Not sufficient hardware to maintain both farms in parallel. Servers have to move from one farm to other over time.
- The migration is not transparent to end-users. If a single Web Interface is used, it will list applications as "Application (Old Farm)" and "Application (New Farm)". If a separated WI is used, then users must configure browser and PNA to use another URL.
We do not plan to support mixed-farm migrations when we move XenApp configuration to Group Policy. Instead, we will focus on the issues above, creating the necessary tools to facilitate the transfer of configurations, users and servers from farm to farm.
This is the plan:
The first step is to create a new farm, installing a new Data Collector and creating a new IMA database. Infrastructure servers (License, Database, Edgesight, etc) may be shared between the old and new farm. The next step is to launch the Migration Wizard and go through the following steps:
- The migration tool wizard will ask information about the old farm (address, authentication). You may chose to export all the old farm data into an XML file and modify it before importing the data in the next steps.
- The wizard will ask the new farm information. It will then convert session policies, farm and server settings into Group Policies, and automatically associate GPOs with the new farm Organizational Units.
- If the old farm contained multiple application silos, the wizard will ask for a server that represents the old farm silo, and create a Group Policy Object containing that server configuration. The wizard will then associate that GPO with the OU representing the Application Silo in the new farm configuration.
- You will be able to select a list of "in-production" test users. The new farm will only enumerate applications to users in that filter list, regardless of the Application object configuration.
- Add the new farm in your Web Interface sites. Web Interface will suppress enumeration of applications coming from multiple farms, based on configuration. This change will make the migration process completely transparent to end users.
At this point, you will have a fully configured, although empty new farm. Over time, you will:
- Add more users to the new farm filter
- Remove servers from the old farm
- Upgrade XenApp software in the server (or re-image)
- Assign the server to the new farm Organizational Unit.
This method is very flexible, you may stage the process based on application silos, zones, users, or any combination of these. The migration tools provided here are also very useful for other use-cases, such as replication of settings between test and production environments.
This plan is still on the drawing board, please feel free to comment and raise scenarios where you believe it wouldn't meet your needs. Note that this is planned for the next major release after project Delaware, therefore still a long way in the future.
Hello, this is my first post in this community, so let me start with a brief introduction: my name is Juliano Maldaner, a product architect on the Presentation Server team. One of the areas I'm working on is the simplification of Presentation Server management experience for upcoming releases. We're introducing some exciting new concepts and would like to hear your feedback!
Managing a Presentation Server farm requires much more than configuring Presentation Server components: Operating System and Application settings are as important. A successful environment must maintain PS, Operating System, and Application settings correctly configured and consistent across all servers in the farm. Maintaining this consistency throughout the farm life cycle is one of the major challenges for PS Administrators.
The Windows platform provides an outstanding tool to address these configuration management challenges: Active Directory and Group Policy. An overwhelming majority of PS deployments use Group Policy in some capacity. Integrating PS settings into GPO is possible with MFCOM scripts, but far from ideal. Most use GPO for Windows and Application settings, and Citrix management consoles for PS configuration. Because all settings must be synchronized, we realized that the management experience would be greatly simplified if PS Session Policies and Server settings were within Group Policy Objects themselves!
Presentation Server settings/policies embedded into Group Policy Editor
The main benefit of this integration is the creation a single management template for platform, applications and Citrix configuration. All operations performed with Group Policy Management Console will include Presentation Server parameters as well. Resulting Set of Policy reports will show all Citrix and platform configuration - a great help for troubleshooting and planning. Backup, Restore, and Migration will allow saving and moving configurations from farm to farm, making replication of environments much easier than what it is today.
Another key benefit is the separation of PS settings and servers. Group Policy Objects are associated with Organization Units, and not with individual servers or users. Common management operations - adding capacity to a silo; repurposing a server; or replacing a broken server - are greatly simplified: simply change the server OU membership, and the settings associated with that silo will automatically apply to the server.
Application Publishing
The Group Policy integration will NOT require Active Directory schema changes. For this reason, PS objects such as Applications and Administrators will continue to be managed via Citrix management consoles. Application Publishing will be modified to allow association of Applications with Active Directory Server Groups and Organization Units. This way, apps will be automatically published as soon as the server is assigned to the correct Organizational Unit.
Policy Filters
Presentation Server Group Policy extension will improve GPO filtering capabilities to include all filters existing on CPS 4.5 session policies - including SmartAccess. These filters will only apply to the Citrix part of the GPO, platform configuration will apply regardless of the filter result.
The Citrix policies within GPOs will also allow filtering on a per-setting level - native Group Policy only allow filtering per-policy level. Some Presentation Server features require complex filtered settings, for example: proximity printing based on client IP address. This feature will allow the configuration of such policies within a single GPO.
What about environments without Group Policy?
There are some important scenarios where Group Policies cannot be used:
- Environments using other Directory services;
- Applications that require anonymous (local) accounts;
- Organizations that restrict or deny AD delegation to PS administrators.
To support these environments, IMA will provide a global Group Policy Object, applied to all servers in the farm. This farm-wide GPO replicates the existing Farm Default settings. Per-server override is possible by configuring the server's Local Group Policy Object.
Our goal is to maintain feature parity with PS 4.5 if Group Policy is not used. However, the Administrator's experience will be optimized for Active Directory and GPO scenarios.
Active Directory and Group Policy are fundamental for a successful Presentation Server environment. Group Policy integration will bring major improvements to management experience, leveraging existing IT infrastructure and knowledge. The feedback we've received so far has been very positive, please let us know what you think!
Most people have a fairly well developed ability to assess trust when interacting with other people, which enables them to sense when situations are safe or not and whether to trust what other people say or to be suspicious of their intentions.
Let me give you an example, which perhaps just illustrates how some people (like me) aren't actually that well attuned to the signs. A couple of months ago, my wife and I agreed to let a double-glazing sales rep visit; we've been thinking we need to replace our windows before long anyway, so when a salesman rang we thought why not get a quote? (Hey, not everyone's sense of suspicion kicks in right away; I do try not to be cynical.)
So we agree a date and time with the sales guy on the phone, and no-one shows up. We're a bit irritated, because we changed our plans to wait in. Next week, the phone sales guy rings again, and when confronted apologizes that the rep who was supposed to visit the first time didn't come - he says the rep claims he visited and gave us a quote. It's impressive how persuasive good phone sales guys can be - he says he will offer us a 60% discount because of it - and after some hesitation we agree to a new time.
This time a rep does show up, and right away apologizes for the other rep not showing first time - and says "he was fired". (Hmmm.) Anyway, this one seems amiable enough and does the necessary inspection then gets down to the sales pitch. It is rather drawn out but finally he quotes a rather large number - then my wife points out that the phone sales guy promised us a 60% discount. The rep manages to look suitably furious and rings the office on his mobile, talks angrily for 10 minutes about how the phone sales guy has done it again and how he will have to honour the discount but it makes him so cross etc, then finishes the call and tells us the phone sales guy "will be demoted this time".
Okay, so if you were in my position, what would you be thinking now? Is this an honest situation, where circumstances and events should be taken at face value?
We respond sceptically about the price (the one with the 60% discount), and are about to start serving supper. The rep then quickly rings the office again and comes back with "we've got a job near here in three weeks and could do it that day - I'll give you an extra discount if you decide tonight". As it happens, I'll be travelling that day so we decline politely and show him out the door. Afterwards, we realize he seems to have forgotten to leave the written quote. (Surprising, that.) A quick web search reveals some interesting comments from previous customers about the sales tactics employed by this company, the commission structure for its reps and the quality of their products and work. Suffice to say, we aren't regretting our decision to pass on the generous offer we were made that night.
My point is that when interacting with another person face to face (or on the phone), we usually have plenty of indicators we can look at to assess how much we should trust the other person, how risky the situation is, whether things are what they seem. "The other rep was fired", "The phone sales guy will be demoted this time" - yes, I wonder whether he would answer today if we ring and ask for Frankie ("like the fish"), sounding as cheerful and matey as ever.
How does this relate to Citrix? Simple: trust is critical to what we do in supporting remote application delivery and how people perceive that, as customers and users.
Trust me, I'm a software developer. (I've got a compiler and a certificate!)
Trust is an issue in many ways and on many levels - for example, do you trust Citrix to write good products that work as they should and don't pose a risk to your systems? If so, why do you trust Citrix to do this? Is it because of how many customers we have, who we have as customers, what customers and third parties say about our products, or because you tested our products in your own environment? Or maybe you know someone you respect who works at Citrix and that gives you confidence in what we produce?
Already you can see that often there are ways open to you to assess something of the true state of affairs, and so reduce the need to blindly trust us to have written solid products. But it isn't so easy in every situation.
Right now, I'm wrestling with trust issues that relate to how Web Interface works and how users are or should be involved in making decisions affecting security, especially of their own system. Most of the key decisions come down to questions of trust.
The core of the problem is that people have very few indicators they can make sense of when visiting a web site on the Internet, to judge accurately whether that site is what they think it is, and whether they are safe visiting it. The current acute problem with phishing is evidence enough of that.
If that site is Web Interface, one of the first things it does is try to use an ActiveX control - that alone can trigger a warning from the browser these days. If not found, Web Interface will normally provide a link to a program that must be downloaded and installed to use the site. If the user elects to do that, they will be faced with a couple of rather cryptic security questions that talk obliquely about trust, but don't really give the user anything useful to go on:
How is an employee of a business partner remotely accessing your system supposed to make an informed and accurate judgement about these questions? Nothing in either dialog tells the user that the program, if run, will actually try to install something on their computer (unless they know that .msi files are installation packages). The Web Client for Citrix link just takes the user to the Citrix home page; they would have to really dig to find out what the Web Client actually does. The publisher link shows them the detailed digital certificate information - barely useful even if you know how to inspect the certificate fields and interpret them.
The business partner employee is implicitly faced with the question "do you trust Citrix to write good products" but without the benefit of the types of evidence someone purchasing the product would likely have.
Even worse than the browser security dialogs are some that the ICA client itself throws up, usually when the user is in the middle of doing something else. Here is the classic example (this typically appears when browsing My Computer in the Open and Save dialogs of most applications):
I won't go into a critique of this one now - I want to finish this post today!
Can we translate trust judgements about remote systems into judgements about things people instinctively understand?
That is the question I am trying to answer in the context of Web Interface, to improve the way users experience our products and maximize their actual level of security. I'm willing to forego a theoretically stronger security mechanism that in practice would often be undermined or bypassed for an apparently weaker security mechanism if it will be so easy to use and understand that most people would receive its full benefit.
The idea is that instead of allowing security to depend on individual users making judgements about technical risks they often don't even understand let alone have the means to assess, we should find ways to design the technology so that users are only part of the chain of trust decisions when they are in a position to understand what's happening, and have more natural ways of assessing risks - more akin to the face-to-face indicators I had when judging whether the double-glazing salesman was being honest with me, or trying to lure or pressure me into accepting an offer that wasn't really good value (for me).
Certainly that is possible in some cases. For example, employers could give employees who need access from home a CD or USB stick that will configure their home PC to trust the company's Web Interface site without needing them to enter the correct URL or manually reconfigure their PC. The employee is making his primary trust decision on the basis of a person he knows (his employer or an IT person at work) giving him a CD for this particular purpose; he will probably assess intention and competence to some extent without even realizing it. He can also make a secondary trust decision about whether the CD or USB stick could have been tampered with or swapped for a trojan once he received it, because it is a physical object he took home with him and people are fairly good at knowing how to look after small objects. (Or at least better at it than knowing when they have visited a phishing site.)
Of course the software installation process started by using that CD or USB stick needs to allow the individual sufficient control over what is happening, as well as ensuring they are properly informed (in terms they can actually understand) about what is happening to the security settings or posture of their system, why that is desirable or necessary, how the user can change their mind later etc. This is where Citrix needs to do its homework, to make sure we design our products to minimize the chance they could be used maliciously to endanger anyone's systems. (That still doesn't quite answer how any particular individual, who might be a third-party user of a Citrix system, can tell whether they should trust Citrix software to behave this way though.)
There are lots of even more complicated scenarios that get interesting, when you look at the relationships between application provider, application consumer, application data owner, device owner and application + device user. I'll talk more about those actors and their relationships another time.
As I said earlier, trust is critical to how Citrix products work and are used, and there are many varied facets and levels of trust we could talk about. Let me know if I've oversimplified things, or missed something you think is vitally important.
Cheers,
AndrewI
PS. I've deliberately been imprecise in using the word trust, to try and speak to the various 'natural' meanings that different people assume. It turns out there are some quite interesting articles that talk at length about the nature of trust, which make insightful reading. One that I've been reading recently is "Designing Systems That People Will Trust", which is included in Security and Usability.
Hello, my name is Brad Pedersen. I'm the Chief Architect for Citrix, which means I oversee all product architecture at Citrix with a primary focus on the Virtualization Systems Group (VSG). VSG is the original group within Citrix that builds Presentation Server, Password Manager, Project Tarpon, and the Dynamic Desktop Initiative (Project Trinity).
I recently had the opportunity to record a video that provides an overview of Citrix products and technology going back to MULTIUSER. I've been with Citrix for over 16 years, so I have a unique perspective on Citrix history. I hope you find this video interesting.
Inside Citrix:
In this video, Brad Pedersen, Chief Architect and Senior Fellow, shares memories of the early days of Citrix virtualization and thoughts on future directions.
This is a topic I've been itching to start talking about since Citrix opened up the doors to blogging. I can only scratch the surface today, but it's a good moment to start.
For those of you attending Citrix iForum in a couple of days, I want to draw your attention to a demo that you might otherwise easily overlook or not immediately see as significant. In the Tech Lab area on future technology we will be showing how Microsoft's Active Directory Federation Services (ADFS) can be used with Citrix products to enable single sign-on across the enterprise. The demo will illustrate how the user frustration of multiple sign-ons to different apps is replaced with a single strong authentication event that is carried securely into web application sessions and applications running on Presentation Server (with the help of Password Manager if necessary).
Don't be fooled though - single sign-on (SSO) is certainly powerful and useful, but that's not all that's happening here. What you are witnessing is the blurring of web and Windows application boundaries, the breaking down of silos of user identities for application access and control - the ending of the era of "one way for the web, another for Windows" and the start of a new way for all applications to tap into a common rich understanding of identity, context, roles, authorization, and trust.
If you care about identity (and I sincerely hope you all do) go see this demo and more importantly talk to the people giving it. You'll find some smart people there who've been thinking hard about this subject, who are eager to hear about the issues you are wrestling with, share what they know, and talk about what Citrix has done already and the work we are doing to enrich and enlarge our approach to identity.
Let me share a bit of my perspective on this, and why I'm really excited by what we have enabled so far and where we're going with this.
I talked before about the role of Web Interface in the Citrix Access Infrastructure, and said that WI is at the intersection of users, resources and access scenarios. Clearly identity is central to the understanding of users, but I hinted that identity is more than just username and password, richer than just which credentials are needed to access a system.
Web Interface, and Presentation Server, and Access Gateway, and most other products and systems throughout the lifetime of the entire IT industry were brought into the world with the feeble understanding of user identity that starts and ends with a username and password. But we know that doesn't begin to match the reality users live in, and have lived in for years now. We know study after study has shown that workers, not just in large enterprises, often have 10 or more usernames and passwords for different systems. We know that they will try to make them the same, and they hate having to change them, and they can't remember them all without using bits of paper stuck in odd places, or just in plain sight.
Many will even divulge them to strangers for a nice candy, or even just a cheap pen. (Anyone want a Mars bar?)
Heck, I've come across people that leave their work machines running all the time (even when they're on holiday) with the screensaver turned off, just so they don't ever have to type their password.
What's really significant about our ADFS SSO demo is not that it demonstrates SSO, even across web and Windows applications, but that it is not sending passwords around to do it. It is sending signed statements of user identity issued by a trusted party (here a corporate ADFS server) based on whatever level of authentication the trusted party and the user agreed to use (password, smartcard, hardware token, etc). The applications, both web-based ones and Windows ones running on CPS, have been directly or indirectly configured to trust the ADFS server's assertions of identity in lieu of performing their own user authentication.
A monumentally huge tectonic shift just happened so quietly in that last paragraph, you might not have noticed you aren't in Kansas any more. Have a look out the window.
That's right. Web apps don't have to perform their own authentication; with help from Citrix, Windows doesn't have to perform authentication either. Both can work with just user identities, not user credentials. The user identity that is authenticated doesn't have to be the identity asserted or used; the identity asserted in one place doesn't have to be the identity asserted in another. In some cases, it may not even be the user identity that matters - it can be enough that a trusted party vouches for the user being over 18 say, or a member of a certain organization, or entrusted with specific privileges (if only for one transaction).
(By the way, I think it is worthwhile everyone reading a bit about the Shibboleth project to get a feel for some of the scenarios in which that last statement applies. Then think about what situations in your organization might bear some resemblence to those, and reflect on whether those situations cause tensions and conflicts that might go away if you could make use of the richer understanding of identity, attributes, roles, authorization etc that Shibboleth users enjoy and which Microsoft is actively working to bring to wider fruition.)
Even if you are just going to work with user identities and use passwords for authentication, this is still a win - we no longer need to ship your full credentials around everywhere, in case something needs to check you have the right password to confirm your identity. You only need to confirm your identity once, to something you trust, using a protocol that doesn't actually have to disclose your password to do it.
But make no mistake, the approach to identity embodied in standards like ADFS and SAML (what Microsoft calls claims-based identity) really is a tectonic shift from the past - and nowhere more-so than in the model of trust it imposes (more on that another time). To take proper advantage of this new approach, without opening yourself to entirely new risks, you need to get your head around how different this approach is and how it really works.
For those of you going to iForum, I trust you'll get a lot out of it, but whether you are going or not try to spend some time lifting your eyes to see the tidal wave that is starting to come over the horizon. It's going to take years to get here in full force, but it will radically change the way we think about identity, roles, authorization, trust, security and most other aspects of how applications are delivered and managed.
Just trust me on this one. Okay?
Cheers,
AndrewI
I was fascinated by Jeff Muir's account of how the ICA web client came to be written, and also by the timing of when this happened (much earlier than I realized). It brought home to me again the curious arc Web Interface is riding, from the early days of the Web when it was a novelty to be able to run applications from a web browser, to the point we are at now where it is getting increasingly difficult to run ICA applications from a web browser, at least with the technology we have today. Making sure we are in a better place a few years from now concerns me, and makes me wonder if we need a step-change in technology.
We've known for some time that it is getting harder, and that people are running into more and more situations where Web Interface isn't working properly and they can't get access to their applications. It isn't just executives using the kiosks in airports and hotels - though you can imagine how much visibility that gets when a company has just put in a shiny new Citrix system for remote access! It also matters for customers wanting employees to be able to access critical applications from home, or from anywhere they might be stranded in a wide-scale emergency.
The problem is that security concerns have come to the fore, and browsers are increasingly trading off usability and convenience (or rather the apparent convenience you enjoy before your PC stops working for you and opts for a life making money for spammers) for better security. Browsers themselves are including more security mechanisms like the IE Information Bar introduced by Windows XP SP2, pop-up blockers and the like have become de rigueur it seems in almost any product with an Internet focus, and security suites are hooking into almost everything that's happening on your PC to block bad behaviour.
This decline in usability unfortunately goes to the heart of the Citrix value message, that access is provided from any device over any connection anywhere. Web Interface is the primary means we have of delivering on that promise, with the Internet and web browsers taken for granted as the ubiquitous baseline we can assume to exist (almost) everywhere.
So it's a big deal for us that WI is hitting more and more problems that undermine this essential role, and I am pleased to say we are now doing something about it. We can still use your input and guidance though, to help ensure we are focused on the right aspects and make the right tradeoffs.
The approach we are taking is one that has been pioneered already; you can see a good example in action here. In essence, the approach is this: accept that we cannot always accomplish what the user wants, or not always as easily or as well as the user would like. Instead of pretending that we can always launch applications at the click of a button, and treating the small matter of ensuring the user's computer has the necessary client components and security settings as a kind of after-thought, lets make that process an essential part of the user experience.
And if we can't launch applications (for reasons beyond our control), lets be sure tell the user so clearly and promptly, so they don't waste any more time trying. If we can say why, they also may have the chance to get something done about it; maybe convince kiosk owners to pre-install ICA clients for example.
I'm sure this is a topic that will get discussed a lot more, here and elsewhere, so for now I'll just whet your appetite with a screenshot from a prototype we've built recently which gives you a flavour of how we are intending to start following this approach in the near future. 
As I said in my initial post, this forum is an opportunity for you to give feedback directly to the Web Interface team, and there is a good chance that we will be able to act on your feedback and incorporate good ideas, if not in the next release then as soon as we can. So, let us know what matters to you, and where you would like us to concentrate.
Cheers,
AndrewI
Hi, it's me again (Web Interface Guy).
Before I start going on and on with all my ideas about where WI should be heading (just the usual stuff: stopping hunger, imposing world peace, serving fries with every app launched), it will help to be clear about what WI is for; what it's role in life is and should be. As you would expect, I have a fairly strong opinion on this, but I realize mine may be a rather blinkered view, coloured by the aspirations Citrix has and those I have myself - so please tell me if you think I'm being dumb about this.
Actually, it will help even more if I am clear about what Web Interface is first. (Thought you knew did you? Ah-ha!)
As far as I am concerned, WI comprises about a dozen things - in other words, this is what the WI engineering team actually builds and maintains:
- the normal WI web app (ASP.NET and JSP flavours)
- PNAgent Services (same two flavours)
- WI web parts and other bits for SharePoint
- WI portlets for Java-based portals (like WebSphere, SAP, etc)
- WI configuration manager (aka the central config service)
- WI extension to the AMC (our admin tool)
- WI installer and site manager tool (2nd stage installer)
- WI core resource access library
- WI SDK documentation
- CPS XML services (NFuse, Admin, Config, STA, RADE)
In fact, about the only component we don't build that logically should perhaps be treated as part of WI is the PNAgent client itself - it is essentially the non-browser UI version of WI.
I mention this list, because I want to use the term 'Web Interface' as a shorthand for all of it, not just the first item which is what everyone else thinks of as WI. (BTW, I have tried to come up with a good term for this "WI in the large" notion but somehow all my acronyms seem a bit lame - WIITL anyone?)
So anyway, back to my point: what is the role of 'Web Interface', in this larger sense?
I think the answer is quite simple: WI's job is to provide users access to their resources. The emphasis is on the word provide, for which I have a quite specific meaning in mind.
First let me digress a bit: Citrix started using the term Access Infrastructure a couple of years ago to try and explain the value our products offer, both individually and collectively. That got me thinking, and I came up with this simple way to categorize our products and components as performing one or more of the following basic functions:
- Provide access to resources
- Deliver resources or access to resources
- Enhance the delivery of resources
- Control resource access and delivery
- Manage (ie. measure or monitor) resource access and delivery
The ICA piece of Presentation Server of course delivers applications remotely, and enhances the delivery in many ways that I won't tire you with now. Our SSL VPN products deliver remote network connectivity or access to specific resources (internal web sites, files, etc) and our NetScaler products enhance the delivery of web applications by providing security, compression, load balancing and so on. Our latest product, WanScaler, does a similar job enhancing network connectivity to branch offices.
Presentation Server, Access Gateway Advanced Edition and NetScaler all support rich policies for controlling their respective resource access or delivery mechanisms, and we are already part way down the path of converging and combining these policy controls to work collectively.
The EdgeSight product line is focused squarely on the final function, of measuring and monitoring all of the above. The Resource Manager, Report Center, and Dashboard components serve the same function for CPS specifically.
(Okay, you get the idea - there is a cogent strategy in action here.)
For me, the point is that WI is concerned only with the first function, and merely plays a supporting role to the products and components addressing the other functions. This may seem a trite point, but actually it helps people in Citrix (me in particular!) to understand which of the many enhancement requests or neat suggestions we get for WI are sensible, and whether and how we should go about extending WI to support new features and capabilities in our products.
Right then, here is my definition of what it means for WI to provide users access to resources. It is WI's job to
- Be aware of the existence, location and nature of resources
- Be aware of how resources can be accessed or used
- Be aware of users and access scenarios
- Make the existence of resources and possible actions known and available to users
- Arrange or orchestrate access to resources (or initiate actions) when requested
I like this definition for lots of reasons, but I'll highlight only a couple right now.
#1 and most significant, WI is at the intersection of users, scenarios and resources.
WI (usually) needs to know who the user is, but that can be a much richer concept than the traditional view of simply a user name or id - users can have multiple accounts or identities, and may take on different roles in their work at different times. WI is a good place to help map between these identities and account for the richness that actually exists. Authentication of course is important and needs to be flexible - but WI doesn't necessarily have to perform authentication itself.
WI then needs to take account of the scenario - 'where' is the user, how are they using the system, what are they trying to do, what are they expecting to happen? In the WI team, we spend a lot of time thinking about this aspect - as I noted in my first post, for many users WI is the face of Citrix and although they may not be able to express very well what they want, they can certainly tell when it didn't happen!
WI needs to understand the resources; what are they, what are they for, what can you do with them, how do they work? Note that this is more than just knowing how you "get" to the resource - different types of resources may be accessed with the same physical means (eg. ICA connections to published apps or virtual desktops), and the same resource might be accessed in quite different ways depending on the type of user interface. For example, someone seeing a Word document link in SharePoint may expect Word to run when they click the link; the same person seeing the same resource listed on their BlackBerry might want a summary of the document emailed to them.
Finally we get the juxtaposition of these three aspects: WI has to figure out what can this user meaningfully do with this resource in thisscenario? And how can that be made to happen?
#2, WI is an orchestrator and must therefore deal with all the complexities and idiosyncracies that come with the territory. WI offers the user "X", the user says "do X", WI must make X happen!
In practice, for the resources WI understands today, that involves detecting the access client / device capabilities, downloading and installing appropriate client components if necessary (or giving instructions on how to do this manually), providing 'directions' (translating addresses as necessary based on the user's location relative to the resource, putting the right settings in launch.ica), obtaining security tickets and access tokens where needed, etc.
I think of WI as aiming to be a bit like the perfect travel agent; the user outlines what they want, the travel agent makes some assumptions and deductions, books everything, then hands over a tidy package with the itinery, tickets, foreign currency, emergency helpline numbers, sick bag, etc all neatly layed out. (But they don't actually go on holiday with you.)
Well, that's the aim anyway!
Cheers,
AndrewI
Hi folks, to the Citrix Architects blog. If you have come here looking to read things our product architects have to say, presumably about Citrix products mostly, probably about what we are working on or thinking about doing as we evolve and expand those products, you come to the right place. If you come to give us your opinions on those things, and what you think we should be doing instead or just better, you definitely come to the right place. We want to hear more from you!
Of course we don know exactly how this forum will turn out, but the plan is for individual product architects like myself to post here occasionally on topics of our choice. The first one will be along in just a moment.
So on behalf of the product architects at Citrix (at least this once), welcome, and without further ado let the conversations begin!
Cheers,
AndrewI
-
May 2008 Sun Mon Tue Wed Thu Fri Sat 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1617 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Search
-
Subscriptions
-
Group Blogs
Top Bloggers
-
Popular Tags
Most Viewed Posts
