Passive/Active Hybrids for Enterprises

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?

Advertisements

~ by Pamela on 1 Oct 06.

3 Responses to “Passive/Active Hybrids for Enterprises”

  1. There are other interesting scenarios that also come up like whether SSO into your 401k also means you can view/change 401k that you have for alternate employers.

  2. […] ADFS and Liability Continued… hmm…let’s see…I wrote a blog, Pam left a comment, I replied to her comment with another blog, and so (if you haven’t seen it yet) Pam posted her own blog entry here…  This is actually kind of fun! You should read (all of) her posts anyways, but to save some screen flipping here’s the meat of it: …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? So…let’s see…What do I think?  I don’t think the problem is in the way that the credentials are stored.  Let’s suppose it’s an InfoCard from some Identity Provider, then the liability would then fall on that Identity Provider if/when a users account gets compromised.  Why would someone sign up for that?  In the case that we’re dealing with internally, Microsoft is the Identity Provider, and our lawyers don’t want to sign up for the risk – why would anyone else? Thinking about this slightly differently – Our lawyers have the problem, because if someone hijacks my corporate user account, and goes into my 401k and wipes out my retirement savings – who is ultimately responsible?  If Microsoft did the authentication, Microsoft is, if the partner did it, they are, and if some 3rd party identity provider did the authentication – then THEY are responsible (would we even consider a 3rd party – umm…let’s hope not) So let’s say we use an infocard.  And not only that, but we use a Managed infocard.  Ok, so now I’ve got a managed card on my machine – So when someone hacks my account, selects the highlighted infocard, and THEN wipes out my 401k… Now who’s responsible? I can absolutely see where an InfoCard can help the end user – but I’m the IT Geek who’s trying to deploy the infrastructure.  How do I sell being an Identity Provider to my CIO?   Published Monday, October 02, 2006 10:41 PM by bpuhl Filed under: Random babblings and such…, ADFS […]

  3. […] I replied to her comment with another blog, and so (if you haven’t seen it yet) Pam posted her own blog entry here…  This is actually kind of […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: