Shibboleth Developers

["Scott Cantor" <>]

> My understanding is that the SP does not query for attributes (ever) if
> they are pushed.  If they are not pushed, and an attribute authority
> role for the IdP is defined, it will query once and then cache the
> information for the life of the user's Shib session.
> 
> Scott, is the SP information basically correct?

Yes, it's accurate with respect to the delivered attribute resolver, whose
function by design is to behave that way. The code that short circuits the
query lives inside the "query" resolver plugin I wrote, so that the mainline
code just always invokes whatever resolver is configured, without knowing
whether it will do anything or not.

That allows somebody to write a different kind of resolver, for example one
that might always query, or that would query some other authority, rather
than hardwiring in the "push means no query" assumption, which is what the
old code in 1.3 did inside the session cache.

The SP attribute "architecture" in 2.0 consists of a two part process
combining "SAML extraction" and "resolution". Every SAML assertion that
comes in during SSO is fed into an extractor that knows how to pull out
attributes from any AttributeStatements it finds. (Of course, the result is
then filtered.)

Then the resolver gets called, if any, and it has access to the session (or
what will become the session) so that it can decide whether to do anything
or not.

Finally, note that the "life" of a 2.0 session is controllable from the IdP
via the SessionNotOnOrAfter attribute, so this enables some control over how
often the data might be updated, since the IdP is in the best position to
know.

-- Scott