Enabling Shibboleth Attribute checker handler throws returns 404

Tue Oct 19 13:45:56 UTC 2021

* Kannan, Satheesh (ELS-CON) <s.kannan.1 at elsevier.com> [2021-10-19 15:24]:
> <Sessions>
> <Handler type="AttributeChecker" Location="/AttrChecker" template="attrChecker.html" attributes="eppn displayName" flushSession="true"/>
> </Sessions>

OK.

> Also, This page
> https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2063695997/ApplicationDefaults
> says Session Hook would be relative path

Well, relative to the vhost in this case. If you insisted I guess you
could put an absolute URL there but there should be no reason to do that.

> and changing sessionHook="/Shibboleth.sso/attrChecker.html" seems to
> be throwing different error as "we couldn't give you access via
> Institution". Do you have any idea Session Hook Value should be
> "/Shibboleth.sso/AttrChecker"?

When you configured the type="AttributeChecker" handler at the
Location="/AttrChecker" then yes, the attribute checker handler would
be available at /Shibboleth.sso/AttrChecker since the Location for the
Handler is relative to the Shibboleth handler.

> Is this possible to display attrChecker.html in case of successful login with IDP  to confirm and see  the attributes received successfully in user interface?
> Is there a way we can configure attribute checker for one specific IDP?

I think the simple answer to any questions wrt more advanced behaviour
of the attribute checker is that you can implement any logic you want
in your own code and then handle (or ignore) requests at will.

E.g. here's some PHP sample code to illustrate how such code could
look like:

<?php
if ( isset($_SERVER['eppn']) and isset($_SERVER['displayName']) ) {
    parse_str(html_entity_decode($_SERVER['QUERY_STRING']), $query);
    if ( isset($query['return']) ) {
        $return = $query['return'];
        if ( preg_match('/^https:\/\/some(-test)?\.example\.com\/.*$/', $return) ) {
            # Allowed return values: Send them on!
            header('Location: ' . $return);
        }
    }
}
?><!DOCTYPE html>
<!-- whatever you want to display if the conditional above fails -->

I.e., you test whatever you want to test for (above: for the presence
of eppn and displayName) and if the test is satisfied you redirect
them on to the originally requested URL.
If the conditional ('if') fails/falls through you handle that any way
you like. In the above example by rendering HTML/PHP as needed with
the necessary information, e.g. based on MDUI info and ContactPerson
content.

You'd make that code available on your web server any way you like
(using any API/language/framework of your choice), e.g. at
/sso-pre-check and then reference it as sessionHook="/sso-pre-check".

You don't configure nor use the Handler of type="AttributeChecker", at
all, then. (That's for when you can't use any code of your own and
need a simple method of keeping the attribute check out of your
application code.)

HTH,
-peter