Business Data and Personal Data (pot-A-to, pot-AH-to?)
Posted by BPuhl on February 21, 2009
How do you tell the difference between “business data” and “personal data”? Since we’ve been diving head first into this whole federated identity thing, it’s turning out to be pretty darn important.
The best that I can come up with at this point, is the following guideline:
If you’re supposed to have access to a piece of information after you quit or are fired, then it’s personal
Man, I wish life were only that simple. Here are a couple of examples of decisions from real life ADFS federations that we’ve set up between Microsoft and some of our business partners.
Microsoft employees in the US (and elsewhere) are provided medical and other types of insurance as part of their benefits package. The HR team wants to leverage a vendor to manage most of the benefits, and provide SSO for employee’s.
Is this business or personal data?
By my definition above, this is pretty obviously business data. Ah, however midway through the project, there was another requirement thrown out. (I’m obviously stereotyping here, but for fun…) It seems that a large number of Microsoft employees are married men, and some large percentage don’t want to manage anything remotely having to do with their family or finances, most likely because their wives won’t allow them to. So during this project, we now need to allow an employee to provide access to the benefits portal for their spouse.
The solution? Employee uses ADFS to sign into the portal, and then they can specify WLID’s that are allowed to log in and manage them as well.
Not bad, but the implementation went sideways. What we’ve got now, is a case where users who are logging in from corpnet have to use ADFS, however ALL USERS that log in from the internet use WLID’s.
Operationally, this is really bad, because the only way you can tell from the internet, where a user is coming from, is by IP address – so if we add a new proxy server IP, we will have transient auth failures.
From an IDM standpoint, the goal was that when a user was terminated, they lost access to the site. They only have access because of their relationship with Microsoft (ie. it’s business data), and they lose access to it when they are terminated. However instead of enforcing this with auth, we now have to rely on the HR, out-of-band, feed to notify the vendor of an employee termination.
Another example, occurred this past January:
In December, Microsoft and our payroll vendor federated an application such that MS employees in the US could gain access to their W-2’s (US tax documents) online, by signing into the application using ADFS.
It’s easy to interpret a W-2 as being business data, after all, it’s essentially a summary of your annual payroll, but it was this case that helped by boil me definition down to what I wrote above.
You see, in December we sent out this e-mail, we had a significant number of employees sign up for online W-2’s, which as part of the process they agreed not to need paper W-2’s to be mailed to them. They would just print them out.
However in January of this year, Microsoft was one of several companies that unfortunately had to cut costs and lay people off. Part of this process, was that the impacted users had their accounts disabled.
So to summarize the insult to injury:
- A user signs up for online W-2’s
- They are layed off
– And the account they need to use to access their W-2’s is disabled
This is a pretty clear case where we should have used some form of public auth provider like Windows Live ID or similar – essentially allowing users to get their W-2’s using their personal ID instead of tying the access to their business ID.
However you have to stop and ask yourself: “If an employee accessing their W-2 is really a person accessing personal information, then what is an HR analyst that’s providing support, who has to access MY w-2 to give me the help I need? Surely we could all agree, that this is a case of a business identity accessing business information!”