[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Comment on SAML implementations and their inter-op properties
A few additional thoughts, from the perspective of working on conformance for SAML 1.0 as well as working with customers on SAML-based solutions. Like Eve, I welcome Daniel Blum's open letter as interesting and timely. Particularly important is his recognition that "customers lack a high level of confidence that they will be able to get their SAML implementations to interoperate seamlessly with partner implementations" and the implicit concern that this limits acceptance and implementation of SAML-based solutions. All five of the suggestions Daniel makes for addressing this problem (his points #1 and #2 each contain two distinct though related suggestions) are certainly worth considering. 1) Test harness and/or reference implementation. During the SAML 1.0 process, the Conformance subcommittee had a number of discussions about the creation and support of test suites, including setting up a formal or informal certification program by a group such as NIST. That no vendor or third-party stepped forward to sponsor a publicly-available test suite reflected both the commitment of resources required and the newness of the spec. But I would fully expect the door to be open for anyone interested in contributing to or driving such an effort. 2) Interoperability testing. (point #1, last sentence). The SAML committee continues to sponsor interoperability events, very often with the support of Burton Group; the next such event is, I believe, targetted for early CY2004. We might be able to use these events to address the issue of customer confidence by publicizing the event both beforehand and afterwards, and by describing for industry publications the scenarios that are tested. 3) Test harness support browser artifact SSO profile. This is certainly a reasonable place to start; I'm assuming that the intent is to make this as minimal a set of functionality as possible (for example, no attribute statements in the assertion). 4) Mandatory use case. We discussed this question a lot during SAML 1.0, and decided that making any particular use case mandatory was inappropriate, given the range of solutions that SAML could address. What was important, we felt, was to specify what needed to be implemented by a vendor claiming conformance to a profile or protocol binding. That still seems to me the right approach, though finding a simpler way to identify what parts of SAML a given vendor supports would be a good idea. 5) Customer information. This feels to me like a much larger issue than a "SAML cookbook". This level of customer assistance is an area where groups like Burton have in the past provided significant value and in which many vendors published white papers. However, I'd be very glad to work with Eve, John and Daniel on seeing what is currently available and what should be added. Early in the discussions of conformance, we distinguished between the two related but distinct questions of conformance to spec and interoperability among implementations. Although conformance to spec is a necessary precondition to interoperability, it is not sufficient: even in a single-vendor implementation of cross-domain sign-on, for example, the details of the contract between parties determines whether requests, responses and assertions are mutually understandable. Even though strides can certainly be made in increasing customer confidence in SAML interoperability, we should also encourage customers to be realistic about the work required to understand fully the relationships among parties in a SAML solution. Bob Griffin -----Original Message----- From: Eve L. Maler [mailto:eve.maler@sun.com] Sent: Monday, November 10, 2003 1:58 PM To: 'security-services@lists.oasis-open.org' Subject: Re: [security-services] Comment on SAML implementations and their inter-op properties Interesting and timely feedback. The issue of working on a test suite came up in the September meeting, but we didn't get very far with it. Perhaps we should see if Daniel Blum's exhortation makes it more attractive for some SAML participants to take on this resource-intensive task. At the least, should we be planning additional interop events for various scenarios? Regarding having a a "must-implement profile": This seems a little weird to me if you look at the entire range of possible and existing profiles, though if we couched it in terms like "*If you're doing SSO*, you must support XYZ profile" it would make more sense. We discussed this idea very early on; maybe it's time to revisit it. Regarding "cookbook" material, we are indeed creating more outreach materials, including executive and technical overviews and the FAQ. Maybe we (John Hughes and I?) should contact Daniel about this and offer the opportunity to review and make suggestions. Eve Mishra, Prateek wrote: > http://burtongroup.com/weblogs/danielblum/ > > - prateek > > Prateek Mishra > Director, Tech&Arch > Netegrity > > p: 781-530-6564 > c: 617-875-4970 -- Eve Maler +1 781 442 3190 Sun Microsystems cell +1 781 354 9441 Web Products, Technologies, and Standards eve.maler @ sun.com To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave _workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]