SAMLProfileConfigurations

The DefiningProfileConfigurations topic discusses how Profile Configurations can be enabled at different levels of granularity. The “net.shibboleth.plugin.shibd.saml” protocol plugin will contribute support for these profile beans into the system:

SAML2.SSO (SAML 2.0 Browser SSO)
SAML2.ECP (SAML 2.0 ECP Profile 2.0)
SAML2.Logout (SAML 2.0 Browser Single Logout)

When these beans are explicitly defined rather than used via automatic registration, the individual settings become subject to control on whatever level of granularity may be needed. The following is a brief summary and (heavily excerpted) examples of a few of the more important or commonly-needed settings available. Complete reference information can be found at SAMLSettingsReference.

1 Cross-Profile Settings
- 1.1 Message Signing
2 Browser SSO Settings
- 2.1 checkAddress
- 2.2 allowUnsolicited
- 2.3 disallowedFeatures
- 2.4 authnContextClassRefs
- 2.5 extractStandardAttributes

Cross-Profile Settings

These are some useful settings that are present on all of the supported SAML profiles.

Message Signing

There are flags available to control signing of SAML requests and responses. In most cases these should be defaulted but you can control them individually if desired with the signRequests and signResponses flags:

<bean parent="SAML2.SSO" p:signRequests="true" />

Typically it is unnecessary to sign login requests but required to sign logout requests.

Browser SSO Settings

SSO is the most complex SAML profile supported, so it contains more settings than most others. Just a few are noted here.

checkAddress

Familiar to users of the legacy SP, this flag will disable the cross-check of client address between the issued SAML Assertion and the current connection to the Agent, which is a frequent need in this era of broken networks.

<bean parent="SAML2.SSO" p:checkAddress="false" />

The default value of this setting is controlled by the global property sp.saml.checkAddress, which is true by default.

allowUnsolicited

Allowing IdPs to issue responses to the SP with no prior request is essentially a XSRF attack. This “feature” can be disabled by setting this flag to false, causing the Hub to refuse to process SAML responses that don’t match a “known” request.

<bean parent="SAML2.SSO" p:allowUnsolicited="false" />

The default value of this setting is controlled by the global property sp.saml.allowUnsolicited, which is true by default.

disallowedFeatures

There are a number of bitmask constants defined that regulate what SAML options an Agent is permitted to send to the Hub to override behavior, whether defaulted or explicit, when making SAML requests. By default, Agents are given permission to control these options (mostly for legacy compatibility reasons). Most commonly, if you were to set such an option within the Hub explicitly, you would tend to also want to restrict the ability for Agents to override it.

Options controllable include these beans:

SAML2.SSO.FEATURE_AUTHNCONTEXT
SAML2.SSO.FEATURE_FORCEAUTHN
SAML2.SSO.FEATURE_NAMEIDFORMAT
SAML2.SSO.FEATURE_SPNAMEQUALIFIER

Of these, the first is probably the most significant/common to want to block to prevent any override of authentication policy managed upstream of the Agent, possibly at the IdP itself.

To set more than one, you use a Set as the property value with each bit you want set:

<bean parent="SAML2.SSO">
    <property name="disallowedFeatures">
        <util:set>
          <ref bean="SAML2.SSO.FEATURE_AUTHNCONTEXT" />
          <ref bean="SAML2.SSO.FEATURE_NAMEIDFORMAT" />
        </util:set>
    </property>
</bean>

authnContextClassRefs

The Hub’s SAML authentication requests can be populated with a <RequestedAuthnContext> element with the class reference values specified with this setting. Typically this is used to specify a requirement for stronger authentication than some “baseline” default available.

In the higher education sector, the REFEDS MFA Profile is an example of a value designed for interoperable signaling:

<bean parent="SAML2.SSO" p:authnContextClassRefs="https://refeds.org/profile/mfa" />

However, you may find it easier to leave this up to Agents to control, as they will usually have to enforce the content of the value returned by relying on the Hub to extract it for them.

In addition, be aware that this setting has mandatory semantics; an IdP that receives such a request must understand and satisfy the requirement exactly, or return an error, so use of this setting is very likely to result in errors under expected conditions, and break non-compliant IdPs, of which there are many.

extractStandardAttributes

The legacy SP populated a number of “special/standard” variables with data extracted from SAML messages “outside” the normal set of rules defined for pulling data out of SAML Assertion(s). This setting enables that if necessary to emulate that behavior. It is discussed in some detail in the SAMLBasics topic’s Attribute section.

<bean parent="SAML2.SSO" p:extractStandardAttributes="true" />

The default value of this setting is controlled by the global property sp.saml.extractStandardAttributes, which is false by default. Related properties control the names of the IdPAttributes created.