Page Comparison

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 containes contains mechanisms to black list enable and white list security Alogithmsdisable 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

Attributes

None

Child Elements

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.

...

Each policy contains a variety of loosely related settings and a configurable set of "rules" that implement particular protections and peer authentication mechanisms.

Attributes

...

Name

...

Type

...

Default

...

Description

...

Uniquely names this policy within the XML file.

...

Enables or disables schema validation of XML when parsing messages at runtime. Includes all SAML and SOAP messages.

Child Elements

...

Name

...

Cardinality

...

Description

...

Security policy rules to use.

...

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.

<SecurityPolicies xmlns="urn:mace:shibboleth:23.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>