Adventures of an Eternal Optimist

As most of you know, I’m pretty excited about InfoCard. I’ve been playing with it for a while now, and I think I need to mention a few of the things I’ve noticed. I’m very aware that I’m working with a CTP – and I understand that there is a finite group of people that can only do a finite amount of work before Vista goes live. I hope I’m mentioning things you already know about and are planning for, Stuart! I don’t believe that these points can be considered nitpicking – they are pretty important, in my opinion.

I expect to be posting more of these entries as I get time, so stay tuned.

1. Export Prevention

As of the Jan 2006 CTP, there is no way to prevent a person with access to your account from exporting your InfoCards. If I walked into an office where the person had not logged off or locked their screen, I could have their entire card set saved to a file on the network or to a USB key in under 60 seconds, without ever being challenged. In fact, instead of being challenged for a password, the attacker is asked to set one! This password is needed in order for the infocards to be imported elsewhere, but it doesn’t protect the user from an attacker who sets it in the first place.

One more scenario to drive the importance of this issue home – there is nothing a parent can do to prevent their child from listening to the instructions of the nice man in the chat room, who tells them how to export infocards belonging to the whole family, and email them off (this of course assumes that the family shares an account – if the child has their own account, then the question of how to control what cards are placed in that account arises). If the cards are pin-locked, they are tougher to get into – however, the attacker can take as long as they want to try and crack the pin.

Keep in mind – I can only assert this regarding self-issued infocards. I don’t have a managed infocard to test with, but my understanding is that a lot of the built-in security that Infocard developers have spent a ton of time on kicks in when you start dealing with managed infocards. With a managed card the data is no longer part of the export, and a new trust relationship has to be established between the Identity Selector and the Identity Provider in order to view managed infocard attributes. This gives you the time to cancel your card, and it gives the Identity Provider the chance to notice that all of a sudden your infocard is being viewed/used from an unknown IP address. Still, if the Identity Provider is not sophisticated enough to notice, you might be up the creek — infocard exports are not even logged under Site Usage, so if somebody does export your cards and walk away, you won’t even know it.

2. Deletion Prevention

Along the same vein – a user cannot guard against accidental or malicious deletion of infocards. In the case of self-issued cards, it isn’t tough to re-create – after all, there are no more than 14 fields to type in. Deletion of managed infocards could be much more of a pain, depending on the process involved for re-provisioning. As well, upon deletion all of the usage records are lost, and Deletion events are also not logged as part of site usage.

Thoughts/Suggestions

From a sys-admin point of view, the obvious eventual goal would be to be able to set group policy around infocards. Until then, if a network login was forced at the time the export/deletion took place, it would at least prevent malicious attacks on unattended workstations. In the case of a shared family account, I have fewer ideas.

This all boils down to control. Visibility and control are keystones of Infocard – and as such, I think that the user or sysadmin has to (a) be able to see events such as exports in the log files, and (b) be able to place X credentials and ONLY X credentials on a managed desktop or account, and to prevent those credentials from being removed or copied. I do realize that you could call that second point a loss of control from the point-of-view of the user with the managed desktop — but the truth is, such relationships exist, and for good reason. The tool has to handle such demands.

So? Am I crazy? Is this not really such a big deal after all? Let me know what y’all think…

This is good stuff:

PDF:Identity Metasystem Design Rationale

There is a lot of info packed into these 11 pages – it is densely formatted, and there are no flowery sentiments. Terse is good. I like terse. I’d have to say that this paper represents pretty well everything I’ve ever heard Kim, John, Andy, Bill, or Mike say about the metasystem… so I guess that makes them terse and consistent :-)

Hi folks,

If you are crazy enough to try and check out InfoCards at this early date, you are probably looking at one of two sources:

1) the Sept 2005 Federated Identity & Access Resource Kit

2) Sample Code on : MSDN

Turns out that neither of these places will actually get you easily running code. The changes needed to get the MSDN samples running are smaller, but they require the fix I’ve described below, and they don’t use runtime bindings (compared to the res kit, which does). There are also a bunch of small fixes regarding casting and iterating through claims in a claimset. The res kit requires both fixes listed below, and a few other things.

I expect that very soon, a nice new shiny set of examples and sample code will come out – maybe even for the Feb 2006 CTP. Until then, however, drop me a comment here if you want working sample code, or an edited version of the Programmer’s guide if you are like me, and want to code the thing from scratch.

If you don’t feel like waiting for me to get back to you – here are a few hints to make life easier:

Modify any instance of “configurationName” in your app.config file to be “name”

If you are getting the following error:

The binding to use to communicate to the federation service at ‘http://schemas.microsoft.com/ws/2005/05/identity/issuer/self’ is not specified. If you are using Infocard please configure an Infocard client credentials for the channel proxy.

It probably means that you need to change a line like this:

ClientCredentials credentials = new ClientCredentials();

Into a line like this:

InfoCardClientCredentials credentials = new InfoCardClientCredentials();

Isn’t it amazing how something so small can cause so much pain?

This will save you a LOT of time. I promise…