Page Comparison

...

For example, if you would like to enable tag-driven configuration for SAML 2.0 Browser SSO, you can replace any reference to the SAML2.SSO bean with SAML2.SSO.MDDriven, as in this example:

Enable tag-driven features in relying-party.xml

Expand

title	Enable tag-driven features in relying-party.xml

Code Block

language	xml

<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
  	<property name="profileConfigurations">
		<list>
			    <list>
      <ref bean="Shibboleth.SSO" />
			      <ref bean="SAML1.AttributeQuery" />
			      <ref bean="SAML1.ArtifactResolution" />
 			     
      <ref bean="SAML2.SSO.MDDriven" /> <!-- enables metadata-driven settings -->
      			
      <ref bean="SAML2.ECP" />
			>
      <ref bean="SAML2.Logout" />
			      <ref bean="SAML2.AttributeQuery" />
			
      <ref bean="SAML2.ArtifactResolution" />
    		</list>
	  </property>
</bean>

Attribute / Property Convention

...

It follows that the includeAttributeStatement property of the "Shibboleth.SSO" profile configuration can be set via a metadata Attribute named "http://shibboleth.net/ns/profiles/saml1/sso/browser/includeAttributeStatement"

As an additional convention, a setting can be configured for all profiles simultaneously by prefixing it with the URL "http://shibboleth.net/ns/profiles"

Tip
We reserve the right to define behavior for any current or future SAML Attributes named in the `shibboleth.net` domain or any other URI we own and control, so if any developers wish to develop general purpose extensions or behavior based on such tags, you should either rely on your own tag names or seek permission from the project.

true

Localtabgroup

tabStyle	flat

Localtab live

active

Expand

title	SAML Attribute NameFormat Usage

While the SAML Attribute Name is handled as above, the NameFormat of all supported properties is presumed to be urn:oasis:names:tc:SAML:2.0:attrname-format:uri to prevent conflicts. However, the system was in fact "lax" about this particular check in V3.

As Of of V4, there is a property in conf/services.xml that is shipped enabled, but internally off by default for compatibility on upgrades. When idp.service.relyingparty.ignoreUnmappedEntityAttributes is true, which is suggested, the system will ignore any tags that have an improper NameFormat unless they are explicitly decoded with a custom rule in the AttributeRegistryConfiguration.

A side effect of this setting is that the IdP will operate much faster in locating (or not locating) tags for all of its settings using decoded and indexed data instead of having to inefficiently search the native XML-wrapping based data structures for a match. As a result, it is strongly advised that the proper NameFormat be used and the property enabled.

localtab-live

Expand

title	Type Conversion

The supplied implementations support various built-in type conversions supporting a natural mapping between simple XML syntax and Java data types. Different kinds of settings support particular XML syntaxes as described below.

The only XML syntaxes supported are "simple content" models involving an <AttributeValue> containing only text content, but it is possible to apply specific xsi:type designations that trigger more precise handling (such as enforcing numeric or boolean data). Note that using xsi:type in this fashion requires declaring an appropriate namespace and prefix for the XSD namespace, http://www.w3.org/2001/XMLSchema, which is conventionally bound to the xsd or xs prefixes.

Setting Data Type	Supported XML Conversions	Notes
String	Untyped, string, boolean, integer, dateTime, base64binary	Booleans are mapped to the strings "0" or "1". Dates are mapped into the Unix epoch, then converted to String.
Boolean	Untyped, string, boolean, integer	Strings are processed as a valid XML boolean value (0, 1, true, false) or treated as false. Non-zero integers are true, zero is false.
Integer	Untyped, string, boolean, integer	Strings are decoded via Integer.decode() method. Booleans are mapped to 0 or 1.
Long	Untyped, string, boolean, integer, dateTime	Strings are decoded via Long.decode() method. Booleans are mapped to 0 or 1. Dates are mapped to the Unix epoch, then converted to a Long.
Double	Untyped, string, boolean, integer	Strings are decoded via Double.valueOf() method. Booleans are mapped to 0.0 or 1.0.
Duration	Untyped, string, integer	Strings are converted from the ISO Duration notation used throughout the software. Integers are treated as a millisecond duration.
List<?>	Untyped, string, boolean, integer, dateTime, base64binary	Supports multiple `<AttributeValue>` elements, and each value is converted to a String and then used to construct an object of the type specified for the property via a String-based single-argument constructor.
Set<?>	Untyped, string, boolean, integer, dateTime, base64binary	Supports multiple `<AttributeValue>` elements, and each value is converted to a String and then used to construct an object of the type specified for the property via a String-based single-argument constructor.
Bean	Untyped, string	Converted to a String used as a name of a Spring bean to build or access

...

The direct method applies to cases in which you control the metadata or when the source of the metadata supports the inclusion of the necessary extensions. The tags simply appear within the metadata being loaded into the IdP using an <mdattr:EntityAttributes> extension element:

...

Expand

title	Direct embedding of configuration tags

Code Block

language	xml

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" 
                  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                  xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"
                  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  entityID="https://sp.example.org/sp">
    <Extensions>
        <mdattr:EntityAttributes>
            <saml:Attribute Name="http://shibboleth.net/ns/profiles/defaultAuthenticationMethods"
                NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml:AttributeValue>http://example.org/ac/classes/mfa</saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="http://shibboleth.net/ns/profiles/saml2/sso/browser/signResponses"
                NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml:AttributeValue>false</saml:AttributeValue>
            </saml:Attribute>
        </mdattr:EntityAttributes>
    </Extensions>
    <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
	<!-- Content omitted -->        
    </SPSSODescriptor>
</EntityDescriptor>

The indirect method uses the EntityAttributesFilter to attach the tags at runtime after loading and verifying the metadata. This is useful for cases in which you want to rely on externally supplied metadata but still organize parts of your configuration around the metadata. One use for this is simply consistency: if you have both external and local metadata, you can drive the configuration with both.

Indirect example of applying tags using a filter

Expand

title	Indirect example of applying tags using a filter

Code Block

language	xml

<MetadataProvider id="InCommonMD" xsi:type="FileBackedHTTPMetadataProvider"
	metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml"
	backingFile="%{idp.home}/metadata/InCommon-metadata.xml"
	failFastInitialization="false">
	<MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P14D" />
	<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
		certificateFile="%{idp.home}/credentials/incommon.pem" />
	<MetadataFilter xsi:type="EntityRoleWhiteListEntityRole">
		<RetainedRole>md:SPSSODescriptor</RetainedRole>
	</MetadataFilter>
	<MetadataFilter xsi:type="EntityAttributes">
		<saml:Attribute Name="http://shibboleth.net/ns/profiles/defaultAuthenticationMethods"
			NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
			<saml:AttributeValue>http://example.org/ac/classes/mfa</saml:AttributeValue>
		</saml:Attribute>
		<saml:Attribute Name="http://shibboleth.net/ns/profiles/saml2/sso/browser/signResponses"
			NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
			<saml:AttributeValue>false</saml:AttributeValue>
		</saml:Attribute>
		<Entity>https://sp.example.org/sp</Entity>
	</MetadataFilter>
</MetadataProvider>

...

Enabling signed assertions for a particular SP is advisedly handled by setting the WantAssertionsSigned XML attribute in metadata, but isn't always possible and sometimes has to be combined with disabling signed responses (or just for efficiency).

...

.

Expand

title	SAML 2 Browser SSO: Sign assertions and not responses

Code Block

language	xml

<saml:Attribute Name="http://shibboleth.net/ns/profiles/saml2/sso/browser/signResponses"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>false</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="http://shibboleth.net/ns/profiles/saml2/sso/browser/signAssertions"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>true</saml:AttributeValue>
</saml:Attribute>

...

Note that it may be helpful to make sure encryption also doesn't get used during logout, so the second tag may be useful.

All profiles: turn off encryption

Expand

title	All profiles: turn off encryption

Code Block

language	xml

<saml:Attribute Name="http://shibboleth.net/ns/profiles/encryptAssertions"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>false</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="http://shibboleth.net/ns/profiles/encryptNameIDs"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>false</saml:AttributeValue>
</saml:Attribute>

...

Using <NameIDFormat> elements in metadata (which can also be added at runtime with the NameIDFormatFilter) is the normal way to use metadata to select the Format to use, but the "unspecified" Format has to be triggered with a profile setting. That's not commonly needed, but it's easy to define a tag for in such cases (and if you prefer you can obviously designate any Format this way).

All profiles: use the "unspecified" NameID Format

Expand

title	All profiles: use the "unspecified" NameID Format

Code Block

language	xml

<saml:Attribute Name="http://shibboleth.net/ns/profiles/nameIDFormatPrecedence"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</saml:AttributeValue>
</saml:Attribute>

...

Some of the other profile settings are workarounds for bugs, e.g., omitting the NotBefore attribute. This is not very common but easily tag-driven.

All profiles: omit the NotBefore attribute

Expand

title	All profiles: omit the NotBefore attribute

Code Block

language	xml

<saml:Attribute Name="http://shibboleth.net/ns/profiles/includeConditionsNotBefore"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>false</saml:AttributeValue>
</saml:Attribute>

A more obscure example would be an SP that requires additional <Audience> values in addition to its own entityID. This mainly demonstrates that some settings may be multi-valued.

...

Expand

title	All profiles: add additional Audience values

Code Block

language	xml

<saml:Attribute Name="http://shibboleth.net/ns/profiles/assertionAudiences"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>https://example.org/bogusAudience1</saml:AttributeValue>
	<saml:AttributeValue>https://example.org/bogusAudience2</saml:AttributeValue>
</saml:Attribute>

...

Handling SPs that require MFA but can't request it requires IdP-side configuration, usually involving a couple of settings. The URL below is just an example, it has to be replaced by whatever <AuthnContextClassRef> constant is used in a deployment to signal MFA, or possibly more than one.

...

Expand

title	All profiles: forcing MFA

Code Block

language	xml

<saml:Attribute Name="http://shibboleth.net/ns/profiles/defaultAuthenticationMethods"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>http://example.org/ac/classes/mfa</saml:AttributeValue>
</saml:Attribute>
<!-- The disallowedFeatures setting is a bitmask, and 0x1 blocks SPs requesting authentication types. -->
<saml:Attribute Name="http://shibboleth.net/ns/profiles/disallowedFeatures"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>0x1</saml:AttributeValue>
</saml:Attribute

...

Triggering consent based on the SP is pretty common.

SAML and CAS SSO: enable attribute consent

Expand

title	SAML and CAS SSO: enable attribute consent

Code Block

language	xml

<saml:Attribute Name="http://shibboleth.net/ns/profiles/postAuthenticationFlows"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>attribute-release</saml:AttributeValue>
</saml:Attribute>

The authorization intereptor flow is another case, though the checking logic would have to be extended for each different service/scenario. In the example, both flows are enabled.

SAML and CAS SSO: enable authorization checking and attribute consent

Expand

title	SAML and CAS SSO: enable authorization checking and attribute consent

Code Block

language	xml

<saml:Attribute Name="http://shibboleth.net/ns/profiles/postAuthenticationFlows"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>context-check</saml:AttributeValue>
	<saml:AttributeValue>attribute-release</saml:AttributeValue>
</saml:Attribute

...

Therefore, the built-in wiring cannot accomodate this use case, but it's possible to do this with an activation condition. This is the same wiring that is provided by the system configuration for many of the other properties but is supplied here "by hand" in order to adjust the default value of the condition to "false" instead of "true".

...

.

...

Expand

title	Enabling SAML 1.1 SSO conditionally using a tag

Code Block

language	xml

<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty.MDDriven">
    <property name="profileConfigurations">
        <list>
            <bean parent="Shibboleth.SSO.MDDriven">
                <property name="activationCondition">
                    <bean class="net.shibboleth.utilities.java.support.logic.PredicateSupport" factory-method="fromFunction">
                        <constructor-arg>
                            <bean parent="shibboleth.MDDrivenBoolProperty" p:propertyName="activationCondition" />
                        </constructor-arg>
                        <constructor-arg value="false" />
                    </bean>
                </property>
            </bean>
            <ref bean="SAML2.SSO.MDDriven" />
            <ref bean="SAML2.ECP.MDDriven" />
            <ref bean="SAML2.Logout.MDDriven" />
            <ref bean="SAML2.AttributeQuery.MDDriven" />
            <ref bean="SAML2.ArtifactResolution.MDDriven" />
        </list>
    </property>
</bean>

...

Expand

title	Attribute to enable SAML 1.1

Code Block

language	xml

<saml:Attribute Name="http://shibboleth.net/ns/profiles/saml1/sso/browser/activationCondition"
	NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
	<saml:AttributeValue>true</saml:AttributeValue>
</saml:Attribute

...

Values: Each value is an internal IdPAttribute ID whose values should be released to an SP whose metadata contains the relevant tag/value.

Example

Here's an example policy (more or less matching an example in the default file) that applies this tag test to a couple of attributes. A couple of subtle points here.

...

Versions Compared

Old Version 19

New Version Current

Key

Enable tag-driven features in relying-party.xml

Attribute / Property Convention

Indirect example of applying tags using a filter

All profiles: turn off encryption

All profiles: use the "unspecified" NameID Format

All profiles: omit the NotBefore attribute

SAML and CAS SSO: enable attribute consent

SAML and CAS SSO: enable authorization checking and attribute consent

Example