SAML Response signatures
SAML Response signature usage varies between SAML implementations as the usage of them and at which level is currently not particularly well-defined.
The SAML metadata exchange format allows marking the requirements/support for signed SAML assertion, but nothing for the SAML Response itself.
We will not go into details on the implication of those choices and when things are useful or not. What is important is to know how we behave, so you can configure your Service Providers accordingly.
Signature for catalog item not using metadata
For any item in the catalog not using metadata, we have a simple approach where only the SAML Response is signed by default, and we change these settings per template if we have detected a need for it when writing and testing our wizards.
If you have a situation where a Service Provider in our catalog asks you to change the signature behavior, please report to us via a support ticket. This means your provider changed their behavior and we have not yet detected it.
Signature for catalog item using metadata
For Custom SAML as well as any app using metadata in URL or XML during configuration, the behavior will depend on the WantAssertionsSigned value provided in the Service Provider metadata.
| WantAssertionsSigned | SAML Response | SAML Assertion |
|---|---|---|
| not set | Signed | Signed |
| true | Not signed | Signed |
| false | Signed | Not Signed |
We are not happy with a grid and will, in the future, extend the capability of Custom SAML to allow custom settings by you.
This situation is the result of a lack of specifications in the use and advertising of different kinds of signatures on the SAML exchanges.