...
Liberty.SSOS (this undocumented feature supports SAML-based security delegation and , has been provisionally deprecated in this release, and will be removed in the next major version)
They ones that are active by default are included in the shibboleth.DefaultRelyingParty bean's profileConfigurations
property, by reference. You can turn them on or off using comments or by deleting them.
...
Note |
---|
As with all relying party settings, an override does not inherit the profiles enabled by default. An override essentially turns everything off unless its own |
Localtabgroup | ||
---|---|---|
| ||
Localtab live | ||
active | true | |
Expand | ||
| ||
To statically override a default profile option, you can replace a
The |
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
Note | All of the profile settings that can be set statically can also be computed via functions or predicates/conditions that execute at runtime. It's a better idea to look into MetadataDrivenConfiguration then to explore this feature. This is the low-level feature that makes metadata-driven settings possible but using metadata is usually more elegant and the system does all the fancy wiring for you. In the most advanced cases, most all profile settings can be derived at runtime using Java functions or scripts, termed "lookup strategies", instead of declaring them statically. This can be done for default or overridden relying party configurations, and provides a powerful way of combining different kinds of rules. This is a useful trick to use The use of this feature helps if you want to apply "cross-cutting" conditions to get around the limitation that overrides don't get merged. For example, consider the following use cases:
Of course, if these two sets don't overlap, and you have nothing else unusual to specify, you could create two overrides for each set individually. But what if the two sets overlap, with some relying parties in one, some in the other, and some in both? Now you need three overrides. Now consider that a third set requires an additional non-default setting and overlaps with some of the first two sets. The number of overrides will get out of hand quickly and start to get very confusing to manage. As an example, let's tackle the cases above by using scripts to derive the settings involved. This can potentially be done with no overrides at all, as below, though that's a matter of style. Use of scripts to derive profile settings
Obviously the example above is somewhat contrived. It's longer than just creating three overrides, but it illustrates the general idea and once you get comfortable using scripts, it isn't as bad as it looks. It's also possible to put scripts in separate files, which makes the XML much shorter. This becomes much more powerful when combined with other techniques, particularly the use of tag-based conditions based on A built-in way of doing this is described in the MetadataDrivenConfiguration topic, and this is the generally-advisable means of handling complex configuration of behavior now. |
Reference
Expand | |||||||
---|---|---|---|---|---|---|---|
| Changing Profile Defaults |
Code Block | ||
---|---|---|
| ||
<bean id="Shibboleth.SSO.custom" parent="Shibboleth.SSO"
p:nameIDFormatPrecedence="#{{
'urn:mace:shibboleth:1.0:nameIdentifier',
'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'}}" />
<bean id="SAML2.SSO.custom" parent="SAML2.SSO"
p:nameIDFormatPrecedence="#{{
'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
'urn:oasis:names:tc:SAML:2.0:nameid-format:transient',
'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress'}}" />
<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
<property name="profileConfigurations">
<util:list>
<ref bean="Shibboleth.SSO.custom" />
<ref bean="SAML1.AttributeQuery" />
<ref bean="SAML1.ArtifactResolution" />
<ref bean="SAML2.SSO.custom" />
<ref bean="SAML2.ECP" />
<ref bean="SAML2.Logout" />
<ref bean="SAML2.AttributeQuery" />
<ref bean="SAML2.ArtifactResolution" />
</util:list>
</property>
</bean>
<util:list id="shibboleth.RelyingPartyOverrides">
<bean parent="RelyingPartyByName"
c:relyingPartyIds="#{{'https://a.example.com/shibboleth', 'https://b.example.com/shibboleth'}}">
<property name="profileConfigurations">
<list>
<bean parent="SAML2.SSO.custom" p:encryptAssertions="false" />
</list>
</property>
</bean>
<bean parent="RelyingPartyByName"
c:relyingPartyIds="#{{'https://x.example.com/shibboleth', 'https://y.example.com/shibboleth'}}">
<property name="profileConfigurations">
<list>
<bean parent="Shibboleth.SSO.custom"
p:signAssertions="true"
p:signResponses="false" />
<bean parent="SAML2.SSO.custom"
p:signAssertions="true"
p:signResponses="false" />
</list>
</property>
</bean>
</util:list> |
Reference
Localtabgroup | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Localtab live | ||||
---|---|---|---|---|
|
Properties |
Properties defined in idp.properties directly related to this configuration area follow:
Property | Type | Default | Function |
---|---|---|---|
idp.entityID | URI | None | The unique name of the IdP, used as the "issuer" in all SAML profiles |
idp.artifact.enabled | Boolean | true | Whether to allow use of the SAML artifact bindings when sending messages |
idp.artifact.secureChannel | Boolean | true | Whether preparation of messages to be communicated via SAML artifact should assume use of a secure channel (allowing signing and encryption to be skipped) |
idp.artifact.endpointIndex | Integer | 2 | Identifies the |
idp.bindings.inMetadataOrder 4.1 | Boolean | true | Controls whether the outbound binding selection is ordered by the SP's metadata or the IdP's preferred bindings |
(the inbuilt default order is |
favor use of POST. Set also to false to favor the front channel over back channel for Logout. |
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Beans defined in relying-party.xml and related system configuration follow:
|
Expand | ||
---|---|---|
| ||
Without stepping fully into the SecurityConfiguration topic, the following defaults are used when enabling individual profiles. In addition, an appropriate "security policy" flow is enabled during request processing to enforce appropriate security guarantees.
|
...