NativeSPAttributeRetrieval

The SP requests that a user authenticate by sending an authentication request to the IdP. The IdP will send a response that includes authentication information, and it might include attributes. The IdP determines whether to include attributes with the authentication response, and the default behavior depends on the protocol used.

With SAML 1.x, the IdP will by default NOT include any attributes in the response. With other protocols, including SAML 2.0, the IdP by default will include them, but will simply fail if an encryption key to use cannot be obtained for the SP. All of these are configuration options in both older and 2.x versions of the software.

The SP uses the authentication response to build a session. If there are attributes, it will extract and filter them. Whether or not any attributes are supplied, the SP will then execute any attribute resolvers with which it is configured. One of these resolvers (type="Query") provides backward compatibility with older SP releases by either doing nothing if attributes were supplied, or performing a SAML query if no attributes were supplied.

Note that with SAML 2.0, some IdPs may not supply a <NameID> element in the subject of their assertions, usually when the attribute filtering policy at the IdP is overly-strict. In such cases, if the IdP supplies no attributes but its metadata indicates support for the attribute query profile, the SP will attempt to perform a superfluous query, and fail because of the lack of a <NameID> value to query against.

Regardless of the outcome of the resolution step, whatever information is available is stored with the new user session, and the ability or inability to obtain attibutes has no effect on the status of the session. Apart from any statically-configured access control rules based on attributes, it is the application's responsibility to determine if the information available is adequate to proceed.