The long-awaited (at least if you’re Swedish and interested in public sector IT which does rather limit the audience a bit) e-delegationen report was released today. The section on national identity solutions says “SAML” and “federations” over and over.
On the whole the report promises a significant improvement over todays proprietary solutions. There is still lots of work left to do in order to realize these ideas. Those of us who have worked in identity space for a while know that there are plenty of opportunities to shoot oneself in the foot even if you have the right shoes on.
For reasons that escape me Sweden has a bit of a track record trying to “roll your own” in areas where there are plenty of existing standards and market direction, but this time I do believe e-delegationen is betting on the right horse. Good work!
Paul Madsen twittered this networworld article about what i guess must be one of the first public appearances of the EU Stork project.
Kim Cameron and MSFT seem to be shopping InfoCard and Geneva all over the place these days so their comments about Stork shouldn’t be surprising to anyone. The article claims that InfoCard has seen solid industry uptake which may be true but according to the recent Concordia Survey on Federated Identity InfoCard has a very small deployed base.
Nevertheless I think it reasonable to think that InfoCard will get deployed more, even in the R&E community where federated identity is already a Big Thing (TM).
InfoCard shares important infrastructure with SAML making it fairly easy to deploy alongside SAML (even though the semantics and user experience of SAML WebSSO and InfoCard differ quite a bit), namely SAML metadata which, when deployed “the right way” becomes the primary trust fabric of an identity federation. Microsofts Geneva was apparently designed around the same principles of how SAML metadata should be used as is fast becoming best practice among R&E identity federations.
So we learn that STORK will consider SAML 2.0 and holder-of-key as the primary way to interface national eID solutions in the European countries. I really hope they understand that the devil is in the details and design metadata management and trust fabric management in a sensible way.
One can only wonder what lies behind Microsoft pushing Geneva all over the place. Typically Microsoft aren’t happy just following where others lead. Perhaps the idea is to include the U-Prove technology they bought with Credentia last year in Geneva and embrace and extend the identity federation framework…
Then again once you can see the threat it is suddenly less of a threat. The famous embrace and extend tactic is precisely that: famous. People who are interested in open standards and open implementations should recognize where the ball is being played and start to think about how to implement U-prove.
Andrew Cormack of ja.net talked at the REFEDS meeting today about recent work they have done on standardizing interfederation agreements. One interesting announcement was that they’ve picked up my old idea of associating a license with federation metadata. They ran this by a set of lawyers who basically said: “don’t call it a license, call it terms-of-use and you’re fine”.
This has the potential of simplifying federation operations (including federation peering) significantly since service-providers don’t have to be tied to federations by legal agreements. For multi-federation service-providers like Microsoft Dreamspark or Elsevier this is good news since they may in time get away from having to sign agreements with every federation on the planet.
While this may seem like a bad idea for federations whose business was driven by being able to charge SPs for inclusion in metadata in the long run everyone benefits from the identity business growing with the removal of a major obstacle.
I’ll admit that X.509 certs aren’t the most hot topic in the world these days but they do rear their ugly little heads now and again. Most recently I’ve been involved with the people working on deploying the new Terena Certificate Service (TCS). The TCS is a follow-up of SCS – a pan-European flat-rate certificate service negotiated by Terena. The second round of procurement got us a sweet deal with Comodo which includes unlimited flat-rate user, code and server certificates (!)
Reading Andreas excellent post on adding support for OAuth in simpleSAMLphp and talking to Thomas Zangerl at NDGF who is helping Henrik Austad of UNINETT work on the confusa CA server we’ll use for the emai/GRID certificate part of TCS, we realized that OAuth could also be used in conjunction with Java WebStart to provide secure key generation and enrollment for confusa. Here is a rough outline:
The CA web interface is a federated application – in our case using the Browser Web SSO SAML 2 profile implemented in simpleSAMLphp. Today confusa allows the user to login via one of the trusted IdPs and then upload a PKCS#10 certification request in a form. This CSR is combined with attributes provided by the IdP to provision the certificate.
This works but doesn’t provide a very nice user experience. Instead we could launch a Java WebStart application or applet which does key generation on the client and submits the CSR to the CA server. This approach has been implemented by others. The problem is how to authenticate the CSR and tie it to the authenticated user attributes. A session identifier could be used but would typically need lots of tweaking to be sufficiently time-limited and secure.
If we try to apply OAuth to this situation and view the established session as a protected resource that the user grants access to for the purpose of binding a public key to it we get the following translation of OAuth concepts:
- Consumer: The Java WebStart application
- Service Provider: The CA application (confusa in our case)
- User: The user requesting a certificate.
- Protected Resource: The established session at the web applicaiton containing the user attributes.
Since the User has already logged in an authorized the request and is provisioned with a consumer key and a pre-authorized request token as part of the launch JNLP file. At this point the JWS application can obtain an access token and use it to associate the CSR with the established session using a PUT request.
I’ll be the first to admit that this is a corner-case – the request-token is authorized before any OAuth protocol flows are initiated but nevertheless it shows that OAuth is a very nice idea adaptable to many situations.
We will look deeper into the security implications of this and this process is expected to get lots of scrutiny by the GridPMA when we submit the TCS Grid CPS to the EuroGRID PMA for review so the jury is still out on weather this gets deployed or not! Stay tuned.
