Those of you who work in and around federation should take note of Brian Puhl. Brian has been speaking and blogging about his deployment experiences with ADFS as part of Microsoft’s ‘dogfooding’ program, and he has some hard-won opinions on the subject. I commented on a blog entry of his regarding who can create federations in ADFS. Part of his reply was this story:

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.

When I read this, I felt like jumping up and down like the goody-two-shoes in the second row, me me me me oh I know the answer pick me!!!

If they were to use an Information Card for the active confirmation prior to a user making changes, users wouldn’t need to remember a password at all. You would get the impediment of requiring credentials, without the support burden attached to maintenance of a rarely-used password. Alternatively, if you felt the need to have a password, you could require a managed information card. In that case, the user would be authenticating to the home IdP instead of to the outside application, taking the password management burden off of your partner and consolidating password use to a single centralized source that would theoretically be much more commonly used, and therefore less likely to require frequent recovery. Not to mention that the Enterprise could audit use of the managed infocard in this context.

This seems to me to be a perfect scenario to envision a hybrid passive/active federation combination instead of passive federation for 85% of user activity, and partner-managed password authentication for the remaining 15%. Yes? If so, it just goes to show that the scenarios are out there, and for more than just the eBusiness world.

Brian, what do you think?