Category Archives: MS/AD/InfoCards/CardSpace

CardSpace *OR* ADFS 2.0

Posted on by

Microsoft announced last Tuesday that CardSpace 2.0 beta would not be releasing at the same time as ADFS 2.0.  That fact may not have immediate significance to you, but it certainly does to me.  Microsoft, you’ve blown it.

On one hand, I’m immensely relieved. A premature release of CardSpace 2.0 would have removed personal card support from the desktop, meaning that CardSpace would have been relegated to nothing more than Home Realm discovery.

On the other hand…  We won’t know for sure until ADFS 2.0 ships, but from what I and other people have seen from the beta and release candidate versions, Microsoft has broken backward compatibility with CardSpace 1.0.  This means that unless Microsoft has taken recent steps to regress their information card issuance code, ADFS 2.0 will ship in information card limbo.

I am trying not to care and failing miserably.   Let’s face it, Microsoft can release their software in whatever shape they see fit.  If they want to, they can release an initial version of a client with no server, and then release a version of the server *years* later that can’t work with the initial client, and can’t be deployed with the later client because that later client “isn’t done yet”.  I’m sure that the collateral damage is the least of their problems, and I actually know and understand better than most what internal and external pressures may have been brought to bear.   Resources are precious, and both FIM and ADFS have slipped themselves, so somebody had to draw a line.

But see, people were waiting.  Big companies, waiting to run information card pilots.  Governments, excited to use ADFS 2.0 to implement higher-assurance consumer identity projects.  There weren’t a huge number of interested parties, but dammit, they were BIG interested parties.  Those interested parties need a sustainable closed circle — a production server and a production client.   Not a production server that can only work with a client that “isn’t done yet”.

In the meantime, there is a very hardy little information card community that can at least now stop the horrible waiting and wondering game with respect to ADFS 2.0 and CardSpace 2.0.  The choice for the immediate future is becoming clear:  CardSpace 1.0 remains the defacto standard for information cards.  The rest is moot. Regardless of the hole that Microsoft may have dug for itself,  the quality and uniqueness of the interactions that the IMI spec makes possible are undeniable, and I hope inevitable in some variant. I continue to believe that this protocol represents our best hope to regain rational control over our own digital relationships.

It is entirely possible that companies like Azigo and Avoco Secure will see the silver lining here and do the extra work to shim up the ADFS server to work again with the rest of our ecosystem.  We’re not out for the count, and at least now we finally know what the biggest player in our space plans, even if it is a big fat WTF…

My Case is MADE

Posted on by

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.

Relying Party Card Identifiers

Posted on by

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.

Which Selector will ship with Windows 7?

Posted on by

WindowsSomehow, 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

Azigo A-go-goes

Posted on by

I’ve finally had a chance to use Parity’s Azigo Identity Selector, and I have to say I’m impressed.

Pretty huh?

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:

  • Easy, beautiful installation script — Azigo is actually a really complex beast, right now there are several parts that have to be downloaded and configured, but the install script takes care of everything.
  • Pretty prettiness — The design is beautiful, it is a joy to see the fonts and colors and rounded spaces.
  • BEST PART:  there is a simple mechanism to group and organize cards according to function.   This is a feature I’ve been dying for for YEARS.  I can now finally separate my OSIS interop cards from my PamelaWare Test Cards from my ICF & PamelaWare Admin cards from the cards I’m playing with at various IdPs.

Issues I found with Azigo:

  • It takes a bit to initially understand the relationship between Azigo in the browser and Azigo the desktop application.  It took only a tiny bit of exploration to get things straight in my mind, but that could be a problem for less adventurous souls.  I understand that the desktop application will be going away in the future anyway, so this is a short-term issue.
  • There is a checkbox when you send a card to a site that asks if you want to just automatically send that card every time that site asks for a card – but there is no persistence to that checkbox, it defaults to automatic submission every time you use the card.   It drives me nuts to have to remember to click that checkbox every time.  I’m assured that this checkbox will become persistent in the future.
  • I found a few other bugs – which isn’t surprising, it just shows that Azigo will improve as people use the application in situations beyond initial testing parameters.  The friendly identifier didn’t correspond to that of the RP, and I had trouble uploading a card image.  Both of these have been reproduced now, and are on their way to being fixed.
  • As a feature request, I am excited to see what the Azigo folks can do with card audit data.  I can’t find any card usage/history data at this point, but hopefully it is coming.

Things I wonder about Azigo

  • I worry about the fact that the cardstore itself is protected by a username & password.  By putting the cardstore in the cloud, we end up having to protect the protection mechanism, and the one that we can’t use to do that are information cards…
  • I wonder if Azigo would license the code to people so that they could run their own cardstores?  I think there could be interesting possibilities in the Enterprise for something like this, perhaps you could do something wacky like combining existing privilege management products with Azigo.  In that case, a short-term user that you don’t want to provision an account to could get limited access to a cardstore containing an elevated privilege card.  This might be useful in the case for a real-life example where a given vendor has a rotating stack of 12 or more auditors, and you wish not to have to provision an account for this revolving door of people, but you want to retain contractual obligations and historical audit.
  • Because this service is available anywhere, it would theoretically be a juicy target for remote attack.  I would love to eventually see user-configurable additional security features in the case where the cardstore is accessed from new IP addresses or countries, or in the case where some threshold of acceptable authentications were exceeded.   I know this is advanced, but I think it would improve confidence in the security of the cardstore.

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.

Fun with Claims Games

Posted on by

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:

  1. Create a set of “role” claim names:
    • http://library.com/role_claims/system_admin
    • http://library.com/role_claims/book_borrower
  2. Create a set of  “action” claim names:
    • http://library.com/action_claims/has_library_role
    • http://library.com/action_claims/does_not_have_library_role
  3. In your RP trigger object, ask for actions as required claims, and specific roles as optional claims, for example:
    • Required:  has_library_role
    • Optional:   system_admin
  4. The Identity Provider evaluates the actions against each of the specified role claims, and returns the applicable roles as the values for each action.
    • In the example above,  the value returned for has_library_role could contain the string: system_admin, communicating that the user does indeed possess the role.
    • A more complicated action might be “has_all_roles” where three role claims are optionally specified, and the return value of the action claim is TRUE only if the user possesses all three of the specified role claims.

Here’s what I like about this scheme:

  • The RP can always expect a definitive answer for the action claim.
  • Minimal data is transmitted.
  • Only the action claims would determine card selection at the beginning of the transaction.
  • The IdP can control the context of what is returned.
    • It could evaluate the requested roles to be sure the RP has the right to ask.
    • It could return something as simple as a role list, or something as complex as an XACML statement.
  • Role claims can grow and change, while action claims can remain static (this is important for managed cards, since IIRC additions to required claims offered would result in users having to download a new version of the managed card template, not something you want to happen often).
  • Action claims can represent very complex and specific logic if need be.

What do you think Andy?   Could it work?

Just got off the Schemas WG Call

Posted on by

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:

  • What are the expectations of the “Display Claim” versus the actual claim in providing human-readable claim values?  Is it reasonable (or even preferable) to define a claim value that is not human-readable and trust that the STS will be responsible for mapping that value to something useful?
  • Is it expected that the selector will do a metadata discovery on each and every claim passed?  I had never even thought of such a thing, so will have to learn more.

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.

We MUST get this Right

Posted on by

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:

  • 0
  • 1
  • 2

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

Playing with CardSpace Geneva Beta

Posted on by

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:

  • Visually, I worry that the card tile feature lacks a strong enough branding consistency for people to easily identify where on a given page the information card trigger form is — if, for example, I happen to use a card which blends into the page, it might be confusing.  Even with the example site,  it isn’t immediately obvious that the picture placed front and center is also intended to be a control.
  • Along that same line, I wonder how much control the web designer has over the size, style, and placement of the card tile.  Is there a standard form factor or is the sky the limit?
  • I hope that a card provider could also have the power to disallow the “always use” feature for certain types of cards.
  • Will there be some kind of maximum limit to how long that little checkbox lasts?
  • Currently the beta card service and RP service appear to be a closed circle – I’m very excited to see the beta get to the point where I can start to play with these features using my own code base.

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

  • If you play with this beta,  remember YOU NEED TO GET THE CARD FIRST, as it is a managed card, and self-issued cards aren’t part of the beta yet.
  • If you aren’t seeing the card tile, check Mike’s blog entry above for a link that explicitly asks for that feature.
  • When you click on the card link to import the card,  nothing happens; the card installs, but the selector doesn’t open or even give you a popup.  I’m not sure if this is by design, or if the acknowledgement of successful install just hasn’t been put in yet — but I hope it is the latter, because without some kind of feedback, people like me assume that it either didn’t work or that it is still running and that I therefore have to wait.  I only discovered that my work was done when I clicked the link a second time & was asked if I really wanted to install a dupe.