Category: Windows Cardspace

The European e-Identity Conference

I don't often mention my speaking agenda, but next week I'll be giving the opening keynote at a conference in Paris that looks like a great opportunity to exchange information.  It is hosted by EEMA (which has morphed into the European Association for eIdentity and Security) and ENISA (the European Network and Information Security Agency).  If you've been sitting on the fence, it looks like the conference has really come together. Here's the program.

One track is called “managing identity” (in the largest sense) with presentations about architecture and application development approaches by Siemens, SEALED and SAP.  It includes roundtables on interoperability, security-identity interfacing and SOA. 

The other track is on “social networking” with presentations on Netlog and Facebook, and a fascinating series of roundtables on a nice taxonomy of reputation issues.

And that's just day one!  Day two is huge. 

Jeff Bohren on role of CardSpace

Jeff Bohren at BMC Software has an interesting take on CardSpace and TEG – as well as other related matters.  And in this posting he says that BMC Software will be participating in the interoperability event at the next Burton Catalyst.  This really adds to the momentum. 

There will be a User Centric interoperability event at the next Burton Catalyst in SF. This will bring together several IdM vendors and open source projects to demonstrate interoperability between different implementations of Cardspace/InfoCard and OpenID. BMC Software will be participating. We will also have a hospitality suite the following night. I will be there so if you want to drop by I would be glad to talk with you about IdM issues.

Mike Jones from Microsoft has some great Cardspace/InfoCard resources on his blog. If you are interested in this area, you should definitely check this out. You should also check out Pamela Dingle’s introduction to Cardspace.

Microsoft has recently announced that they have sold over 40 million copies of Vista in the first 100 days since its release. Obviously not all of those are installed and in use, but this still a lot of users. And every one of them is a potential Cardspace user.

If IE isn’t your cup of tea, there are several other option available. Xmldap.org has a plug-in for Firefox. I gave it a try, but for some reason I could not use it to do InfoCard authentication to Kim Cameron’s blog, which you can obviously do with CardSpace.

There has been a recent spurt of debate over at the TEG mailing list about Cardspace. I don’t want to waste TEG bandwidth on what is really a tangential issue, so here is my take on the value of Cardspace/InfoCard.

The best way to think of the value of Self-Issued InfoCards is to think of them as analogous in feature to end-user SSL client certificates. In essence they are a holder-of-key style authentication that can be used by itself or in conjunction with a password based authentication to dramatically improve the security of the authentication process. Like client certificates, InfoCards authenticate the computer the user is on, not the user. They further have the advantage of presenting a very user friendly graphical mechanism to select what identity should be used.

While all InfoCard implementations have this value, Cardspace goes further and adds additional features to thwart phishing, man-in-the-middle-attacks, and software key loggers. If the US banks where smart, they would adopt InfoCard as their solution to comply with FFIEC guidance for on-line banking. Cardspace/InfoCard could be used as a second factor of authentication to use for financially sensitive transactions. Not as a replacement for passwords, but as a supplement. And best of all (to the bank) there is zero cost on a per user basis.

For enterprises there is an important potential value for InfoCards, and it has nothing to do with internal authentication. The value is by using InfoCards, an employee of a company can easily choose different identities depending on whether he is representing the company in a specific transaction or not. It has to do with separating personal from professional personas. A company could issue a managed InfoCard to each employee for use for their professional persona and establish best practices for using their self-issued InfoCards for personal business. Now you can do this without InfoCards by creating multiple IDs, but as a practice no one does that.

Update 5-24-07

Shibboleth just announced that they will add support for Cardspace/Infocard in the Shibboleth architecture. Kim Cameron's thoughts about it are here and Mike Jone's comments are here. This is a great development. The Shibboleth project has a great deal of respect and mind share in the identity community.

I'm not sure I agree that InfoCards authenticate the computer the user is on, and not the user.  I think that depends on whether they are combined with a challenge such as a one-time password.  I hope Jeff writes more about what he means by this.

Shibboleth adds CardSpace support

Here is news from Internet2 and Shibboleth, the open-source software for building multilateral federations that has become especially popular in the academic world (more information on Shibboleth here). 

ANN ARBOR, Mich. – May 23, 2007 –  Adding information card support to Shibboleth, the most widely-deployed federated authentication architecture, would enable interoperability with Windows CardSpace which provides critical support for secure user-centric authentication and identity information exchange for web-based applications. By enabling this interoperability, Microsoft and Internet2 aim to help users exchange personal identity information more safely and easily. In doing so, institutions can more effectively leverage their existing and future investments in their identity management solutions and build a closer, safer relationship with their users.

“As more and more companies and organizations make information materials and resources accessible online, the need for secure access solutions has become critical. We see information card technology like Microsoft's Windows CardSpace as a very important step forward in creating a ubiquitous Internet identity layer, which is a key goal of the Shibboleth project as well,” said RL “Bob” Morgan, security architect at the University of Washington and co-manager of the Shibboleth Project. “We appreciate Microsoft's leadership in helping to create an open environment for information card development and deployment, and are grateful for Microsoft support of Windows CardSpace work in Shibboleth.”

Shibboleth is a standards-based, open source middleware architecture providing both intra-domain and inter-domain single-sign on (SSO) capability. Used by over 20 million users worldwide within the research and higher education community, Shibboleth implements the OASIS Security Assertion Markup Language (SAML) standard specification, and is currently interoperable with Microsoft's Active Directory Federation Services (ADFS).

Both Shibboleth and Windows CardSpace provide the underlying mechanisms for institutions and individuals to share resources across organizational boundaries and to make informed authorization decisions for the access of protected online resources. This federated authentication model implemented by both Internet2 and Microsoft has proven to provide online resource providers and institutions with a solid platform for exchanging information in a highly secure and privacy-preserving manner. Once development is complete, sites using Windows CardSpace will have the ability to participate in the growing number of Shibboleth-based federations worldwide.

“The Internet2 Shibboleth project has been one of the leaders in bringing interoperable digital identity to the academic and research communities worldwide,” said Michael B. Jones, senior program manager for Identity Partnerships at Microsoft. “Shibboleth's support for information cards allows people in the Shibboleth federation to use the cards at sites participating in the Identity Metasystem, making the identities more valuable to both the issuers and to the individuals, as well as enhancing the user's control of their online interactions.”

I echo Mike's words.  Shibboleth is distinctly forward thinking in its approach, and has been the main crucible for refining the thinking (and practice) that enables multilateral federations like those needed to facilitate co-operation between universities. 

As Shibboleth federations continue to grow, so will the rewards for attacking them.  CardSpace, and other compatible Information Card selectors, will add resilience and phishing resistance while helping solve Shibboleth's “home site discovery” problem in a way that doesn't put control in the hands of evil sites posing as federation affiliates. 

For more details on what is at stake here, see this posting where I explain a similar vulnerability in OpenID.  SAML and the browser-based version of WS-Federation are also subject to these attacks, which become more probable as the technologies become more widely deployed.   

Pamela Dingle on multiple issuers

Some clear and advanced thinking from Pamela Dingle at Eternal Optimist:

Here is a simple and likely RP scenario that I’d like you to consider:

A given site wants to allow users to pay with either their Visa or their Mastercard information card. They do not, however, accept American Express. How should they create their security policy such that Visa and Mastercard managed cards are both highlighted in the Identity Selector if present, but also such that an American Express Card is grayed out and not clickable?

Would you all agree that this is a pretty important thing for a Relying Party to be able to implement? I think it’s important too, but I don’t see an easy way to actually accomplish it.

To my knowledge, there are two ways to choose what cards are highlighted and what cards are grayed out in the identity selector:

  • if a card’s issuer matches the value of the issuer parameter

  • if the entire set of required claim types are all present in a given card.

In the scenario above, the issuer parameter is a non-starter, because Windows CardSpace v1.0 only accepts a single issuer. And at this point in the identity metasystem, what WCS says, goes. I can specify Visa’s STS, or I can specify Mastercard’s STS, or I can choose not to specify an STS at all, but I cannot specify exactly two of them. Bottom line: as soon as I need to create a policy that lists more than one issuer, but less than all issuers, I cannot use the issuer statement.

So – that leaves us claims. Claims are great – when you can use what’s in them. In this case, however, the RP can’t work with claim values, only with claim types. In order to succeed in my scenario using claims, I would need to be able to specify a claim type that both Visa and Mastercard offer, but that AmEx doesn’t, in order to have the right cards show up and the wrong cards gray out. What exact claim type would that be? The only way I can see to architect such a thing is to have a commonly agreed upon but different claim type for every possible distinct combination of credit cards. Let’s say that there are 6 major credit card companies out there. How many permutations & combinations of claim types would be necessary to cover every single combination of 2,3,4, and 5 accepted cards, and how ugly would it be to add a new credit card?

It could theoretically be done. Identity Providers would have to start publishing two very separate types of claim types — contentless claim types that advertise capabilities, and content-rich claim types that would deliver actual data values. If you implement the capability claim types as constants and not as directory schema, it isn’t so bad — but the big problem is, it takes the ‘distributed’ out of this wonderful distributed system.

Unless things change (or unless I’m proven wrong, maybe I’m just missing some answers and need to be educated), here is what I fear will happen: users would go to a Relying Party Site, only to be presented with an HTML “menu” of supported managed card providers. They would then click on the card provider logo, and an HTML object would be invoked which has an issuer tailored to that single provider. Is this what we want to have happen?

If it does happen, I can see all sorts of fallout:

  • Common claim types are no longer needed to ensure the user picks the right card. This is good.

  • Every RP has to alter HTML to support a new Identity Provider. This is bad, or at least worse than adding a url to an allow or deny list.

  • The ability for a Relying Party to require the same claims from every Identity Provider becomes damaged. This is bad. Of course, with issuer in the state it is in, I would say that no matter what, this is already the case.

  • The system is more distributed, but MUCH less consistent for the user. This is bad.

  • It opens the door for the more established Identity Providers to set arbitrary rules on what attributes “must” be asked for in order to interoperate, forcing Relying Parties to embed different code for each provider. This is bad.

Of course, all of this hinges on how important the initial card presentation ceremony becomes to the world. Remember that we are not talking about the RP’s ability to accept or reject a card once it has been selected. We are only talking about how to get the most user-friendly initial display of highlighted or grayed out cards when the selector opens. Maybe this small part of the information card ceremony won’t end up being that important — but I predict that it will. If I could have have any kind of solution to the problem, it would be the ability not just to list multiple issuers, but to apply Boolean logic to the list, so that I could represent ideas like “every issuer except these two”.

Kim, Mike, what can we do? Is this as big a problem as I’ve made it out to be, or am I just whining about something inconsequential? What is your vision of how my scenario could be implemented? Can this be solved with a few best practices, or do we need to change the way that information card RP security policies can be specified?

Pam's thinking is unassailable.  The problems she outlines are issues we just didn't have time to solve in version 1.0 of CardSpace. 

We were aware of them, but wanted to get the first round of our technology “out there” so everyone could start doing proofs of concept and implementations that would help clarify the right approaches.  I think in practice we'll have time to fix this before people anyone really “feels” it.  Not all credit card providers will be supporting information cards at once.  Meanwhile we'll be pumping out more advanced versions of CardSpace that address the issue.  

The same problems Pam describes with respect to issuers apply with respect to RP support for multiple token types (e.g. SAML tokens plus OpenID tokens).  Currently we can address this by accepting “any” token type, and that will get us by for a while, but ultimately we will need to be able to specify rich combinations.

WS-SecurityPolicy is powerful enough to express boolean logic, so theoretically the relying party can publish metadata that has all the capabilities Pam calls for.  For example, you can say you will accept American Express AND Visa as issuers but not Diner's Club.  You can also require different claim types from different issuers.  So the architecture is adequate to the problems.  

So given that the architecture is right, it represents an opportunity for our competitors…  And we ourselves are working really hard to solve this problem in our next version – before it anyone feels the pain.

Age and identity verification in Second Life

Via Dennis Hamilton, a pointer to a new experiment at Second Life:

We will shortly begin beta testing an age and identity verification system, which will allow Residents to provide a one-time proof of identity (such as a driver’s license, passport or ID card) and have that identity verified in a matter of moments.

Second Life has always been restricted to those over 18. All Residents personally assert their age on registration. When we receive reports of underage Residents in Second Life, we close their account until they provide us with proof of age. This system works well, but as the community grows and the attractions of Second Life become more widely known, we’ve decided to add an additional layer of protection.

Once the age verification system is in place, only those Residents with verified age will be able to access adult content in Mature areas. Any Resident wishing to access adult content will have to prove they are over 18 in real life.We have created Teen Second Life for minors under the age of 18. Access to TSL by adults is prohibited, with minors not allowed into the rest of Second Life.

For their part, land owners will be required to flag their land as ‘adult’ if it contains adult content using the estate and land management tools provided to landowners. This flag will protect landowners from displaying inappropriate content to underage users who may have entered Second Life. Landowners are morally and legally responsible for the content displayed and the behavior taking place on their land. The identity verification system gives them new tools to ensure any adult content is only available to adults over 18 because unverified avatars will not have access to land flagged as containing adult content.

We hope you’ll agree that the small inconvenience of doing this once is far outweighed by the benefits of protecting minors from inappropriate content. Further, this system will assist landowners in engaging in lawful businesses.

The verification system will be run by a third party specializing in age and identity authentication. No personally identifying information will be stored by them or by Linden Lab, including date of birth, unless the Resident chooses to do so. Those who wish to be verified, but remain anonymous, are free to do so.

(Continues here…)

The idea of presenting a passport to get into an imaginary adult establishment strikes me as nutso.  I must be missing a gene.  It is certainly a conundrum, this virtual world. 

I think that rather than adopting this one-off inspector approach, outfits like Second Life and all the other big web sites should get together to accept registration claims from whatever identity providers would fully guarantee both accuracy and the anonymity of their users.  Information Cards combined with the anonymous credential technology developed by people like Stefan Brands would provide the ideal solution.

WS-Federation OASIS TC

I'll begin by quoting from a piece by Paul Madsen after the OASIS announcement of a new working group to drive WS-Federation towards standardization.  Paul writes: 

“James McGovern predicts:

‘I humbly predict that WS-Federation will become more important than SAML within the next two years and will invalidate all the hard work already done by the Liberty Alliance.’

“I guess it's over. I have to admit that I'm disappointed and, to be honest, even surprised.

“I actually thought things were going well, you know, lots of adoption, encouraging signs of convergence, important new functionality etc.

“As for the New Jersey Devils, it seems that the Liberty Alliance's playoff run is over. I'll be emptying my locker and signing autographs this afternoon before spending the summer golfing.”

Like Paul, I'm surprised, if not so inspired to irony, by James’ comment. 

I do agree that WS-Federation will gain a lot of traction.  But I absolutely disagree that it will “will invalidate all the hard work already done by the Liberty Alliance.” 

Liberty has contributed deeply to understanding a whole series of use cases and requirements, and the protocols, formats and concepts proposed by the SAML working groups have been an important step forward for all of us involved with identity.  Nothing about WS-Federation invalidates this work.

On the other hand, technology doesn't stand still.  Think back to the days when SAML was first posited as an alternative to LDAP authentication.  Those of us involved in LDAP from the very beginning didn't for one minute take LDAP as the end of all thinking about attributes and identity.   Ask LDAP guru Mark Wahl, or Bob “RL” Morgan or Keith Hazelton – people deeply involved in Kerberos and LDAP but just as willing to embrace new technologies like SAML as meeting new use cases.

Just as SAML broke new ground, WS-Federation is intended to address a number of things that people working in Web Services want better defined to facilitate interoperation using WS-Security and WS-Trust. 

These protocols hadn't even been invented when SAML evolved.  The idea of claims transformation is the most important technical advance in distributed computing for at least a decade.  It is so powerful that it wasn't even fully understood until we began to build things with it.  So how can anyone expect SAML to deal in an optimal way with the issues that ultimately emerged?  This doesn't detract from SAML's successes.  That's not how software engineering works.

WS-Federation will provide new options for people who want to build on the web services architecture, evolving their current web technology in an incremental way to be consistent with that architecture.  To do this, no one will have to throw out their existing SAML deployments.  Many of the SAML producers will include support for WS-Federation so that interconnectivity will be a given.

A lot of WS-Federation editorial work has been done by my friend DES (Don Schmidt).  This guy has paid his dues – triple dues – and works from a deep experience in security.  After some badgering he has just started to blog his ideas.  Here's part of how he explains his goals: 

WS-Federation enables development and deployment of advanced federation services (e.g. Authentication, Authorization, Attribute and Pseudonym Services) as special purpose variations of the WS-Trust STS claim transformation model.  Managing, discovering and accessing such services can be simplified when they are all based on a common processing model and speak the same protocol. Further, reusing an established processing model and protocol can simplify the threat model for implementers and should lead to more robust code.

Customers have indicated that manually configuring federation trusts – particularly exchanging signing keys and specifying service endpoints and access policies – is an onerous process when they have many partners. WS-Federation defines a Federation Metadata format to identify services, including the communication and security policies which must be satisfied for accessing them. This enables much of the configuration to be automated.

Another significant benefit of WS-Federation is improved security through “automated de-provisioning” of external user access. If a Relying Party issues local accounts for external users from its partners, it may not immediately learn when those users have changed responsibilities or been terminated. Such accounts could be misused to obtain unauthorized access. WS-Federation enables a Federated Identity relationship wherein a user can no longer access a partner’s resources as soon as he is unable to obtain a valid security token from his own organization.

Microsoft is actually pretty typical of many other companies in that it will have to support a whole spectrum of deployments reaching from simple, restful apps at one end to transactionally guranteed high security applications at the other.  The ability to support the whole spectrum consistently is the key.

We don't want to build two parallel infrastructures in order to do this.  We don't want to deploy everything twice.  Test everything twice.  Secure everything twice.   Does anyone? 

So we need a technology that takes everything learned while elaborating SAML – plus new features – and allows them to be composed and managed within the WS framework as well as used in conventional web sites. That's what I understand this TC to be about.

It remains a personal hope that those who have been involved with SAML will adopt this larger goal as part of what needs to be achieved.  That really will make convergence possible.

And I also expect everyone to give them credit for all they have done, which will not be lost if WS-Federation continues to gain momentum, but will rather be extended.

Information Card Contest

I was still reeling from the latest chicken pictures posted by James McGovern when I stumbled onto news of a contest put together by my colleague Richard Turner. 

James was complaining that the contest would slow down adoption in his case since it would break corporate policy to accept a prize.  I added a comment to his blog saying I would try to figure out a way that someone who could not accept the prize could make a charitable donation instead. 

But I didn't know what the prizes were until I read the original posting by Richard:

Identifying yourself online is becoming increasingly difficult and dangerous. Most people who use the web have to maintain several usernames and passwords and have to remember which usernames and passwords to use at the various sites they use.

While usernames and passwords are a growing frustration to most users, this problem is dwarfed by the growing threat of phishing and other forms of malware and identity-related attack.

Follow the wrong link and try to sign-in to a malicious site masquerading as, for example, your bank, and you run the very real risk of suffering considerable loss. These potential losses may be financial but may also impact your reputation (e.g. credit score) that may take years to repair.

Microsoft, along with many partners in the IT Industry, is building a suite of technologies to help combat the phishing issue, whilst making it easier for users to authenticate safely online. Technologies such as Windows CardSpace enable users to identify themselves by presenting cryptographically strong identity tokens (represented visually as information cards) to supporting websites.

To help fuel the growth of sites supporting Information Cards, Microsoft is announcing a competition that is open to every website owner, regardless of your web platform of choice. We hope you'll join us in helping to protect your user's identities from abuse and make it easier for your users to sign-in to your sites! 

How to enter

  • Add sign-up and sign-in support for Windows CardSpace to your website
  • Email the following to identity@microsoft.com
    • Details of your site
    • Your details
    • Complete this statement: “We added support for information cards to our site because …”
  • All entries will be judged by the CardSpace product team and winners announced on August 17, 2007. The winner will be notified by email.

The prizes

  • Grand Prize:
    • 1 Round-trip ticket (from and to a single location within the United States)
    • Overnight accommodation in a hotel near Microsoft Campus
    • Meet the team – spend a day with various members of Microsoft's Federated Identity team
    • Dinner with Kim Cameron
  • Second prize:
    • XBox 360 Elite Games Console
  • Third prize:
    • Zune music player

[Please note that due to international gaming laws we are only able to offer these prizes to US Residents and that any taxes incurred from receiving a prize is the sole responsibility of the prize winner(s).]

Adding support for Windows CardSpace to your site

  • The following resources will be indispensible in guiding you how to add support to your website:
  • If you have technical issues, please post questions to the Windows CardSpace discussion forum on MSDN – we'll be monitoring this forum closely and responding as quickly as we can. Note – if you contact us directly with support requests and your request is generic in nature, we'll ask you to post your question to the forum. This is the help others who may be experiencing the same issue as you and so that we can better manage potential support issues.

Anyway, that sounds like a lot of fun, and I'll make sure the winner gets a really incredible evening at one of the top restaurants in the region. 

And as for James, now I know what the prize is, if he wins we can just make it a working dinner at the local pub, taking on the role of Information Cards in the enterprise environment and all the other things I'd like to discuss with him from a purely business point of view.

RunAsRadio does CardSpace

Dana Epp runs SilverStr blog and is a security pro with passion and a real handle on CardSpace and Information Cards.  Richard Campbell and Greg Hughs have the new radio blog called RunAsRadio.  The trio come through as likeable and relevant in the podcast Dana describes here:

Recently I was interviewed by Richard Campbell and Greg Hughs on RunAsRadio. You might have heard of Richard… he's also the host of .Net Rocks!. Where .NET Rocks! is for developers, RunAsRadio is for IT Pros.

Anyways, if you would like to listen to the interview we did on CardSpace, you can download it here. Its about a half hour long, and is a simple introduction to the world of Cardspace, atleast for the client side perspective.

For those already versed in the subject, you will notice a few term definition problems in the interview. It went by so fast, and I didn't make it clear what I was getting at. For those that don't know, here is a primer that may help understand how I talk about digital identity:

  • InfoCard : An information card. The previous code name for Cardspace [but now the name of the underlying technology – Kim]
  • Identity Card: Generic term to mean a piece of digital information that represents your identity [definition not recommended – Kim]
  • Identity Provider: As the name implies, a provider of one's digital identity.
  • Relying Party: A system/application that relies on a digital identity for authentication, and possibly authorization. It is up to this party to decide which Identity Provider(s) it is willing to trust. ie: Web site, LOB app etc
  • Claim: An assertion of a piece of information belonging to an identity. ie: username, password, age, phone number etc.
  • Wallet: A piece of software that holds Identity Cards. Vista ships with a wallet that holds Information Cards. You can also download it for XP.

In a couple of places I used the term “credential” where I was really talking about “claims”. And in passing it may sound like I was saying its the Identity Providers (IdP) role to decide who to trust. That didn't come out right. It is up to the relying party to decide which IdP it wishes to trust. In some cases, it will trust you, because you act as the provider. How? Because when you create a a self-issued card and submit it, you are asserting you are who you say you are. It won't be as trusted as much as say… a government IdP. But you get the point. I hope Kim doesn't think about throwing a brick at my head if he hears the interview 🙂 [I love the interview – no brick – Kim]

Anyways, fun interview. Richard and Greg have asked me to come back and do another one where we can explore the server side of things… and discuss how Relying Parties and Identity Providers really work. We may even get into some discussion about Longhorn server and some of the interesting bits there that can be leveraged for the new digital identity ecosystem. Until then… enjoy!

Actually, Dana is remarkably precise while still being interesting.  He has made even the hardest leap – separating credentials from claims cleanly enough that he catches himself when at one point he starts to slip.

In the interview Dana says “InfoCards”, and uses the word properly – to refer to the the technology we are working on across the industry.  “Windows CardSpace”, on the other hand, is the name of the Microsoft implementation of this technology. 

I take full responsibility for confusing everyone in this regard – and apologize to Dana and all my readers – because early in the product cycle I conflated our proposed technology ideas and our Microsoft implementation.  Over time we've become very crisp about our usage.  CardSpace is the way we store Information Cards on Windows; people abbreviate Information Cards into “InfoCards”. 

I do not use and do not like the phrase “Identity Cards” when talking about digital identity. 

“Identity Cards” conjure up government-issued citizen identities.  While  government cards are a legitimate notion when interacting with government sites, we don't want to imply that government-issued identities should be used everywhere or for everything!  People need to be able to assert different identities and decide which ones they want to pull out of their “wallets” – just as they do in the physical world.

But I nit-pick.  If you want to learn about CardSpace and Information Cards, check out this interview.

CardSpace and OpenSSO

The Sun Developer Network has published an article by Martin Gee entitled Securing Site Access with CardSpace and OpenSSO:

With today's ever-increasing demands for robust security software and systems, alternative authentication and trust mechanisms are gaining popularity. In particular, the user name-password authentication model is typically the root cause of many security frauds. Why? First, many of us record passwords somewhere, rendering them vulnerable for snooping. Second, our tendency to create passwords that are easy to remember makes them easy to be guessed or detected. Consequently, enterprises that have established processes along that model are looking for ways to better safeguard and optimize their systems without major overhauls.

Enter Windows CardSpace (henceforth, CardSpace), a Microsoft-led specification that has been gaining recognition over the past months. CardSpace defines a simplified paradigm that employs a security token called InfoCard for managing digital credentials and is available in Windows XP and Vista.

OpenSSO is Sun's open Web access management project based on Sun Java System Access Manager source code. As part of the open-source Project CardSpace on java.net, ICSynergy has extended OpenSSO to include CardSpace as a simple authentication module. In addition, ICSynergy offers a commercial CardSpace implementation for OpenSSO and Sun Java System Access Manager along with training programs.

This article describes the benefits, basic architecture, and process flow of the CardSpace-OpenSSO authentication module.

It is good to see things coming together across the “crevasses” that used to separate different industry forces.  If you do Java you should look at the Project CardSpace site.

Token Decryption Service for CardSpace

Via Richard Turner's blog, the announcement of an architecturally superior  token decryption component devised by Dominick Baier at leastprivilege.com. 

Dominick  and Richard have blogged previously about mitigating the dangers involved in allowing web middleware and front-end software to process encrypted payloads.  Decrypting a payload involves access to a private key.  The broader the range of applications that can get to the key, the greater the attack surface.  This led to discussions about:

  1. Re-factoring the token decryption code into an assembly that runs under full trust whilst the site runs under partial trust
  2. Building a Token Decryption Service to which you can pass your encrypted blob and you get back a list of claims, PPID and issuer key.

And that is exactly the problem Dominick has tackled:

Web Applications that want to decrypt CardSpace tokens need read access to the SSL private key. But you would increase your attack surface tremendously if you directly grant this access to the worker process account of your application. I wrote about this in more detail here and Richard Turner followed up here.

Together with my colleagues at Thinktecture (thanks Christian and Buddhike for code reviewing and QA) I wrote an out-of-proc token decryption service that allows decrypting tokens without having to have direct access to the private key in the application, the idea is as follows:

Your web application runs under its normal least privilege account with no read access to the private key. The token decryption service runs as an NT service on the same machine under an account that has read access. Whenever the application has to decrypt a token, it hands the encrypted token to the token decryption service which (in this version) simply uses the TokenProcessor to return a list of claims, a unique ID and the issuer key.

The token decryption service is implemented as a WCF service that uses named pipes to communicate with the applications. To make sure that only authorized applications can call into the service, the application(s) have to be member of a special Windows group called “TokenDecryptionUsers” (can be changed in configuration to support multiple decryption services on the same machine). I also wrote a shim for the WCF client proxy that allows using this service from partially trusted web applications.

The download contains binaries, installation instructions and the full source code. I hope this helps CardSpace adopters to improve the security of their applications and servers. If you have any comments or questions – feel free to contact me.

The approach is a good example of the “alligators and snakes” approach I discussed here recently.