How Attributes are Retrieved
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. That's the IdP's decision. By default, Shibboleth 1.3 doesn't, and 2.0 does. The SP will use the Response . 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 uses them, and it's done. If there are no attributes, and there is an <AttributeResolver 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" />, it will request attributes. If there is no query attribute resolver, or the query fails, then there will be no attributes, but there will be a session) provides backward compatibility with older SP releases by either doing nothing if attributes were supplied, or performing a SAML query if none were.
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.