...
In Shibboleth 2 the relying-party.xml file also included MetadataProviders. In Shib 3 there is a separate file for metadata-providers.Our Shibboleth 3
In SAML, the IdP can digitally sign both the Response and the Attributes, or just the Response. The Attributes can be encrypted or not. Shibboleth has a default. The relying-party.xml file configures the same defaults that were configured with a different XML syntax in our Shib 2 configuration file. There is one really important statement:
...
provides syntax to specify specific Yale defaults for each option. Default behavior can be overridden by the Metadata of the RP or by the contents of the Request (if one is sent).
Yale does not encrypt attributes if we can avoid it because it makes debugging impossible and because the entire SAML message is typically protected by SSL. In Shib 2 our default behavior was to digitally sign both the Response and the Attribute Assertion, but now we just sign the Response by default.
The new Shib 3 relying-party.xml file is small and has a new syntax. In theory we could specify defaults for each SAML protocols supported, but currently the only SAML Protocol that anyone uses is SSO:
| Code Block |
|---|
p:encryptAssertions="false<bean parent="SAML2.SSO" p:encryptNameIDs="falsepostAuthenticationFlows="%{idp.postauthenticationflows}" p:encryptAssertions="false" p:encryptNameIDs="false" p:encryptAttributes="false" /> |
...
The postAuthenticationFlows parameter currently has one possible interesting value. If it is set to "attribute-release" then this triggers the Consent dialog, where the user is given a list of attributes that are gooing to be released and has a chance to approve them. Currently we turn on Consent for DEV (because it makes debugging easier) and for Anonymous Relying Parties (where we get a SAML Request from an EntityID for which we have no Metadata).
...