There are several bedrock relationships. Shortly after the Shibboleth project was conceived in spring of 2000, the OASIS working group for SAML was formed with founders that included the Shibboleth core developers. The Shibboleth work was then structured so that the basic requirements in Shibboleth for XML and protocols that were shared by the OASIS activity was done there as part of the SAML spec. (Three of the seven authors of the SAML 1.0 spec were principals in Shibboleth.) That synergy is even more pronounced in the SAML 2.0 standard, where the technical editor of that specification is Scott Cantor of Ohio State, who is also the lead Shibboleth architect. SAML 2.0 represents the convergence of the OASIS specs, much of the Shibboleth system, and the Liberty Alliance ID-FF specifications.
The Shibboleth and SAML design processes have been coupled to insure that Shibboleth is standards-based. Because of this design, on a software level, a major part of the Shibboleth system is the OpenSAML libraries, which are also widely used. OpenSAML is at the core; Shibboleth software adds a set of components to augment that capability into a federating system that meets the needs of the R&E community. Both the OpenSAML libraries and the Shibboleth software are developed by the Shibboleth team and released as open source.
The primary function of the Shibboleth system is to support identity federation between multiple sites using the SAML protocol standard. Shibboleth's added value lies in support for privacy, business process improvement via user attributes, extensive policy controls, and large-scale federation support via metadata. Hence Shibboleth accommodates richer and more complex metadata distributed by a federated operator; it has more refined capabilities for managing trust implicit in larger communities; it allows users and enterprises to manage attribute releases, reflecting the greater number and variety of participants. Shibboleth is being developed by a highly-involved open source community.
Microsoft recognizes the complementary nature of Shibboleth with Microsoft approaches and supported the development of WS-Federation capabilities into Shibboleth software. In the future it may support additional specifications such as the WS-Trust protocol used by Microsoft's CardSpace.
Shibboleth is fastidiously SAML-compatible in protocol interactions, to support maximum interoperability. Past interoperability has been demonstrated with Shibboleth 1.3 and SAML 1.x WebSSO products, and has been certified in the federal interoperability labs for use with EAuthentication. 2.0 support should be better, given the use of fewer extensions. Basically, Shibboleth 2.0 will be an implementation of the SAML 2.0 Web SSO and attribute exchange profiles and will interoperate with other SAML 2.0 products at least as well as anything commercial does. Some SAML 2.0 products may need to enhance themselves in their support of complex federations to be fully Shibboleth compatible; Shibboleth compatibility is increasingly included in commercial products.
