Photo Credit: CarbonNYC (http://www.flickr.com/photos/carbonnyc/76468122/)
Enterprise use of information cards have been a topic of great thought for me leading up to my talk at the Directory Experts Conference in Chicago this month and culminating in a panel at last week’s Novell BrainShare conference, in which Patrick Harding, Kim Cameron, Dale Olds and myself talked to the lovely Carolyn Ford on this very subject.
At DEC, the predominant opinion given to me by the experienced & capable Enterprise administrators present were as follows:
“We don’t want users to be interrupted at all — so why would we ever want or need information cards?”
If in the Enterprise you are responsible for, your users do not need to make a single context decision, if you the Administrator and your stored data can do it all in every situation — fantastic. My experience has been that many Enterprises find that the profile data they are able to serve from an Enterprise Directory or even a Meta-Directory cannot always suffice, and that measures have to be taken that deviate from the Zen of a single network profile in order to achieve business objectives. I’d like to put a few situations in front of you that I believe demonstrate common cases where undesirable measures are taken in order to get around an IT assumption that user context decisions are never necessary.
Situation #1: Do you ever have to assign two different accounts for the same application to the same user?
The only reason why a user might be issued two accounts for the same resource is because there is something critical but different about each account – and guess who chooses which account is appropriate – the user. The Enterprise cannot do the thinking for the user in this case – in fact, the Enterprise may not even know that both accounts belong to the same worker.
There are many many reasons why an Enterprise might feel forced to issue multiple accounts to a single user — it could be due to a need to completely separate conflicting roles. It could be due to a need for a certain privilege to only be available to a user under specific, acknowledged (and audited) circumstances.
Situation #2: Do your users ever have to logon to a separate network domain just to get to a specific application?
I see this at client sites every so often, often in cases where mergers and acquisitions have resulted in a fragmented Windows network. Users are forced to internally access a VPN in order to create a separate network session in order to get to a single application in an untrusted/unconnected domain still within the overall company perimeter. Maybe there is a better way to do this without Information Cards, I dunno – but it seems to me that cases like this where users have no choice but to exit their soft comfy SSO/Kerberos world using nasty clunky VPN software, using an Information Card might be a cheaper, nicer, more user friendly option.
Situation #3: Did you ever want to impress upon your workforce a sense of the solemnity of a given decision?
Currently, most workflows for approval of provisioning or service requests are implemented by a simple HTML button — “yes” I approve or “no” I reject. What if what you need in your Enterprise is something more along the lines of “I, Pamela Dingle, acting in my capacity as Manager of Business Unit X, approve this message”?
Situation #4: How many smart cards are hanging from your users’ belt-loops?
If your user is required to select the right smart card for the job, they are making context decisions – and in fact, I’d argue that you’ve already bought into the card metaphor :). In this case, chances are that the hardware solution would trump any kind of information card solution — for now. In the future, as information cards become more integrated with physical devices, the line may get awfully blurry…
Perhaps situations like the ones I’ve described above might influence you to take a closer look at information cards. Perhaps, there still isn’t enough to convince you yet. That’s ok – there is a lot more to come, this is just a small piece. I’d love to know what people’s experiences are in general around the concept of the need for user context decisions in the Enterprise – are such decisions as diametrically opposed to common SSO/IWA administrative philosophies out there now as I imply here?
Situations #1 and #4 are theoretically resolved using a role based access control approach. This leads me to the following two questions:
1. Does role equal context ?
2. Do (virtual) cards become a convenient means for activating one’s role ?
Theoretically resolved – yes. Resolved in practice – not always. I have been in Enterprises with role-based access control in place who still choose to assign multiple user accounts on the same app to the same user. These fringe cases are the ones I’m referring to.
Absolutely, a role is context – I would call roles “system readable” context, to steal a term. Most Identity projects involve turning non-system-readable business processes into system readable rules and policies. Most roles would never need a card, and certainly it would be a user interface nightmare to activate every role, but in the case where adoption of a role represents an event the Enterprise wants to acknowledge, or where the system cannot judge which of two conflicting roles should be adopted, yes I definitely think that cards are useful.
thanks for the comments!