Unsolicited opinions on Identity, Privacy, Geekery and life in general.
Patrick Petit discusses Information Card support in OpenSSO – note that for those of you wondering about Information Card projects using Java, the OpenSSO project is a prime example.
I wrote not long ago about the HSBC Canada banking site, and its odd and frightening ways of dealing with access control. Their fanciful notions of authentication proved to me that passwords were being stored in a retrievable format rather than in a format where the password can be verified as matching but not retrieved and examined.
This exact same issue has come up on the OSIS list with respect to privatepersonalidentifiers – some have argued that it is perfectly safe to store raw ppid and modulus information at the RP, and I cannot tell you how STRONGLY I disagree with that idea.
Luckily, Gunnar has pointed me to the perfect example: apparently the HSBC France banking site has been hacked, and guess what? They are storing their customer’s passwords in clear text too (surprise surprise). And a handy little SQL injection attack gives the hacker everything he needs to log in as anyone he can think to query for.
Had the HSBC stored their passwords in some kind of encrypted format, the same attack would have netted the hacker a fraction of the value, because there would still be a significant and likely cost-ineffective amount of time and work necessary to turn the data into a set of credentials that could be used for actual authentication. This is why encryption of passwords is an industry best practice, and why you will and should be laughed out of this community if you can’t get such a simple mitigation right.
If an RP stores the ppid and modulus of a self-issued information card in clear text, and that RP becomes the victim of a SQL injection attack, a hacker has everything they need to get in the front door too. The data must be stored in a way that mitigates this danger, period. I consider this to be identity 101 for information cards, and anyone who writes an RP should consider this to be a best practice.
We’ve been having a great discussion on the OSIS-general mailing list, and I wanted to save a bookmark to the thread so that I could come back later.
The thread discusses what exactly an RP should use to uniquely identify a card from a managed card provider. The current methodology that I’ve been using with the PamelaProject RP’s was to take the isuer certificate signerkeymodulus provided in the SAML 1.1 token and the PPID and hash it together to get a card hash that is pretty tough to replicate without the original inputs.
The problem started when I encountered a managed card that did not explicitly provide a signerkeymodulus in the token. It turns out that I could still extract the value, but the point was made that by using the signerkeymodulus of a managed card, I guaranteed that on issuer certificate rotation, the card identifier would become invalid, and the user would have to reassociate their card. Obviously, this is not an optimal solution.
The solution that was recommended was to generate an identifier for the issuer using the same algorithm IdPs use in section 7.6.1 of the IMI specification, so I will give that a try right away. I would say that this is the closest thing to a best practice out there for Relying Parties, and I would recommend that any other RP writers out there that they review whatever policy they are using; if they are depending on signerkeymodulus, there is at least one IdP out there who does not supply the signerkeymodulus as a separate element in the token, so you’ll be having interoperability issues. If you are storing the PPID directly, I’d also like to strongly discourage you from doing so, I would consider it just as much of a no-no as if you were storing clear-text passwords.
The thread is worth reading, if you get excited about such things ;) You can also subscribe to the osis-general list here.
Somehow, I was thinking of Windows 7 as being far far away, but apparently it could be here in as little as six months. Now that details of what will ship under which SKU are starting to come out, I am dying to try and get the skinny from the Federated Identity team on whether Windows 7 users will get the old CardSpace bundled with .NET 3.5 sp1, or whether they will in fact get a bright shiny new CardSpace Geneva Selector!
Kim? Mike? Don? Can you give us the scoop?
As an aside, I hear that both fax services and full-image backup will be included in Windows 7 home edition — thank HEAVENS. Whatever dim bulb removed those features from most/all of the the many and oh-so-confusing array of home versions in Vista caused me a WORLD of grief, in my capacity as reluctant amateur PC support for my family & friends.
Photo attribution: http://www.flickr.com/photos/marioraffin
I’ve finally had a chance to use Parity’s Azigo Identity Selector, and I have to say I’m impressed.
Pretty huh?
Azigo’s biggest differentiating factor is the fact that cards are stored in the cloud — Azigo uses an Adobe AIR front-end to talk to your cloud-based cardstore and submit your cards. Of course it doesn’t look any different to the user, until the user installs azigo on a second computer, and discovers that their cards are ready to go, no importing required.
Here’s what I loved about Azigo:
Issues I found with Azigo:
Things I wonder about Azigo
Overall, I have to say that this selector greatly exceeded my expectations. Not only is the product really polished, but the people behind the product have been really responsive, making sure to address all of the issues I brought up to them. Azigo has really made good on the promise of information cards here. For those who don’t follow this area closely, I suggest keeping your eyes on the parent company, Parity. Parity has always been a leader with respect to mindshare in the area of information cards, but now their products are showing that they are not just up in the ivory tower. They mean business, and they are going to raise the stakes.
Andy has a claims quandary – check out his blog post to see it: http://xditao.blogspot.com/2009/01/claim-game.html.
To paraphrase, the question is how could a Library model a set of roles that a user might possess, and ask for possession of those roles in a way that doesn’t inconvenience the user by forcing them to undergo multiple card transactions?
Here is my proposed solution, and I just made this up so feel free to call me an idiot if deserved:
Here’s what I like about this scheme:
What do you think Andy? Could it work?
I love working with smart people. I went into the ICF schemas working group call with my set of gobbled-together proposals, and everybody seized on it and started breaking those ideas down into their separate pieces, using language with far more structure than my own words.
There were some excellent points made:
I will keep you up to date with the conversation, which is expected to continue on the working group mailing list this week. The mailing group is: http://groups.google.ca/group/icf-wg-schemas, I believe anyone can read, but you have to be an ICF member to participate. If you are keen to participate, let me know.
During IIW, the ICF Schema Working Group proposed and approved its first standardized claim definition. I’ve been following the workings of the schema group but not closely, and I was taken by surprise at the values defined as part of this precedent-setting claim element:
Claim Name: age-18-or-over
Proposed Values:
What? Want to know what the values MEAN? Sorry, you’ll have to look that up. What you see above is what a Mother or Father will see when they view values passed between the Identity Provider they are trusting to make claims about their children’s age, and a website that may restrict content based on that value.
Do you see the problem? Why on earth even have a selector if the standard claims we propose are not understandable by end users? Why use a meaningless number? To make it easier for the machines? For the developers? That’s crazy! Why don’t we make it easier for the people that are making selector-level security decisions on a daily basis? These schema types have to be created so that whenever possible, the data passed is legible to those attempting to understand the context of identity data flowing around them. Heck, if we created a vocabulary for content that could be distinctly identified and parsed by Selectors, we could even localize.
It’s taken me since IIW to really get my head around this – but I believe we need to set some very specific best practices around these schema elements, first and foremost being the primary design principle that these atomic elements should be designed for regular people, not for developers, and not for machines.
I’m going to do my best to argue this point today on the ICF working group call. If you think this is important, whatever your stance on the issue might be, I urge you to join the Information Card Foundation and to make your voice heard. Contact me if you aren’t sure what you need in order to join, I will put you in touch with the right people.
I think that best practices around claims schema is THE MOST IMPORTANT thing happening right now. It is worth taking the time to get this right. We’ll only get one shot at it.
The public version of the claim catalog is here: https://informationcard.net/wiki/index.php/Claim_Catalog
There are two interesting new selector features to play with in the CardSpace Geneva beta. The first is the idea of the card tile, where (as I understand it, no guarantees of accuracy here) the browser interacts with the selector to discover, cache, and display the image of the last card you have used at a given RP as part of the context of the Relying Party page (rather than as a separate context). The Relying Party never sees or can access the image of your card. This mashup-like user interface is meant to be personalized and more inviting to users.
The second new feature is the “always use this card at this site” checkbox. If you check this box while authenticating with a card, you will subsequently see your card tile, but after clicking that card tile, the rest of the process happens without further interaction. Web site operators can veto this convenience if they wish, by adding a new parameter called ‘requireUserInteraction’ to the information card trigger object and setting the value to true.
I think the always use feature really works well in combination with card tiles, as the user retains context without having to push more buttons. I don’t know how to non-destructively change my mind about always using a given card at a particular site though. I tried restarting the browser, restarting the machine, and clearing “private” data from the browser without effect. I tried going to the control panel and opening CardSpace directly, but nothing there helps. Short of deleting & reinstalling the card, one click of that checkbox and I become permanently committed to a silent transaction with the Federated Identity demo website forever more. I’m sure this lack of choice is temporary (after all this is a beta) – but if possible, I would love to see more on the CardSpace blog about the planned persistence model for this feature, and about what the plans are for letting people manipulate it or even disable it.
When I first heard of card tile feature, I hated it. Now that I see it in use, I understand the value proposition, but I still have to point out that this little picture represents a critical piece of user context information. I can’t help but think that to allow the card tile image to be manipulated by the browser is to eventually serve it to the bad guys on a platter. I hope I’ll be proven wrong.
Other thoughts:
Check out the blog entry from the CardSpace Team: http://blogs.msdn.com/card/archive/2008/11/18/the-cardspace-geneva-selection-experience.aspx Mike Jones also blogged on this: http://self-issued.info/?p=94
Those of us in OSIS have half-joked about the I4 Interop event being the end of the beginning — but yesterday, the announcement of Geneva ushered in a new beginning. It is still a long road ahead, but mark my words, the momentum changes here.
I was recently asked in a rather public forum whether people are really using Information Cards. The answer was a reluctant no. There are a few pools of use that are extraordinary, the largest being in Europe. There are many very interested parties. There is development happening all over, but not released yet. I am ok with this however, because the truth is, this technology will break out when it is not just cool, but also the obvious choice for the job.
In the past, this technology has been evangelized as the end of passwords, which is, in my mind, a mischaracterization. It is not the end of the password. It is the end of the login form. It is the end of that uncertain little piece of html out there that may or may not be well written, or well protected, and may not actually even be the place you trust. That may sound like a small little piece of the pie – but when you combine that little piece with the power of the underlying protocols, and the massive usability problem that confronts us now in the security space, what we get is a lot closer to the complete picture.
Why is this complete picture necessary? Ah, well this is the thing, isn’t it? People keep asking me, why would we ever NEED information cards? We’re already busy, we don’t want to add something we have to work hard to understand to our Enterprises or to our products, and we’re getting by JUST FINE thank you very much…
Microsoft answered that question yesterday too, with Azure. As I’ve said before, your provisioning problems can be ignored when removal of network access can act as a master switch for all the nonexistent process in the Enterprise. Once your Enterprise starts pushing critical business functions outside of the Enterprise, there is no choice but to evolve your Enterprise towards claims-based Identity, federation, SAML, information cards, and this whole next generation of accountability. In order for Azure to exist, MS had to find a way to push credentials out into the cloud as well — and here we are.
This is the vision. And the opportunity, long awaited. For those of you who might think that this sounds like a great Microsoft conspiracy here, remember the protocols that this identity layer rests upon are OPEN, and although MS was involved, so were a huge number of other people and companies. Anyone can play. Instead of simply engineering an Identity layer for themselves, Microsoft has instead worked within the community to enable something much greater. I have been lucky enough to see just how much work, time, money, and care has been put into making sure that there are tools, products, and services out there that give people choice in the Identity Infrastructure they use to interact with services such as Azure.
I tip my hat to all you folks on the federated identity team at Microsoft — past and present members. You have walked and will continue to walk a tough line, but I hope that now, at least the story gets easier. Thank you.
