...
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:
| Expand |
|---|
| title | Enable tag-driven features in relying-party.xml |
|---|
|
| Code Block |
|---|
| <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
...
| Localtabgroup |
|---|
|
| Localtab live |
|---|
| active | true |
|---|
| 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. 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 |
|---|
| <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.
...
| Expand |
|---|
| title | Indirect example of applying tags using a filter |
|---|
|
| Code Block |
|---|
| <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="EntityRoleWhiteList">
<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 |
|---|
| <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.
| Expand |
|---|
| title | All profiles: turn off encryption |
|---|
|
| Code Block |
|---|
| <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).
...
designate any Format this way).
| Expand |
|---|
| title | All profiles: use the "unspecified" NameID Format |
|---|
|
| Code Block |
|---|
| <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.
| Expand |
|---|
| title | All profiles: omit the NotBefore attribute |
|---|
|
| Code Block |
|---|
| <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 |
|---|
| <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 |
|---|
| <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.
...
| Expand |
|---|
| title | SAML and CAS SSO: enable attribute consent |
|---|
|
| Code Block |
|---|
| <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.
...
| Expand |
|---|
| title | SAML and CAS SSO: enable authorization checking and attribute consent |
|---|
|
| Code Block |
|---|
| <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 |
|---|
| <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 |
|---|
| <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.
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.
...
| Code Block |
|---|
<AttributeFilterPolicy id="Per-Attribute-singleValued">
<PolicyRequirementRule xsi:type="ANY"/>
<AttributeRule attributeID="eduPersonPrincipalName">
<PermitValueRule xsi:type="EntityAttributeExactMatch"
attributeName="http://shibboleth.net/ns/attributes/releaseAllValues"
attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
attributeValue="eduPersonPrincipalName" />
</AttributeRule>
<AttributeRule attributeID="mail">
<PermitValueRule xsi:type="EntityAttributeExactMatch"
attributeName="http://shibboleth.net/ns/attributes/releaseAllValues"
attributeNameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
attributeValue="mail" />
</AttributeRule>
</AttributeFilterPolicy>
|
Reference
| Localtabgroup |
|---|
Bean ID | Type | Function |
|---|
RelyingParty.MDDriven | RelyingPartyConfiguration | A template bean for use in defining metadata-driven RelyingParty overrides by hand | RelyingPartyByName.MDDriven | RelyingPartyConfiguration | A template bean for defining metadata-driven RelyingParty overrides based on matching by name | RelyingPartyByGroup.MDDriven | RelyingPartyConfiguration | A template bean for defining metadata-driven RelyingParty overrides based on matching by <EntitiesDescriptor> groups or SAML metadata-based <AffiliationDescriptor> groups | RelyingPartyByEntitiesDescriptor.MDDriven 4.1 | RelyingPartyConfiguration | A template bean for defining metadata-driven RelyingParty overrides based on matching by <EntitiesDescriptor> groups only | RelyingPartyByTag.MDDriven | RelyingPartyConfiguration | A template bean for defining metadata-driven RelyingParty overrides based on matching <EntityAttributes> extension content | RelyingPartyByMappedTag.MDDriven | RelyingPartyConfiguration | A template bean for defining metadata-driven RelyingParty overrides based on matching <EntityAttributes> extension content mapped via the AttributeRegistryConfiguration | Shibboleth.SSO.MDDriven | BrowserSSOProfileConfiguration | Default metadata-driven configuration for SAML 1.1 SSO profile | SAML1.AttributeQuery.MDDriven | AttributeQueryProfileConfiguration | Default metadata-driven configuration for SAML 1.1 Attribute Query profile | SAML1.ArtifactResolution.MDDriven | ArtifactResolutionProfileConfiguration | Default metadata-driven configuration for SAML 1.1 Artifact Resolution profile | SAML2.SSO.MDDriven | BrowserSSOProfileConfiguration | Default metadata-driven configuration for SAML 2.0 SSO profile | SAML2.ECP.MDDriven | ECPProfileConfiguration | Default metadata-driven configuration for SAML 2.0 Enhanced Client/Proxy profile | SAML2.Logout.MDDriven | SingleLogoutProfileConfiguration | Default metadata-driven configuration for SAML 2.0 Single Logout profile | SAML2.AttributeQuery.MDDriven | AttributeQueryProfileConfiguration | Default metadata-driven configuration for SAML 2.0 Attribute Query profile | SAML2.ArtifactResolution.MDDriven | ArtifactResolutionProfileConfiguration | Default metadata-driven configuration for SAML 2.0 Artifact Resolution profile | Liberty.SSOS.MDDriven | SSOSProfileConfiguration | Default metadata-driven configuration for Liberty ID-WSF Delegated SSO profile | CAS.LoginConfiguration.MDDriven | LoginConfiguration | Default metadata-driven configuration for CAS login prototol | CAS.ProxyConfiguration.MDDriven | ProxyConfiguration | Default metadata-driven configuration for CAS proxy login protocol | CAS.ValidateConfiguration.MDDriven | ValidateConfiguration | Default metadata-driven configuration for CAS ticket validation protocol | shibboleth.DefaultMDProfileAliases | List<String> | A built-in list of alternate URL "prefixes" to property names, this is used to automate the generation of property tag names that apply to all profiles at the same time. | shibboleth.MDProfileAliases | List<String> | An optional user-supplied list of additional URL prefixes to support custom property tag names | shibboleth.MDDrivenStringProperty | StringConfigurationLookupStrategy | Parent bean for defining new lookup strategies for string settings | shibboleth.MDDrivenBoolProperty | BooleanConfigurationLookupStrategy | Parent bean for defining new lookup strategies for boolean settings | shibboleth.MDDrivenIntProperty | IntegerConfigurationLookupStrategy | Parent bean for defining new lookup strategies for integer settings | shibboleth.MDDrivenLongProperty | LongConfigurationLookupStrategy | Parent bean for defining new lookup strategies for long integer settings | shibboleth.MDDrivenDoubleProperty | DoubleConfigurationLookupStrategy | Parent bean for defining new lookup strategies for double settings | shibboleth.MDDrivenDurationProperty | DurationConfigurationLookupStrategy | Parent bean for defining new lookup strategies for Duration settings | shibboleth.MDDrivenListProperty | ListConfigurationLookupStrategy | Parent bean for defining new lookup strategies for List settings | shibboleth.MDDrivenSetProperty | SetConfigurationLookupStrategy | Parent bean for defining new lookup strategies for Set settings | shibboleth.MDDrivenBeanProperty | BeanConfigurationLookupStrategy | Parent bean for defining new lookup strategies for arbitrary Spring bean settings |
|