SecurityPolicies

Overview

The <SecurityPolicies> element is a container for one or more uniquely identified <Policy> elements that control low-level security and profile processing performed by the SP. It also contains mechanisms to enable and disable security algorithms.

The system is flexible enough to allow very fine-grained selection of different policies to use for different use cases or even different IdPs, but this is not a commonly needed feature and the vast majority of deployments will just use the defaults, or at least a single default policy.

Reference

Child Elements

Name	Cardinality	Description

Name	Cardinality	Description
<Policy>	1 or more	Security policy rules. These must be the first child elements.
<AlgorithmWhitelist>	0 or 1	DEPRECATED: Whitespace-delimited list of algorithm URIs to explicitly enable
<IncludedAlgorithms> 3.2	0 or 1	Whitespace-delimited list of algorithm URIs to explicitly enable
<AlgorithmBlacklist>	0 or 1	DEPRECATED: Whitespace-delimited list of algorithms to explicitly disable
<ExcludedAlgorithms> 3.2	0 or 1	Whitespace-delimited list of algorithms to explicitly disable

Custom security policies can be defined at the level of a specific application or protocol endpoint and referenced via a policyId attribute, but in most cases, the default policy is appropriate for all typical exchanges.

Example

The example below is the default shipping version at the time of authoring. The default policy is the one used for all the typical interactions in the SP. For safety's sake, you will find that just removing some of the obviously named rules won't actually open your system to attacks but you might learn a bit about the system by playing with them.

The second named policy is an example of how to define a special set of rules for an unusual use case, the evaluation of signed SAML Assertions inside SAML metadata. It has only a couple of rules because a lot of the usual message oriented checks don't apply to that use case.

The last line essentially delegates the rules for disabling insecure algorithms to the software's defaults, allowing us to change them easily. The example dates to before V3.2, which has deprecated and renamed that element.

<SecurityPolicies xmlns="urn:mace:shibboleth:3.0:native:sp:config">

    <!-- Each policy defines a set of rules to use to secure messages. -->

    <!--
    The predefined policy enforces replay/freshness, standard
    condition processing, and permits signing and client TLS.
    -->
    <Policy id="default" validate="false">
        <PolicyRule type="MessageFlow" checkReplay="true" expires="60"/>
        <PolicyRule type="Conditions">
            <PolicyRule type="Audience"/>
            <!-- Enable Delegation rule to permit delegated access. -->
            <!-- <PolicyRule type="Delegation"/> -->
        </PolicyRule>
        <PolicyRule type="ClientCertAuth" errorFatal="true"/>
        <PolicyRule type="XMLSigning" errorFatal="true"/>
        <PolicyRule type="SimpleSigning" errorFatal="true"/>
    </Policy>

    <!--
    This policy is a place-holder for use of assertions in metadata
    as a way of attaching signed information about particular IdPs.
    -->
    <Policy id="entity-attributes">
        <PolicyRule type="Conditions"/>
        <PolicyRule type="XMLSigning" errorFatal="true"/>
    </Policy>
    
    <!-- Disables known weak algorithms. -->
    <AlgorithmBlacklist includeDefaultBlacklist="true"/>

</SecurityPolicies>