Concordia workshop RSA 2008 notes
From Project Concordia
Eve Maler of Sun Microsystems, Mike Jones of Microsoft, and Dr. Robert Haar of General Motors presented a Concordia update and elicited workshop attendee feedback. The slides are here: Media:Concordia-Apr2008-wiki.pdf
Check out the RSA IOP Scenarios page for details on what was interop-tested for this event. Also be sure to look at the followup activity in later meeting notes; the Concordia telecon 22 Apr 2008 notes in particular discuss the profile-spec activity that some in our community are kicking off as a next step. The full list of telecon notes, and instructions for joining the mailing list, are on the Main Page.
Thanks to all who participated!
Contents |
Summary of themes, memes, and next steps
Two themes seemed to be particularly effective in conveying Concordia's purpose.
- We noted that Concordia is focusing on conventions, not inventions. In the scenarios we presented, Mike pointed out that our only innovations were the InfoCard authentication descriptor strings and the agreement around the pairing of an expressed SP requirement and an IdP's description of what it did.
- We noted that Concordia primarily works on scenarios involving protocols that are used together, but weren't originally designed to be used together.
Based on feedback from Bob Haar and from the audience, the scenarios we selected for this interop event seemed to hit sweet spots that are of interest to deployers and users. A general desire was expressed for formal interop testing and formal profiling of the scenarios going forward.
Brief notes on the demo presentations
FuGen Solutions
Lena Kannappan and Vijay Simha presented. They explained a scenario for SAML2 step-up authentication.
Internet2
Scott Cantor presented. He noted that SAML is widely deployed. He commented that personal InfoCards aren't entirely suitable in his IT environment for security and mobility reasons, but it would be useful to do Shibboleth attribute release under people's personal control.
Two of the lessons he presented:
- Browser SSO generally works well by now.
- Profiles for assertion content are needed. (This was echoed by several others.)
Microsoft
Mike Jones and Caleb Baker presented. The IdP support they demoed here isn't shipping yet. SAML2 token support is coming in ADFS's next version. In response to a question, Mike said SAML2 token support is coming to Visual Studio too -- no dates yet.
Oracle
Ari Kermaier presented (and Damien Carru was also staffing the table at the back). Ari demoed Scenario 2. He noted that the custom authentication mechanism setup in his product is handy for configuring CardSpace. Key takeway:
- Specs are key; we need good profiles.
Ping Identity
Ashish Jain presented. He suggested that if you're already thinking about using InfoCard, today's scenarios show how you can extend your reach. He demoed Scenario 1a, minus the special authentication context agreement, connecting to a public-facing SAML endpoint run by that little company named Google. :-) (And got spontaneous applause!)
Sun Microsystems
Pat Patterson presented. He demoed InfoCard scenarios with no Microsoft software involved -- earning kudos from Mike! Pat's demos used shipping OpenSSO (open-source) code. He noted that SSOCircle is a public-facing SAML and OpenID IdP using OpenSSO.
Slides from Pat Patterson (Sun Microsystems): Media:PatConcordiaRSA0408.pdf
SymLabs
Sampo Kellomaki presented. He noted that he chose the HTTP POST binding but could have used artifact or any other binding. He noted that both SAML and InfoCard have the risk of a client-side Trojan horse, which can be mitigated if care is applied. He noted that the artifact binding in SAML is good for avoiding an MITM attack.
Interop observations:
- Deploying the APIs of vendors other than oneself is difficult!
- APIs that are redolent of SAML concepts aren't ideal.
New Zealand State Services Commission
Danny Mollan presented. NZ SSC has done some prototyping of a scenario that is close to Concordia's Scenario 1a; his slides were helpful for understanding this relationships. He noted that InfoCard is good stuff, but inconveniently, NZ had already standardized on SAML2 (using persistent pseudonyms and passing four attributes: name, sex, date of birth, and place of birth). Microsoft funded the integration effort. The NZ goal is for CardSpace to have zero impact on their SPs.
The prototype has been successful, but they're discovering some user experience problems. Danny mentioned several additional use cases of interest, which could perhaps be seen as Concordia fodder:
- InfoCard + Liberty ID-WSF for attribute services
- Identity selectors being able to pass through to another card elsewhere (would "managed card proxying" be a good name?)
Questions and answers
The morning included several question-and-answer sessions, led by Bob Haar.
Q (Bob Blakley): What is the integrity mechanism that hooks the two works together in scenario 1a? How to mitigate risks of packet surgery and MITM?
A (Mike Jones): Trust. :-) The same sorts of relationships that get built between IdP and RP in a SAML or WS-Fed exclusive scenario would also get built with the IdP/RP and the InfoCard STS. It's one more relationship but it adds no risk beyond what's already in the federation relationship.
Q (?): Is there a negotiation around authn methods, or do you just "FAIL" if you don't get the right kind?
A (Mike Jones): SAML and WS-Fed only provide request capability for the method you want, not extensive negotiation beyond that.
Q (Bob Haar): As moderator, he asked each of the interop participants the same set of questions: What's the magic sauce in your solution? What difficulties did you experience?
A: Most of the interop participants indicated that they mostly had to do configuration, not new development, to get the scenarios to work.
Q (?): Has concerns about federating risk.
A (Mike Jones): Cited an example from the automotive world.
A (Bob Haar): Federation gives more real-time control. The Legal/contractual aspect supports risk management. E.g., auditing requirements dictate a lot of those agreements.
Q (?): Is there such a thing as a WS-Fed/SAML toolkit?
A (Mike Jones): Microsoft has publicly committed already to supporting SAML2 tokens for the next major version of ADFS. Concordia has been valuable for Microsoft's testing process for this new support. They were able to sort out the differing implementation assumptions.
A (Eve Maler): Many products and open-source APIs support multiple protocols today; OpenSSO is an example.
Q (Mike Beach): Will Visual Studio add support for SAML2 tokens?
A (Mike Jones): Microsoft is working in that direction. No date commitments yet.
Q (?): What about applications acting on humans' behalf?
A (Eve Maler): Take a look at ID-WSF's Security Mechanisms spec for a model of how to represent the different actors, including such applications.
A (Mike Jones): There is a continuum between user-centric identity and classic federation. We need to evolve clients to work with SaaS models.
Q (?): What about biometric support?
A (Ari Kermaier): Oracle doesn't have an STS yet. Biometric authentication is an interesting idea to support.
Final discussion
Danny Mollan: In federated identity, you're trying to insulate your customers from change, and they're trying to do that for their customers too. We need to increase security and the reach of the solutions.
Brett: What's missing in today's solutions for solving the NZ CardSpace and ID-WSF scenario?
Danny: Only comprehensive agreement on the metadata to pass.
Bob Haar: Outsourcing is a complicated dance.
Danny: Yes - sometimes outsourcing (government <-> business) goes both ways. May need bilateral trust (business, not technical).
Bob H: There are compliance and regulatory issues.
?: How avoid agencies requiring attributes/claims beyond their remit?
Danny: We are managing agencies in groups of "privacy realms" -- pseudonymity across those boundaries. One of their challenges is a scenario where the Lotteries Commission, which sells scratch cards, might start having an age requirement (it doesn't now). How would they do this?
Mike B: The authn context stuff I saw today seems like it's not ready. When is Microsoft going to shore that piece up?
Mike J: It's the server side that's new; the CardSpace stuff we showed today has been available for a while.
Eve: The limitation of today's InfoCard protocol on having to decide based on claim types (not values) is an example of something not ready for prime time.
Ari: Yes, we implementors had to hijack the "required claims" mechanism feature and use it in a way not originally intended, and thus we were limited.
Bob H: Specs are not enough! Profiles are needed to close gaps and choose among options.
Brett: Liberty does interop testing. Would it be good to add testing scenarios for the stuff shown today?
All: Yes.
Eve: I heard several variations on the InfoCard+SAML theme today, including from Danny's preso.
Scott: Is the SSTC a good home for profiles?
Hal Lockhart (SSTC co-chair): Yes.
Lena: Next step should be to tighten the scenarios into profiles.
Ari: The bigger question: Who is the ultimate trust authority? E.g., if the STS is outsourced in these scenarios?
Mike J: Kim C. would ask, "Trust for what?" Context matters. Trust isn't binary.
Bob H: For that we'd need a system to manage the identities of IdPs!
Danny: Users want to see the IdP "brand" -- you can't mess with that too much.
Mike B: So what are the next steps for Concordia?
Eve: Heard profiling and interop testing of these scenarios.
Bob H: The work so far is good, but it isn't done yet!
