Significant profiling of SAML should be unnecessary because the Shibboleth software already provides sufficient coverage of the options that might come up. The ECP client role does not impose significant implementation costs, so it should be adoptable in full.
ID-WSF, on the other hand, is a much more complex set of specifications with many options and advanced features. For our purposes, we will profile this down severely in the initial stages. We can admit new options as they become needed.
We propose the following:
- Disallow all optional ID-WSF SOAP Binding header blocks, leaving only the minimal required set to be compliant.
- As a consequence, the IdP will not maintain state with proxying services (though it might maintain state with the proxied-to services for logout purposes).
- Support only the
urn:liberty:security:2006-08:ClientTLS:peerSAMLV2and theurn:liberty:security:2005-02:TLS:Bearersecurity mechanisms for authentication of services to the IdP. This avoids a requirement for complex signature creation on the part of the ECP client, and allows for either bearer or holder-of-key authentication via a SAML assertion.- Should message signing be a desirable approach, the
urn:liberty:security:2006-08:TLS:SAMLV2mechanism can be implemented, but this will require profiling WS-Security sufficiently to keep the work manageable.
- Should message signing be a desirable approach, the
- Require that the EndpointReference information for the IdP's SSOS signal either that no security token is required (unlikely), or that the enclosing assertion in which the EndpointReference appears is to be used. Embedding additional tokens or referencing other external tokens will not be supported.