Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
The Shibboleth IdP V4 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP5 wiki space for current documentation on the supported version.
The SAML2.AttributeQuery profile configuration bean enables support for the SAML 2.0 Attribute Query profile over SOAP. It was implemented mostly for completeness and has seen some use by virtual organizations and research communities but is rarely used in enterprise scenarios.
By default, the IdP will only respond to queries containing NameIDs that it understands how to reverse-map into user identities, and it will not do so out of the box for anything but transient identifiers issued by it. Nevertheless, it should be disabled if not in use.
Configuration
The most typical options used are described in more detail below, but not every obscure option is discussed. See the javadoc for all of the possible configuration options for this profile (note that many of them are inherited from parent classes).
Virtually all the configuration options below can be set via two different properties: a static property that explicitly sets the value to use and a lookup strategy or predicate property that takes a Function or Predicate and returns the value to use. The dynamic property is generally named "propertyNamePredicate" or "propertyNameLookupStrategy" for Boolean- and non-Boolean-valued properties respectively.
Bean named shibboleth.DefaultSecurityConfiguration
An object containing all of the default security-related objects needed for peer authentication and encryption. See SecurityConfiguration for complete details.
disallowedFeatures
Integer
0
A bitmask of features to disallow, the mask values being specific to individual profiles
inboundInterceptorFlows
List<String>
Ordered list of profile interceptor flows to run prior to message processing
outboundInterceptorFlows
List<String>
Ordered list of profile interceptor flows to run prior to outbound message handling
specify an alternate signing or decryption key to use
control signing or encryption algorithms (but for metadata you control, it's advisable to control algorithms by using an extension to specify supported algorithms).
The two interceptor lists allow the much less commonly used profile interceptor injection points to be used. This is largely a Java-based way of doing very low-level sorts of “message rewriting” hackery that might otherwise be impossible to pull off. One use case for the inbound side might be picking up non-standard parameters in a SAML request.
Options common to SAML profiles:
Name
Type
Default
Description
Name
Type
Default
Description
signResponses
Boolean
varies by profile
Whether to sign responses
signRequests
Boolean
false
Whether to sign requests
Guidance
It isn't too common to need any of these options, and they should be changed only with care.
The signResponses default varies by profile, see the notes on the individual profile pages.
Options common to SAML profiles that create assertions:
Name
Type
Default
Description
Name
Type
Default
Description
additionalAudiencesForAssertion
Collection<String>
Additional values to populate into audience restriction condition of assertions
includeConditionsNotBefore
Boolean
true
Whether to include a NotBefore attribute in assertions
assertionLifetime
Duration
PT5M
Lifetime of assertions
signAssertions
Boolean
false
Whether to sign assertions
Guidance
It isn't too common to need any of these options, and they should be changed only with care.
The additionalAuduencesForAssertion and includeConditionsNotBefore settings provide ways to work around bugs in other systems. You should never use these settings without obtaining a commitment from the other system's owner to fix their bugs.
The assertionLifetime setting does not involve control over the session with the relying party, it's only relevant in delegation scenarios.
The signResponses default varies by profile, see the notes on the individual profile pages.
If you need to enable the signAssertions option, and you control the SP's metadata, you should generally add the WantAssertionsSigned flag to it in place of using this option. Related, the idp.saml.honorWantAssertionsSigned property can be turned off to globally ignore that flag in metadata should you wish to do so.
Options common to SAML 2.0 profiles:
Name
Type
Default
Description
Name
Type
Default
Description
ignoreRequestSignatures
Boolean
false
Whether to skip validation of signatures on requests
encryptionOptional
Boolean
false
Whether to automatically disable encryption if the relying party does not possess a suitable key
encryptNameIDs
Boolean
varies by profile
Whether to encrypt NameIDs
Guidance
The encryption options are generally set correctly for each different profile; see the notes on the individual profile pages.
Note that when the conditions to encrypt various constructs evaluate to true, the IdP will fail the request if it is unable to perform the encryption, for whatever reason. This is overrideable using the encryptionOptional property, which allows the IdP to encrypt if it can but continue otherwise. If you carefully control your metadata sources, which you should do in any case, you should be able to trust that any SP lacking an encryption key is incapable of encryption anyway, making the property safe to enable.
The ignoreRequestSignatures option is an interoperability knob to deal with badly broken or incompetently operated services. Signed requests in some profiles, particularly SSO, are often pointless and are frequently used for no good reason. If the signer's code is broken, or even worse if they manage their key poorly and require constant flag days to update them, this allows the signature to be ignored and potentially the key to be bypassed so their incompetence doesn't impact your operations.
Name
Type
Default
Description
Name
Type
Default
Description
encryptAssertions
Boolean
See Notes
Whether to encrypt assertions
encryptAttributes
Boolean
false
Whether to encrypt attributes
Notes
The default value of signResponses for this profile is an extended form of the behavior that was referred to in V2 as "conditional". It signs only if TLS isn't used (very unusual) or if the receiving port is 443. It assumes that traffic over 443 will be relying on message-based security measures, whereas traffic to an alternative TLS port like 8443 will be relying on mutual authentication and thus provide a secure channel.
The default value of encryptAssertions is also conditional on the same basis.
If you need to enable the signAssertions option, and you control the SP's metadata, you should generally add the WantAssertionsSigned flag to it in place of using this option. Related, the idp.saml.honorWantAssertionsSigned property can be turned off to globally ignore that flag in metadata should you wish to do so.