AttributeChecker and redirectErrors

Peter Schober peter.schober at univie.ac.at
Wed Jan 16 06:58:30 EST 2013


I looked into providing a somewhat centralized error handling page
displaying stuff fed from the SP's //Errors/@redirectErrors.

At the same time I turned on the new AttributeChecker handler and
started fumbling with the local template (to display friendly
explanations of why access is not possible at that time and who's to
blame for that).

>From that came the desire for handling failed AttributeChecker
evaluations the same way as Errors/@redirectErrors: with a redirect to
some external service.
Seems to me handling all necessary the conditional logic will be quite
a bit easier in a full prgramming/scripting environment, based on
request parameters, as compared to nested shibmlpif and shibmlpifnot
inside the template.
(Depending on the use there might then be the issue of forwarding PII
to a third party -- the handling service -- but as of now I don't see
a case where I needed to include attributes on the subject as part of
the attribute checker.)

Does that make sense and seems like a useful feature to others?
(I'd add an issue in Jira then.)

While I'm at it: For that idea -- but also for keeping the templates
for the Attribue Checker generic and identical over installs -- it
might also be helpful if the AttributeExtractor/@type="Metatdata"
could also export parts of the SP's own metadata (mdui, contactPerson,
etc.) in the way it currently does for the IdP.
As it is now (which is no big deal, really) I define basic things I
want to process in the template as additional attributes of the SP's
Errors element inside shibboleth2.xml (e.g. //Errors/@contactName,
//Errors/@contactEmail and //Errors/@serviceName), essentially
duplicating the SP's metadata.
  Not sure the latter is really generally helpful (and might even do
damage, since "the SP never processes its own metadata" would then
be potentially technically incorrect) and as soon as the
AttributeExtractor/@type="Metatdata" is involved I have (or the
deployer has) to touch shibboleth2.xml anway.
So probably not worth the effort.
-peter


More information about the dev mailing list