The following is a terse explanation of how it works:
ESSO tools serve as a proxy between client devices and target systems. Target systems still maintain independent credential stores and will present their own unique, sign-on prompts to users' client devices. ESSO tools provide various mechanisms to sense sign-on, password and password change prompts for different target systems. Automated sign-on logic can fail when sign-on or password update prompts change with new releases of target applications or operating systems (OSs).Two-tiered architectures will require schema modifications in AD (or whichever repository is being utilized), although it gets to leverage the benefits of your directory services infrastructure, like redundancy, fault-tolerance and performance. N-tiered approaches require a separate set of ESSO boxes (midtier architectural components) - i.e. more stuff to maintain, and vendors in this world tend to battle on how many concurrent users their boxes could handle (Don't confuse the number of users on a box, with the number of concurrent connections the box could handle. Sales folk love to muddle those two). On the other, this approach may prove useful if your directory infrastructure leaves something to be desired, or if your data is dispersed in more than one repository. In that case, a synchronization strategy is pretty typical from the various data repositories to the internal ESSO repository. Although I have yet to see it, I would love to see an ESSO/Virtual Directory model here. On paper, this seems like an elegant solution, allowing (for example) physician data to remain in eDirectory, employee data in AD, and the ESSO solution pointing to the Virtual Directory that intelligently routes requests based on user type. At least this would not mangle things with a metadirectory, though I'm not about to get into the whole 'metadirectory is dead/almost dead' debate.
Instead of going into depth on every ESSO feature, I've decided to put together a list of technical areas that are important differentiators. Each vendor may have a different approach in dealing with the situations described below. Anyhow, these questions are a good place to start:
* What directories does the ESSO solution support - in terms of storing ESSO data?
* How are username changes managed? For example, someone changes their last name, and their username changes...how does the ESSO system manage that?
* Every healthcare institution has a pretty involved Citrix environment. How will it deal with physicians accessing applications externally through a portal? Will it still provide the appropriate ESSO experience? Does the solution support authentication by generic accounts using virtual channel?
* Most healthcare institutions have areas with shared workstations, in which generic accounts are used for authentication. How does the ESSO solution deal with that? What about multiple session private desktops?
* How does the vendor support remote users (i.e. users connecting via VPN)? How does it support for a user connecting via VPN from a non-domain controlled PC?
* Does the solution support fast user switching?
* How easy is it to integrate new applications? Is the point and click wizard really that easy to use? (In a POC, make sure your techies get hands-on. An expert can make it look easy, so don't be fooled.)
On another note, if you are looking for a detailed analysis of the vendor offerings, at over 400 pages - the KLAS report on ESSO and Context Management is quite a comprehensive paper (Sorry, I can't seem to find the link right now), and definitely better than Gartner's magic quadrant report from a vendor analysis perspective.
Up next...a bit on Context Management.
No comments:
Post a Comment