Comment on ADFS Liability
My favorite Calgary-ian Pam left the following comment on my last blog post:
Hm. In a perfect world, there would need to be a contractual component to any and all technical federations, and those contractual components should go through review by the privacy officer, and also by the admin team.
Companies and admin groups need to get religion over the process involved with creation of federations, if for no other reason than to protect themselves from liability.
Here is more about liability and federation: http://www.rsasecurity.com/go/siliconcom/liability.asp
Cheers,
Pam
I am SOOOO glad she did too, because liability is one of the hardest problems to deal with when deploying ADFS, and something that I've personally been harping about to our internal deployment team as we develop our onboarding process for new federations. In fact, one of the topics that I've been presenting at various TechEd's and the upcoming ITForum lately, is "How Microsoft IT Deployed Active Directory Federation Services". In that talk, I've dedicated an entire slide, to just some of the impacts that liability can have, whether your providing the user authentication or the resources. In fact, one of the comments that I make during my talk, is:
I've been involved with Microsoft's Active Directory for 5 years, and never had any reason. But I was tasked with deploying AD Federation Services, and within a week of the project starting up, I had met with some attorneys in our Legal and Corporate Affairs group.
A great example of technology vs. liability is the ongoing discussion that we're having with one of our business partners, about providing federated access to their internet portal. This partner though, happens to be one of the providers of financial services to Microsoft employee's. From the partners perspective, the idea of federation is wonderful...they see it increasing their security, reducing their risk (since they still allow SSN's as user names), and reducing the amount of overhead they have for constantly resetting users passwords. In fact, one of their architects commented that there were nearly as many users who require a password reset EVERY TIME a user attempted a login, as there were who didn't.
Enter the Microsoft attorneys...
They looked at the technology, and got a pretty quick understanding of the risks, limitations, and potential uses for ADFS. They just as quickly built the following scenario
So Joe User's password gets compromised. Not only can someone use it to gain access to some set of corporate resources, but now they can also go in and mess around with his retirement portfolio? And they would do this, because during the logon attempt, "Microsoft" verified that the user was actually Joe? Ummmm....No.
This is basically the story of how Microsoft has ended up asking some of their higher impact business partners, to create a 2-tiered authentication model. In this case, a user can log in using ADFS authentication to view their information...but as soon as they want to make a change to their information, they'll need to enter their application specific credentials.
According to the partner, approximately 85% of all logons are just to view the data anyways, so it's still a win...but it also virtually guarantee's that when a user does want to make a trade, they'll need to reset the password because now they DEFINITELY are not going to remember what it is.
So what does all this mean - it means that I agree 100% with Pam's comment, that IT people are going to have to get religion over the process of creating federations, and the impact that it has to their business.