The following are technical specifications that are supported/implemented in part or in full by various Shibboleth products.
You can find a highly unofficial statement here about FIPS compliance.
The formal specifications that define how Shibboleth works span a number of documents. Shibboleth is primarily built on the Security Assertion Markup Language (SAML) standard as defined by the OASIS SSTC. Shibboleth also has formal profile and conformance documents that define additional constraints on top of the base standard.
Specification for SAML V1.1, an OASIS Standard. Describes SAML V1.1 assertions, protocols, bindings, and profiles.
Specification for Metadata Profile for the OASIS Security Assertion Markup Language (SAML) V1.x, an OASIS Standard. Describes a SAML V2.0 metadata profile for describing SAML V1.x entities.
Specification for SAML V2.0, an OASIS Standard. Describes SAML V2.0 assertions, protocols, bindings, profiles, metadata, and authentication context.
Specification for Identity Provider Discovery Service Protocol and Profile, an OASIS Committee Spec. Describes a protocol and profile for identity provider discovery.
This document defines a <saml:Condition> type for expressing a chain of intermediaries acting on behalf of the subject of an assertion, requring relying parties to distinguish between direct and indirect access.
This profile defines an extension element for use in attaching SAML attributes to an <md:EntityDescriptor> or <md:EntitiesDescriptor> element, to communicate an arbitrary set of additional information about an entity in its metadata.
An OASIS Standard. This profile describes a set of rules for SAML metadata producers and consumers to follow such that federated relationships can be interoperably provisioned, and controlled at runtime in a secure, understandable, and self-contained fashion.
This specification defines a SAML HTTP protocol binding, specifically using the HTTP POST method, and not using XML Digital Signature for SAML message data origination authentication. Rather, a “sign the BLOB” technique is employed wherein a conveyed SAML message is treated as a simple octet string if it is signed. Conveyed SAML assertions may be individually signed using XMLdsig. Security is optional in this binding. This specification is an addition to the bindings described in the SAML V2.0 Bindings specification.
SAML Metadata extension that allow an entity to describe which signature and encryption algorithms are supported
An OASIS Standard. This document defines a set of extensions to SAML metadata that provide information necessary for user agents to present effective user interfaces and, in the case of identity provider discovery, recommend appropriate choices to the user.
|This document defines a set of extensions to SAML metadata that provide information about the creation and intended usage of the metadata document and information about who and how particular entities were registered.|
This specification defines an extension to the SAML V2.0 protocol specification. The extension allows Service Providers to specify ad-hoc sets of attributes per request. This brings more flexibility than existing mechanisms, which are based on signaling pre-defined sets of requested attributes.
Describes Shibboleth-specific extensions to SAML V1.x. The primary extension specifies an SP-first authentication request.
Describes conformance standards for the Shibboleth Protocol Specification
|SAML V2.0 Implementation Profile for Federation Interoperability Version 1.1|
This document encompasses a set of software conformance requirements intended to facilitate interoperability within the context of full mesh identity federations, such as those found in the research and education sector. It attempts to address a number of common barriers to interoperability and details features that are necessary in order to use SAML metadata as a foundation for scalable trust fabrics.
Deployment Profiles, Best Practices, Etc:
In addition to these standards, note that within specific communities of use, additional profiles may be defined to further constrain options, define attributes, etc. People are welcome to maintain pointers to those here.
The Internet2 Middleware Initiative has published profiles for the use of SAML attributes (both SAML V1.x and SAML V2.0). These are best practices and naming standards used by at least InCommon and some other federations. Some of the practices described are implemented directly by Shibboleth 1.x, often in ways that don't permit other approaches.
A deployment profile of SAML 2 representing best practice for use of the standard and its most important extensions. Most other deployment models of SAML are considered deficient at best and outright insecure at worst by the Shibboleth Project team.
Additional documents of historical relevance to the project and our community.
|Shibboleth Architecture document||The last draft located of the original Shibboleth Architecture document that was created prior to constructing the original software. The software today looks much different than it did in the heads of the people who imagined it, but there are also a lot of ideas that survive after all this time.|