Options specific to the SAML 2.0 Browser SSO profile:
Name / Type |
Default |
Description |
encryptAssertions
Boolean |
true |
Whether to encrypt assertions as a whole |
encryptAttributes
Boolean |
false |
Whether to encrypt individual SAML Attributes |
maximumSPSessionLifetime
Duration |
0 |
If non-zero, attempts to limit length of session with SP via =
SessionNotOnOrAfter attribute |
skipEndpointValidationWhenSigned
Boolean |
false |
Whether to skip validation of response location via metadata if the requ=
est was signed |
nameIDFormatPrecedence
List<String> |
|
Ordered list of NameID Format(s) to select f=
or use, in the event that a relying party does not signal a preference. =
|
ignoreScoping
Boolean |
false |
Whether to ignore <saml2:Scoping> elements within an =
SP's AuthnRequest, and bypass generating one in accordance with the standar=
d when proxying |
checkAddress
Boolean |
true |
Whether to enforce consistency between the client's address and the valu=
e within an inbound assertion's <saml2:SubjectConfirmationData>=
and <saml2:SubjectLocality> elements |
proxyCount
Non-negative Integer |
|
Controls the insertion of a proxy count into a <saml2:Scoping&g=
t; element (when issuing SAML 2 AuthnRequests to an IdP) and into a =
<saml2:ProxyRestiction> element (when issuing SAML 2 ass=
ertions) |
proxyAudiences
Set<String> |
|
Controls the insertion of audiences into a <saml2:ProxyResticti=
on> element when issuing SAML 2 assertions |
proxiedAuthnInstant
Boolean |
true |
Whether to pass through a proxied AuthnInstant value from a=
n inbound assertion when issuing new assertions based on it (the alternativ=
e is to insert a fresh timestamp) |
suppressAuthenticatingAuthority 4.2
Boolean |
false |
Whether to prevent the insertion of <AuthenticatingAuthority>=
; elements(s) in the event of proxying |
maximumTimeSinceAuthn
Duration |
|
Limits the allowable time to accept a proxied authentication assertion b=
ased on its AuthnInstant , this is principally used to cross-ch=
eck use of the ForceAuthn flag |
authnContextComparison
"exact", "minimum", "maximum", "better" |
see below |
Controls the comparison operator used when including <saml2p:Re=
questedAuthnContext> elements in proxied AuthnRequests |
authnContextTranslationStrategy
Function<AuthnContext=
a>,Collection<Principal> |
see below |
Controls bidirectional translation of <saml2:AuthnContext>=
code> content when issuing requests and generating assertions to allow for =
remapping of values across the proxy boundary |
authnContextTranslationStrategyEx 4.2
Function<Profi=
leRequestContext,Collection=
a><Principal>
|
|
More advanced support for populating <saml2:AuthnContext> content based on arbitrary request state (e.g. use of SAML Attributes =
from a proxied IdP) |
requireSignedRequests 4.3 |
false |
When true, equivalent to setting the AuthnRequestsSigned attribute in SP=
metadata, blocks unsigned requests. Main use for this is to facilitate blo=
cking IdP-initiated SSO. |
Guidance
The nameIDFormatPrecedence
property is a common way of=
controlling the type of SAML NameIden=
tifier / NameID included in a response, a common requirement of many co=
mmercial services. It is in fact the only way to force the=
use of the ill-advised "urn:oasis:names:tc:SAML:1.1:nameid-format:un=
specified
" Format, which it must be noted is very rarely needed, des=
pite frequent mis-documentation to the contrary.
In most cases, it is better to control the Format selected by including =
a <NameIDFormat>
element in the SP's metadata. In t=
he event that you don't control the metadata, you can inject the required e=
lement by applying a metadata filter.
<bean=
id=3D"shibboleth.DefaultRelyingParty" parent=3D"RelyingParty">
=09<!--
=09Both constants below evaluate to the string "urn:oasis:names:tc:SAML:1.1=
:nameid-format:unspecified",
=09and are interchangeable, they're just illustrations of different ways to=
reference the same string.
=09-->
=09<!-- Use "unspecified" NameIdentifier with Shibboleth SSO profile. --=
>
=09<bean parent=3D"Shibboleth.SSO">
=09=09<property name=3D"nameIDFormatPrecedence">
=09=09=09<list>
=09=09=09=09<util:constant static-field=3D"org.opensaml.saml.saml1.core.=
NameIdentifier.UNSPECIFIED" />
=09=09=09</list>
=09=09</property>
=09</bean>
=09<!-- Use "unspecified" NameID with SAML 2 SSO profile. -->
=09<bean parent=3D"SAML2.SSO">
=09=09<property name=3D"nameIDFormatPrecedence">
=09=09=09<list>
=09=09=09=09<util:constant static-field=3D"org.opensaml.saml.saml2.core.=
NameIDType.UNSPECIFIED" />
=09=09=09</list>
=09=09</property>
=09</bean>
=09<!-- Return formats from a function bean (not shown). -->
=09<bean parent=3D"Shibboleth.SSO" p:nameIDFormatPrecedenceLookupStrateg=
y-ref=3D"FormatsFunction" />
</bean>
The skipEndpointValidationWhenSigned
option is attract=
ive in many enterprise scenarios if you prefer to maintain some degree of s=
ecurity but avoid registration of metadata containing every individual SP e=
ndpoint, which adds a lot of overhead in massively vhosted-environments. It=
can also add a degree of insulation from SP changes, but in practice syste=
ms that are likely to change endpoint locations but don't support metadata-=
based change control are likely to misunderstand the need to keep entityIDs=
stable also.
The ignoreScoping
setting is provided to work around intero=
perability issues with broken SPs.
Several other new settings are used when proxying and provide various ki=
nds of policy controls familiar to SP operators, as well as new features to=
support remapping of potentially non-interoperable AuthnContext values. By=
default, the IdP operates in a fairly automatic fashion when proxying, suc=
h that any <saml2p:RequestedAuthnContext>
element from a=
n SP will be echoed essentially as-is to any upstream Identity Provider, an=
d the data found in the incoming assertion will be echoed as-is back downst=
ream. Since proxying is often used to firewall against interoperability pro=
blems and crosswalk between different communities of practice, functions ca=
n be plugged in to perform more flexible mapping of values, and some pre-ex=
isting machinery is in place to support this declaratively, as described in=
the AuthenticationConfiguration pag=
e. An additional hook was added in V4.1 that allows a similar function to b=
e injected but with access to the entire request state to do more advanced =
things.
There are also a variety of settings related to delegation that are not =
shown above but can be found in the relevant API documentation.