Monday, October 02, 2006

Ping Cardspace implementation oddity

I used Chuck Mortimore's Firefox extension to present a self-asserted card to Ping's IDP, which, after doing the Cardspace dance, displayed the following on the IDP portal page.



It's the 'PASSWORD' as authentication context that confuses me.

I didn't authenticate to the IDP with a password, I did so with Cardspace. More precisely, I authenticated to the IDP (acting as a Cardspace RP) by proving I had a key through an XML-Signature. So, strictly speaking, the appropriate SAML Authentication Context class should be 'XML Signature'.

A Cardspace user will sometimes be required to authenticate with a pin or similar to a local key store (and so it could be conceivable that there would be a password in the mix). In such cases, just saying 'XML Signature' wouldn't adequately describe the authentication context. The options would appear to be to use combinations of existing AC class URIs or define new SAML AC class defined specific to Cardspace.

Update: Patrick Harding reminded me that Cardspace uses SAML 1.1 so doesn't have the full expressiveness of SAML 2.0's Authentication Context available. The conjecture is that Ping's Ashish Jain, because of this lack of expressiveness, had to fall back on 'password'.

1 comment:

Ashish Jain said...

- From the CardSpace perspective, the site that you are accessing is 'RP'.
- In the scenario you are testing, your client is the IdP.
- Our managed IdP server (that one used at DIDW) hasn’t yet found a hosted place yet. I’m working on it.
- In case of self-issued cards, it’s the client that is responsible for generating the assertion (and hence populating the AuthnContext).
- CardSpace v1.0 supports SAML 1.1.
- SAML assertion created as a result of using a self issued card (MS Version – July CTP) doesn’t even have an AuthenticationStatement.
- In the managed Infocard scenario, the IdP server controls the SAML creation and can set the appropriate value for AuthenticationStatement->AuthenticationMethod. We currently default that to “Password”.
- I extended our PingFederate sample application (username/password) to demonstrate the chaining of CardSpace / Passive Federation. The word “Password” you see on the RP screen (using a self issued card) is a result of that (rather than any actual dynamic retrieval).