Wouldn't it be cool if there was a blog where someone was posting documentation about ADFS?

Well looky here - apparently this has been around for a while, but since I just recently discovered it I thought I'd share...

http://blogs.technet.com/adfs_documentation/

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?

It's time to start over with this whole blogging thing.  But it was important (to me at least) to figure out why this one died such a horrible death when it had so much potential.  And I realized, that it's because of the darn namespace - "blogs.technet.com"...sort of puts a damper on this things when I'm just interested in ranting or raving or talking about my daughters, and that cascaded into me not really being interested in throwing the cool AD/ADFS/Identity stuff up here when I could.

So I've started over, with my own blog:  http://imav8n.wordpress.com

I know that most of the people subscribed here only want the AD stuff.  That's nice.  I'll do my best to categorize my posts, and we'll see how it goes from there.

 ~B