Category: Cardspace

Integrating OpenID and Infocard – Part 1

Let's start by taking a step-by-step look at the basic OpenID protocol to see how the phishing attack works.  (Click on the diagrams to see them on a more readable scale.)

The system consists of three parties – the relying party (or RP) which wants an ID in order to provide services to the user;  the user – running a browser;  and the Identity Provider (OpenID affectionados call it an OP – presumably because the phrase Open Identity Identity Provider smacks of the Department of Redundancy Department.   None the less I'll stick with the term IP since I want to discuss this in a broader context).

OpenID can employ a few possible messages and patterns, but I'll just deal with the one which is of concern to me.  An interaction starts with the user telling the RP what her URL is (1).  The RP consults the URL content to determine where the user's IP is located (not shown).  Then it redirects the user to her IP to pick up an authentication token, as shown in (2) and (3).  To do the authentication, the IP has to be sure that it's the user who is making the request.  So it presents her with an authentication screen, typically asking for a username and password in (4).  If they are entered correctly, the IP mints a token to send to the RP as shown in (5) and (6).  If the IP and RP already know each other, this is the end of the authentication part of the protocol.  If not, the back channel is used as well.

The attack works as shown in the next diagram.  The user unwittingly goes to an evil site (through conventional phishing or even by following a search engine).  The user sends the evil RP her URL (1) and it consults the URL's content to determine the location of her IP (not shown).  But instead of redirecting the user to the legitimate IP, it redirects her to the Evil Scooper site as shown in (2) an (3).  The Evil Scooper contacts the legitimate IP and pulls down an exact replica of its login experience (it can even simply become a “man in the middle”) as shown in (4).  Convinced she is talking to her IP, the user posts her credentials (username and password) which can now be used by the Evil Scooper to get tokens from the legitimate IP.  These tokens can then be used to gain access to any legitimate RP (not shown – too gory).

The problem here is that redirection to the home site is under the control of the evil party, and the user gives that party enough information to sink her.  Further, the whole process can be fully automated.

We can eliminate this attack if the user employs Cardspace (or some other identity selector) to log in to the Identity Provider.  One way to do this is through use of a self-issued card.  Let's look at what this does to the attacker.

Everything looks the same until step (4), where the user would normally enter her username and password.  With self-issued cards, username and password aren't used and can't be revealed no matter how much the user is tricked.  There is nothing to steal.  The central “honeypot credentials” cannot be pried out of the user. The system employs public key cryptography and generates different keys for every site the user visits.  So an Evil Scooper can scoop as much as it wants but nothing of value will be revealed to it.

I'll point out that this is a lot stronger as a solution than just configuring a web browser to know the IP's address.  I won't go into the many potential attacks on the web browser, although I wish people would start thinking about those, too.  What I am saying is the solution I am proposing benefits from cryptogrphy, and that is a good thing, not a bad thing. 

There are other advantages as well.  Not the least of these is that the user comes to see authentication as being a consistent experience whether going to an OpenID identity provider or to an identity provider using some other technology. 

So is this just like saying, “you can fix OpenID if you replace it with Cardspace”?  Absolutely not.  In this proposal, the relying parties continue to use OpenID in its current form, so we have a very nice lightweight solution.  Meanwhile Cardspace is used at the identity provider to keep credentials from being stolen.  So the best aspects of OpenID are retained.

How hard would it be for OpenID producers to go in this direction? 

Trivial.  OpenID software providers would just have to hook support for self-issued cards into their “OP” authentication.  More and more software is coming out that will make this easy, and if anyone has trouble just let me know.

Clearly not everyone will use Infocards on day one.  But if OpenID embraces the  alternative I am proposing, people who want to use selectors will have the option to protect themselves.  It will give those of us really concerned about phishing and security the opportunity to work with people so they can understand the benefits of Information Cards – especially when they want, as they inevitably will, to start protecting things of greater value.

So my ask is simple.  Build Infocard compatibility into OpenID identity providers.  This would help promote Infocards on the one hand, and result in enhanced safety for OpenID on the other.  How can that be anything other than a WIN/WIN?  I know there are already a number of people in the milieux who want to do this.

I think it would really help and is eminently doable.

This said, I have another proposal as well.  I'll get to it over then next few days.

Dmitry Shechtman's Undevelopment Blog

So much is happening in the identity discussion it's hard to keep up with it.  Through the miracles of ping-back I came across The Undevelopment Blog by Dmitry Shechtman, and this posting on a new proposal called Identity Manager: 

It seems like the OpenID community is currently bothered with the following two questions:

  1. OpenID facilitates phishing. What can be done about this?
  2. FireFox 3.0 will have CardSpace and OpenID support. What does that mean?

I addressed the OpenID phishing problem even before it became wildly discussed. Unfortunately, the method wasn’t foolproof, to say the least. Several other suggestions have been brought up, but none seemed to solve the problem without making OpenID unusable.

Kim Cameron of Microsoft has been repeatedly promising to elaborate on how CardSpace and OpenID could converge. Although he has yet to keep his promise, we can make an educated guess. We recently saw the FireFox extension Identity Selector act as an in-browser OpenID-to-InfoCard bridge. That is definitely something CardSpace folks would love to see as a standard browser feature, since it would effectively turn an OpenID into nothing more than a fairly insecure InfoCard.

Of course, OpenID could simply dismiss CardSpace (I was trying to get into the average kool-aid drinker’s shoes). Or it could very well learn from it. The CardSpace UI seems very intuitive:

  • A Sign In button on a website
  • An identity selection dialog
  • Seamless secure login

This is exactly what OpenID needs in order to become both widely used and insusceptible to phishing. And since CardSpace planned support is now a reality, why shouldn’t OpenID be integrated? This is no trivial requirement, but one that can be met with some additions to the browser logic.

The combination of UI and business logic outlined in this proposal is dubbed Identity Manager. The proposal uses informal language (should, must, be and do are used interchangeably); handle with care.

Whenever a web page presents an OpenID sign in option, the OpenID field and the Sign In button are replaced by a single OpenID Sign In button. Moreover, separate OpenID Sign In and CardSpace Sign In buttons are replaced with a Secure Sign In button.

Once such a button is pushed, an Identity Manager window is presented with a list of the user’s identities — OpenIDs, InfoCards or both, depending on what the relying party accepts. The user must be able to decline; we treat this case as trivial. The user must be able to make a persistent selection (e.g. a checkbox with the text Always use this ID for example.com).

(Dmitry's piece continues here…)

I would never characterize OpenID as “nothing more than a fairly insecure infocard”. It is a system where the root of trust is defined to be control over the content at a URL.  Folks, this is innovative.  I like it as what I call an “underlying identity system” that should live within the identity metasystem.  Given its theoretical starting point in terms of trust, OpenID has the security characteristics, good and bad, of the Internet which it harnesses in the name of identity.  That makes it very exciting, especially for bottoms up use cases involving public personna.

But “exciting” doesn't mean “good for every purpose.”  OpenID won't replace all other forms of digital identity!

Is it necessary to explain further?

I'm fine with blog comments being associated with my URL.  But I don't want access to my bank account to be gated by nothing more than the ability to set the header in what a system thinks is https://www.identityblog.com (I'm thinking here about all the potential attacks on DNS as well as the ways in which third parties could gain unauthorized access to my page). 

My site is hosted by the good people at http://www.textdrive.com.  As administrators of the shared systems there, they could certainly, for example, gain access to my pages. 

Are their employees bonded?  Do they practice strict separation of duties for access to web pages?  Do they have HR practices that will protect them from organized crime?  I don't think so!  And if they did,  wouldn't they turn into the world's most bureaucratic mess as a web hosting service?  Their flexibility and personal touch is what makes them so good.  I like them just as they are, thank you very much.

So it all comes back to the Laws of Identity.  There will be a pluralism of providers and technologies, optimal in different use cases.  And, as the potential phishing attacks demonstrate, there remains the requirement of giving users a consistent and controlled experience across these multiple systems.

My conclusion?

Combine CardSpace (insert your favorite replacement identity selector here) with OpenID and you have the best of both worlds.  You have the web-based identity system.  You have a consistent anti-phishing user experience.  And you have continuity between OpenID and other underlying systems in a metasystem.  Wouldn't we all want this?

As Dmitry reports, I have promised to share my own technical ideas about how to move forward but haven't come through on my promise yet.  So I'm going to do that now.  One idea is very simple (and effective) – I'll start with that.  The second is in many ways more interesting (at least to me) but I need to explain a bit more about managed cards before I get to it.

 

Superpat and the third way

Pat Patterson leaps through the firmament to punctuate my recent discussion of minimal disclosure with this gotcha: 

But, but, but… how does the relying party know not to ask for givenname, surname and emailaddress the second (and subsequent) time round? It doesn't know that it's already collected those claims for that user, since it doesn't know who the user is yet…

In the case described by Pat, the site really does use a “registration” model like the one from BestBuy shown here. 

When registering you hand over your identity information, and subsequently you only “authenticate”. 

This is really the current model for how identity is handled by most web sites.  In other words the “Registration process” is completely separated from the “Returning user” process.

So the obvious answer to Pat's question is that when you press “create an account” above, you invoke an object tag that asks for the four attributes discussed earlier.  And if you press “Sign in”, you invoke an object tag that only asks for PPID and then associates with your stored information.  

In other words, there is no new problem and no new framework is required.

This doesn't prevent Pat from serving up a little irony:

If only there were some specification (perhaps part of some sort of framework) that, given a token from an authentication, allowed you to get the data you needed, subject, of course, to the user's permission. 

I guess it bothered Pat that I didn't include use of backend protocols as one of the options for reducing disclosure. 

I want to set this right.  I've said since the beginning that as I saw it, the PPID (or other authenticated identifier) delivered by an InfoCard could also be used to animate a back-end protocol such as he's refering to.  That's one of the reasons I thought everyone should be able to rally behind these proposals.

The third option

So let me add a third alternative to the two I gave yesterday (storing locally or asking the user to resubmit through infocard).  The relying party could authenticate the user using InfoCard and then contact the identity provider with the user's PPID and ask it for the information the user has already agreed should be released to it.  This could be done using the protocols referred to by Pat. 

My uberpoint is simple.  InfoCards are intended to be as neutral as possible in their technical assumptions (e.g. to be an identity platform) and can be used in many ways that make sense in different environments and use cases.

I don't personally agree that the back-end protocol route for obtaining attributes is either simpler or more secure than delivering the claims directly on an as-needed basis in the authentication token, but it is certainly possible and I'm sure it has its use cases.  I wonder if Pat's implementation of Information Cards, should there be one, will take this approach?  Interesting.

 

Resending of personal data with InfoCards

Eric Schultz writes with this question: 

I've been investigating CardSpace and the practicality of it's use for login on a new social networking site.

I have a question regarding the method through which data is transferred. I see that you can require certain claims from an InfoCard such as email, first and last name, zip code etc. When I look at the login code I see that the same claims are required again.

Does this mean that each time an InfoCard is sent all the personal data is resent? Isn't this dangerous for security/privacy? The potential for a server failure (malicious or not) caused by a buffer overflow, a coding mistake that outputs the details of session variables etc. seems rather risky in this scenario.

Perhaps I am being alarmist?

This is an area in which being “an alarmist” – perhaps I will rephrase it as being thoroughly pessimistic about what can go wrong – is the best starting point.  You questions are ones everyone should think about.

InfoCard and Minimal Disclosure

The simple answer is that there is nothing built into InfoCard concepts that requires a “relying party” to ask for attributes every time a user comes to its site.  Let's first look at the mechanics. 

The relying party controls what attributes it asks for by putting an OBJECT tag in the HTML page where the user opts to use an infocard.

The example shown here will bring up the infocard dialog and illuminate any cards that offer all four claims so the user can select one. 

If, next time, the relying party doesn't want to receive these claims, it just doesn't ask for them.  If it has stored them, it should be able to retrieve them when necessary by using  “privatepersonalidentifier” as a handle.  This identifier is just a random pairwise number meaningless to any other site, and so there is no identity risk in using it.

No theoretical bias 

In other words, the InfoCard system has no theoretical bias about what information should be asked for when.  Through the Laws of Identity we have tried to help people understand that they should only ask for what they need to complete a transaction and should only keep it for the length of time they absolutely must. 

In particular, there should be no hoarding of rainy-day information – information that “might come in handy” some day – but which is more likely to turn into a liability than into a benefit.

Do your risk analysis 

You'll need to do the conventional risk analysis and think about whether it is more dangerous to store the information or just ask for it on an “as-needed” basis and then forget it.  My personal sense is that it is more dangerous to store it than to use an on-demand approach. 

A central machine with the stored information that animates a successful internet business is a honeypot.  It could well be subject to insider attacks, and certainly, since it lives on the internet, will be subject to many attacks on the information it stores.  Why not avoid these problems completely?

Certainly, the on-demand approach has benefits in convincing customers and legal practitioners that, having held no identity information, you cannot be seen as being responsible for an identity meltdown.  To me this is very attractive, and something that has not been possible until now.

Conclusion

The examples Eric gives of things that can go wrong seem to me to apply even more strongly if you have stored information locally than if you ask for it on demand.

But as I said earlier, this just expresses my thinking – there is lots more to be written by Eric and hundreds of others as they develop applications. 

Meanwhile, InfoCard has no built-in assumptions around this and can be used in whatever way is appropriate to a given situation.

 

Bill Barnes is CardCarrying

Bill  Barnes is more responsible for crafting the Cardspace user experience than anyone on our team.  Now, he's not only working on next generation Cardspace, but tackling the user experience issues that arise when integrating InfoCards into web sites (e.g. “how to build a relying party?”.  Of course, this is an on-going project and – great news – he'll be using his new CardCarrying blog to express his thinking and develop ideas.  For those interested in InfoCards, this is a “must-subscribe”.  Here's his take on what he's doing: 

Information Cards are a new approach to digital identity. So new that I’ve noticed an interesting phenomenon – in the hundred or so times I’ve presented our idea, to audiences of all kinds, it always takes the better part of an hour to convey. Sometimes more. And I’m a good speaker.

This shouldn't be surprising. They’re new, and one would expect the concepts to take a while to sink in. I remember the first time I saw the World Wide Web, then just a few months old. I just didn’t get it. My friend did a very admirable job as visionary, but it didn’t click. Same thing with TiVo. Again, I’m not dumb, not that dumb anyway, but new ideas take a while to filter in.

And Information Cards have it worse. They’re not just new, they’re different, and different is harder. You don’t just have to learn, you have to unlearn. This helps explain why security experts often take the longest to grasp what we’re doing – we’re forcing them to go back to first principles, and for many of them that’s a long way back. But even my mom has to unlearn passwords, and that won’t happen instantly.

I love to talk, I do. So I don’t mind speaking for the better part of an hour if that’s what it takes to get someone up to speed. But I have two jobs. My busy schedule simply won’t allow me to teach Information Cards to every man, woman, and child on the Internet today. How are we going to educate them? More to the point, how will website X, which thinks supporting Information Cards will garner more customers from increased security and convenience, educate them?

The good news is, not everyone needs to understand the end-to-end meta-architecture. They just need to understand what they need to make it work. One of the reasons we adopted the Card metaphor was that it brings with it some intuition. Hopefully, then, a given website won’t have to do very much explanation.

Here’s what I think they need to know, in language that I am continuing to develop. My hope is that, with these few key concepts under their belt, the flow of the website plus the user experience of their identity selector, be it Windows CardSpace or a competitor, will be clear enough to take them the rest of the way. So, without further ado:

Information Cards are like digital versions of the cards in your wallet. You can make personal cards for signing in to websites – they are like passwords but are much harder to steal. Personal cards are stored on your computer, and you can use a single card to sign into multiple websites.

You can also download managed cards from organizations like banks, associations, and businesses. When you want to prove something about yourself to a website, for instance “I am a member of club X” or “I work for company Y”, show that website a managed card. A managed card is stored on your computer, but the information it conveys is not.

These are the key points I think people need to understand. And the second part, managed cards, isn’t necessary if your site doesn’t take managed cards, and that’s most of them out of the gate. So really it’s one paragraph, three sentences, four or five concepts.

Don’t get me wrong, I think four or five concepts is a lot, and I don’t expect everyone to get it right away. I think inevitably what will happen is that a small group of geeks will learn these concepts deeply, and start to evangelize them in the blogosphere, in media, and to their parents. A good analogy here is RSS. My experience in that hardly anyone outside the technorati knows what it is yet, and very few people will bootstrap themselves simply by seeing that magic orange square. Conversions happen one at a time, from one satisfied (and informed) customer to another. My mom will use Information Cards because I tell her why she should.

I have heard some other great ideas about educating people. More on these later. Meanwhile, let me know how you would educate a user at your website on what Information Cards are, and why they should use them at your website. Would you use my language or a variant thereof? Share the love.

Oh, one more thing. I’m not speaking in an official capacity here, but I don’t think it’s reasonable to expect Microsoft or anyone else to mount a giant P.R. education campaign on Information Cards, any more than you would expect them or anyone else to convince you to use RSS. If it’s really a good technology (and I think it is) it will succeed because it is in everyone’s benefit when it is used. So I think everyone shares the educational burden. So get teaching.

Virtual gardens with real-world walls

Here is a fascinating piece from OZYMANDIAS that oozes with grist for the User Centric mill.  This seems to be about walled gardens with barbed wire.  Please don't take what I'm saying as being critical of Sony in order to puff some other company (like, er, my own).  I'm talking about the general problem of identity in the gaming world, and the miserable experience much of the current technology gives us.  I think I should be able to represent my gaming personas as Information Cards – just as I would represent other aspects of my identity – and use them across games (and one day, even platforms) – without linkage to my molecular identity. 

News on the web today is that Xfire is suing GameSpy for how their GameSpy Comrade “Buddy Sync” feature creates friends lists. To quote:

Now Battlefield 2142 is caught up in a legal tangle between rival in-game instant messaging programs Xfire and GameSpy Comrade. On October 16, Viacom-owned Xfire filed suit against News Corp subsidiary IGN Entertainment over its GameSpy Comrade program, which comes on the Battlefield 2142 disc. IGN Entertainment also owns IGN.com, a GameSpot competitor.   

Xfire is claiming that GameSpy Comrade's “Buddy Sync” feature illegally infringes on its copyrights. Buddy Sync retrieves users’ friends lists from other instant messaging programs like AOL Instant Messenger and Xfire, and gives players the option of automatically inviting those friends who have GameSpy accounts to join the users’ friends lists on Comrade.

If you read a bit deeper you find that what's basically being challenged is GameSpy's use of information (friends lists) that has been publicly published by Xfire on their website. Xfire claims that GameSpy's reading of that data is to enable GameSpy to bolster their own friends lists:

In a filing in support of the restraining order, Xfire CEO Michael Cassidy specified how his company believes the Comrade program works. First, Cassidy said it reads the user's Xfire handle from the XfireUser.ini file, then visits a formulaic URL on the Xfire site to get a list of the user's friends (for instance, to find the friends list of Xfire user Aragorn, Comrade would go to http://www.xfire.com/friends/aragorn). The names on that friends list are then compared with a central IGN database of Comrade users’ Xfire handles, and if any matches turn up, the user is asked if they want to invite those people to their Comrade buddy lists.

I am not a lawyer, and can't definitively comment on whether information that's made public in this fashion can or cannot be harvested. My gut is that it's probably kosher – we have plenty of website scraping applications in the wild today that do just this, including best price searching sites. What does fascinate me is how this suit highlights how busted Sony's PS3 online network is, and how companies are fighting to position themselves to take advantage of this financially. Bet that seemed to come out of right field. Wink But here's where I'm coming from.

I wrote earlier about why Sony's enabling of Xfire for PS3 games wasn't as exciting as it might seem. Take a read, and then let's talk about just what the experience of being an online user on PS3 is likely to be like.

So I buy my PS3, bring it home, and go online. The first thing I'm going to be asked to do is create some sort of Sony Network ID. That “Sony ID” will apparently bring basic presence and communication features via the crossbar interface. So far so good. Now I decide to play Insomniac's Resistance, which recently stated the following:

Insomniac's Ted Price: “The buddy list is specific to Resistance. And we decided not to bother people in-game with messages. If you have a new message sent to you while you're in a game, you'll see your “buddy list” tab flashing when you re-enter the lobby after playing a game. The buddy list tab is where you can access your friends, ignore list, messages, etc.”  

1Up (to reader): “Does this mean there's a system-wide friend's list, but you have to compile game-specific friends lists for each online game you participate in? That doesn't make much sense, and hopefully today's event will clear up the situation.”

Yes Virginia, that's exactly what this means. Even though I already have a “Sony ID”, I may have to create a new “Resistance ID” to play. And then start thinking about just how broken the experience is when you try to invite someone to a game. Do you send it via the Resistance UI? What screenname do I send it to? If I want to add you to my “Sony ID” friends list, do I need to send you an in-game message to ask you what your real “Sony ID” name is? What about game invites? How does that work across even just these two IDs?

You think that's bad? Now let's open up a few more games from different publishers. Each of these publishers had to make a choice of what online interface to use – again, because Sony's online network just isn't ready. So they'll choose between writing their own (as did Insomniac for Resistance), or perhaps licensing Xfire, or GameSpy, or Quazal, or Demonware. So now we have five potential networks with different namespaces, and an inherent  lack of ability to communicate (chatting, voice, invites, finding friends, etc.) between them, and even across to just the “Sony ID” namespace. Think we're done? Nope… what happens if each publisher doesn't stick with the same online solution for all of their games? This is very likely as most publishers use different developers – so even across a single publisher, you may find fragmented communities.

The only consistent tie all of these different community fragments has is that a user should always have their Sony ID. That gives you a lifeline to be see friends when they are online… but only in the crossbar UI. Will you even be able to see what game they're playing? What about what network that game uses, and whether that friend is logged into it? How will you get messages in a timely manner? Remember Ted Price's quote above? “And we decided not to bother people in-game with messages. If you have a new message sent to you while you're in a game, you'll see your “buddy list” tab flashing when you re-enter the lobby after playing a game.” Doesn't sound like a user-centric design decision to me.

So… back to Xfire and GameSpy. I said earlier this suit is a direct result of how busted Sony's online network appears to be, and I just described some of the issues you'll likely be facing later this month. Yes, it's targeted at a PC title right now (Battlefield 2142), but that's just noise. What we're really seeing with this suit are online middleware companies trying to position themselves to become the eventual defacto solution that publishers will use. Just as with web search and instant messaging, these companies are trying to get momentum and user base that will cause them to be the “PS3 online” solution of choice. And this suit is simply one of many battles we'll see in this space, especially as PC and console crossplatform connectivity becomes more important in the coming years.

When my role as a player is really valued, I will be seen as owning my own buddy list.  Using zero knowledge technology, it will be possible for me to hook up with any of my buddies’ personas – across various games and without committing sins of privacy.

 

Information Cards supported on Community Server

Armand du Plessis at Impersonation Falure writes about his work to add Information Card support to his Community Server:

A couple of days ago I enabled experimental Windows Cardspace support on http://dotnet.org.za/. I mentioned that I'll post the source code and controls but with Tech-Ed Africa and some other work I never got around to posting it.

So now the updated Community Server files is available here and the source code for both the Community Server controls and the underlying ASP.NET controls available here.

To enable Community Server to make use of Information Cards for authentication the following steps are required :

  • Install and configure your site with a SSL certificate. (Make sure it's a certificate issued by a Certification Authority trusted by popular browsers so you don't make the same mistake as me. See this post for more info)
  • Grant access to the certificate's private key to your application pool user. Easiest method to do this is using the winhttpcertcfg.exe utility.
    • winhttpcertcfg -g -c CertLocation -s SubjectStr -a Account
  • Add your certificate's thumbprint to your web.config appSettings section so the Token processor helper class can find it :
    • The thumbprint can be obtained through the MMC Certificates snap-in.
  • Unzip the updated Community Server files over the CS web files. The following files will be replaced so make sure you've backed them up before this step :
    • \Themes\default\Masters\master.ascx
    • \Themes\default\Skins\Skin-EditProfile.ascx
    • \login.aspx

How it works is relatively straigth forward, kudos to the design of the Cardspace web integration and the Community Server SDK. A quick explanation :

The source consists of four core controls :

  1. Adp.CardSpace.InformationCardRequest – A very basic ASP.NET control that takes care of rendering the < object > element used to engage the Identity Selector with the desired claims the Relying Party wants from the Identity Provider. This can either be placed in the head of the page when working together with the InformationCardSubmit control, or as a standalone in a form body.
  2. Adp.CardSpace.InformationCardSubmit –  Another basic ASP.NET control that renders the required script and a button that can be used to engage the Identity Card Selector. It is meant for consumption by higer-level controls that can subscribe to it's OnTokenReady event which is fired when a postback triggered by the ICS happens.
  3. Adp.CommunityServer.Controls.Association – A Community Server control used in the profile section to allow a user to associate an Information Card with his/her account.
  4. Adp.CommunityServer.Controls.CardSpaceLogin – A Community Server control used to authenticate the user using his Information Card instead of the usual username/password.

The claim requirements is expressed through the Claims property on the Adp.Cardspace.InformationCardRequest control. This can be done programmatically or declaratively and the control added either to the page head or to a form body. Adding the control to the page head as done in the Community Server integration allows for fine grained control over when the Identity Selector is invoked without interfering with other form submit buttons on your page.

Below is an extract from master.ascx which embeds a request for two claims, email and PPID, into the page. (By default self-issued cards are accepted but this can be configured through the Issuer property on the control) 

< CS:Head runat="Server">
< meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
< CS:Style id="UserStyle" runat="server" visible = "true" />
< CS:Style id="s2" runat="server" visible = "true" Href="../style/Common.css" />
< CS:Style  runat="server" Href="../style/common_print.css" media="print" />
< CS:Script id="s" runat="server"  />
< ADP:InformationCardRequest ID="_xmlToken" runat="server" Claims-Capacity="4">
< ADP:ClaimDto ClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier" Required="true" />
< ADP:ClaimDto ClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" Required="true" />
ADP:InformationCardRequest>
CS:Head>

 Where the Identity Selector trigger is required the Adp.Cardspace.InformationCardSubmit control is placed. The sole responsibilty of this control is to invoke the Identity Selector and raise an OnTokenReady event which can be consumed by other interested parties. Below is an extract from the Skin-CardspaceLogin.ascx (a Community Server control which uses the InformationCardSubmit control to obtain the encrypted token)

< ADP:InformationCardSubmit CssClass = "CommonTextButtonBig" runat="server" id="csSubmit" />

 That's all that's required to invoke the ICS. To decrypt and extract the token using the very useful TokenProcessor from the Microsoft samples the following code is required to hookup and handle the OnTokenReady event. (This code is in the above mentioned CardSpaceLogin control, a composite control utilizing the InformationCardSubmit control and other default Community Server Controls) 

protected override void  AttachChildControls()
{
submit = FindControl("csSubmit") as InformationCardSubmit;
message = FindControl("csMessage") as StatusMessage;
 
submit.OnTokenReady += new EventHandler(submit_OnTokenReady);


if ((submit == null) || (message == null))


throw new CSException(CSExceptionType.SkinNotSet);


}




The Token helper class takes care of decrypting and extracting all the tokens from the postback. (The token helper class is available in the samples on http://wcs.netfx3.com)


After breaking out the tokens we can access them through the indexed Claims property. All the claims we expressed in the InformationCardRequest control above is available for use in your code.  In the sample below the token's unique id is extracted and assigned to an extended profile attribute in Community Server.




void submit_OnTokenReady(object sender, TokenEventArgs e)


{


try {


Token token = new Token(e.TokenValue);




if(context.User.Email !=


token.Claims[System.IdentityModel.Claims.ClaimTypes.Email]) {




DisplayMessage(ResourceManager.GetString("Association_EmailMismatch",


CSUtil.CsResourceFilename), false);


return;


}


 


context.User.SetExtendedAttribute(CSUtil.CsExtendedAttributeName,


token.UniqueID);




Users.UpdateUser(context.User);


 


DisplayMessage(


ResourceManager.GetString("Association_Success",


CSUtil.CsResourceFilename),true);


 


}


catch (Exception e1) {


string displayMessage = ResourceManager.GetString("Association_GenericException",


CSUtil.CsResourceFilename);


 


CSException e2 = new CSException(CSExceptionType.UnknownError,


displayMessage, e1);




e2.Log();


 


DisplayMessage(displayMessage, false);


}


}




Some limitations in this implementation is that it currently don't detect whether or not the browser supports Infocards. Also triggering the Identity Selector through script currently don't seem to be supported by the Firefox Identity Selector plug-in.


Currently the implementation on dotnet.org.za still suffers from the use of the Starfield SSL certificate which requires users to first import the Intermediate Certificate as a trusted issuer before Cardspace will accept it. This will be rectified soon.


Links:






	


	
	






	
	

		
Ping unveils Managed Card IP written in Java
	


	

		
Ashish Jain of Ping Identity seems to have broken another barrier by demonstrating a “managed card” identity provider written in Java.


In the world of InfoCards, we talk about two kinds of “identity provider”.  One is a “self-issued” card provider, through which individuals can make claims about themselves.  The other is a “managed” card provider, which supports claims made by one party about another party. 


Examples of managed card providers could include claims made by an employer about its employees; a financial institution about its customers; an enterprise about its customers; or a reputation service making claims about its users.  While the technology for posting tokens from an identity selector like Cardspace to a web site can be very light weight (RESTful), that for building managed card providers is more challenging.


Here's how Ashish puts it:


The Managed Card IdP as well as the RP server that we demonstrated at DIDW is now available for a test run. It’s still early access…so expect some issues. But if you do want to try early, give it a go. It should give you an idea of the things to come.


baby_beer400x299.jpeg


Please do the following (you need to have RC1 client installed on your machine).


    

  • Access the IdP Demo here.
    • 

  • Enter your information and click ‘Get Card’.
    • 

  • When the popup happens, click “open” to save it to the CardSpace Client. Alternatively, you can save it to the disk and double-click to install it. (You can change the extension from .crd to .xml if you are interested in looking at the contents).
    • 

  • Close the CardSpace Client.
    • 

  • Next go to the RP site here.
    • 

  • Click on the Managed Infocard Image.
    • 

  • Your CardSpace client should pop-up at this time and only the relevant card should be available for selection.
    • 

  • Select the card and it will challenge you to enter your IdP credentials. The server doesn’t perform any password validation at this time (as long as the username is correct).
    • 



And you should be logged in to the Relying party. The relying party page also displays the IdP as well as the RP message flow.


I tried it and it definitely worked for me.  I'll do a screen capture.


I don't know if the picture in Ashish's piece shows something he drank as a baby, but if so, a lot of other programmers may want to try some. 


 

	


	
	






	
	

		
DasBlog site InfoCard enabled
	


	

		
Of course Kim Cameron's Identity Blog has been InfoCard enabled for a while, and I've written about the process.  Now others are working (more on this later) to produce a WordPress InfoCard Plugin for everyone who wants to start accepting InfoCards.


Then a while ago I learned that Rob Richards had InfoCard-enabled his Serendipity-based blog and again published the code for others to examine.  


Now Kevin Hammond has done the same for DasBlog – though I'm not sure yet if I can leave comments using InfoCards:


Taking inspiration from Kim Cameron and how he CardSpace-enabled WordPress, I did the same with DasBlog 1.9.6264.0. casadehambone.com now supports logging into the administrative account using Windows CardSpace allowing me to throw the use of passwords to the wind!


The great thing is that it only took minor changes to three source files and the introduction of one new configuration option each to site.config and siteSecurity.config. I have a little more work before me to make configuration just a tad easier, but the great thing is that this works really well.


I owe special thanks to Clemens Vasters who suggested this morning that the proper “hack” to get this working was to build DasBlog with Visual Studio 2005 and the Visual Studio 2005 Web Application Project add-on. DasBlog built out-of-the-box without issue, making the integration of TokenProcessor.cs to decrypt the SAML token a piece of cake.


If you haven't looked at Windows CardSpace yet, head on over to cardspace.netfx3.com and start reading. Now that Windows Internet Explorer 7.0 is released and Release Candidate 1 of .NET Framework 3.0 is available, you'll find the mainstream barriers to adoption are quickly eroding.


I hope Kevin also publishes his code so others can learn from it.

	


	
	






	
	

		
Serious cardmaking
	


	

		
Kevin Hammond ups the ante on how to put a graphic on your infocard.  His reference to my card makes me blush – I just “borrowed” a graphic that had been assembled by one of the computer journals, not having any idea of how one would make it.  One day I'll find the time to play with the cool technology he is talking about.


There's a lesson here though.  When people start hand-tailor their cards, it becomes impossible for “phishing software” to successfully perform social engineering attacks that trick people into thinking a fake CardSpace interface is real.  The phisher has no idea of what kind of graphic or what kind of photo the user has created – so it just can't do a believable impersonation.  The result is that the user immediately recognizes something is very wrong.


 I've been getting my feet wet with Windows CardSpace and my self-issued card. In watching Kim Cameron's demonstration of how he integrated CardSpace with WordPress, I saw his nifty looking card with his portrait on it. Right then and there I decided I too must have one. What do you think of the results? Here's how I did it.


 I made a self portrait with my Canon EOS 20D and an EF 50mm f/1.8 II lens.  I extracted the headshot with Photoshop CS2’s Extract filter, did some complexion touch up and resized it to what you see here, about 60×64 at the shoulder. I created a new 120×80 image according to the guidance provided by Vittorio Bertocci in his great article about how images are mapped onto cards. From here, it's all a composite. There's a layer for the black rectangle across the bottom, a layer for the gradient background, a layer for my portrait, and a layer each for the text. It took some experimenting with fonts and text transformation to arrive at the setting you see here – by far the largest part of this entire exercise. My Layers palette is reproduced here for your reference. Frankly, I'm surprised by the result because I'm by no means a Photoshop guru. But I think I now have something cool to liven up casadehambone.com with!


Vista does one annoying little thing in the reflection it places on the top third of the card when it renders it within the Windows CardSpace UI. I can see how they're trying to be cool, but I think it detracts rather than adds to the overall experience.