Shibboleth Developers

["Scott Cantor" <>]

Peter Schober wrote on 2009-12-11:
> It seems to me the case of failing IP "auth" is not really an
> exceptional one when using IP "auth", so doing something similar to
> handling those unsuccessful isPassive responses would probably make
> deploying IP-auth possible without resorting to scripting.

Well, the majority/typical case with SAML errors is that you get
urn:....Responder or urn:....Requester and can't count on any other detail.
The specs have some errata in this area, but the rule of thumb is that you
MAY return second-level codes but if you do, they MUST have certain values
in certain cases.

Now, some cases are much more mandatory than others, like IsPassive, but
most are less strict and with commercial code I suspect second level codes
might be rare.

None of that precludes building in some support for triggering differently
when particular codes show up, though. Just pointing out a possible
limitation.

> Or is the problem then that the SP should know to invoke the
> accessDenied template?

Well, with IsPassive, it intentionally just passes back control, since
that's an optional session by definition. I didn't look at differentiating
between errors and access failure. If I start filtering on different codes,
part of that would probably include directing those filters to *either* hard
errors or access failures.

(Just as a point of note, the SP generally tries to use standard 403
Forbidden responses and only returns a page on "access failure" during the
ACL processing if you supply a template for that. My assumption was it's
better to let people tailor 403s using the standard web server bits and not
mine.)

Anyway, there's lots of territory here and it probably makes sense to try
and identify some specific needs. I don't have error handling specifically
tasked for this coming wave of development, but it may be relatively simple
to do, just depends. I'll add it to the backlog at the very least.

-- Scott