How to refuse SP session when no attributes received?

[Peter Schober]

* Gernot Hassenpflug <gernot.hassenpflug at asahinet.com> [2013-03-11 06:33]:
> Our SP (Shibboleth 2.4.3 with Apache 1.3, plus nginx as a front-end
> web server) has gone into production with the customer (a major
> university in Japan) as of this morning

I suppose you'll have your reasons for starting a new project with
ancient, unsupported software.

> It seems some users are being authenticated, but no attributes are
> sent to the SP (whether this is caused by the customer's IdP and/or
> Siteminder settings we do not yet know, but password authentication is
> clearly processed successfully). In that case, REMOTE_USER is empty,
> but the SP nevertheless creates a session and redirects to the
> application page requested (in this case, a local application login
> page is displayed).

Yes. You could handle that situation in your own code, of course, and
also immediately remove the session there.

> After that, the SP attempts to connect to the IdP and do another
> attribute query---it fails with a connect timeout.

If the IDP does not support attribute queries it should not announce
support for those in its SAML metadata. Or get the port opened and
queries fixed, obviously.
(If you rely on attributes always being pushed from IdPs, e.g. because
all IdPs support SAML2, you could also disable the SP's attribute
query plugin to avoid useless attribute queries when the IdP does not
provide attributes in the first place.)

> What I would like to know is if, and if so, how, one could configure
> the SP to not create a session or not redirect, or otherwise declare
> an error if no attributes (or not the desired attributes) are passed
> from the IdP. I understand that we cannot go back to the IdP login
> page since the credentials were already validated by the IdP.
> 
> As a workaround we declare "Access forbidden" if REMOTE_USER is empty
> for shibboleth-protected pages.

That's one way. You can make that page more friendly by telling the
subject what to do about it, e.g. by including info on whom to contact
(by parsing the SAML metadata for the IdP).

Or you could just upgrade and let the Shibbolet SP do all that for
you, using the "Metadata" AttributeExtractor and the SP's SessionHook
plus either your own SessionHook code or the provided AttributeChecker
Handler (incl flushSession="true").
-peter