authnContextClassRef for a specific url

[Peter Schober]

* Idar Borlaug <idar.borlaug at gmail.com> [2015-06-01 10:10]:
> I have tried to configure this in apache and in shibboleth2.xml with:

Jfyi: Note that with Apache httpd native configiuration directives are
recommended over use of the request mapper.

> <RequestMapper type="Native">
> <RequestMap>
> <Host name="domain.no">
> <Path name="/highsecurity" authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:HighSecurity />
> </Host>
> </RequestMap>
> </RequestMapper>
> 
> This works fine if you are not logged in, but if you have already got a
> shibboleth session it won't reauthenticate. Is there some way to force
> reauthentication or drop the already existing session?

There are two issues here, your current one about the above doing
nothing for/to authenticated users, and the "future" one of the SP not
"reauthenticating" users that fail authz:

The issue you're seeing already is that the above will only influence
SAML2 authn requests sent to an IDP. Obviously (?) if I already have
an SP session valid for that path the SP will not issue an
authentication request.

The second ("future") issue is that even if you added an access
control rule that enforced the authnContextClass you requested is in
the response from the IDP any requests that fail this requirement (do
not contain the authnContextClass you wanted) will be stuck with
failed authorization (HTTP 403).
Whenever authz fails the SP (or httpd) will not and cannot just resend
the subject to the IDP again, mostly because it has no way of
distinguishing that from properly failed authorization (i.e., when the
subject should not have access to the resource).

You could likely handle that with httpd configuration (catching HTTP
403 and handling them better, e.g. by giving subjects the means to end
their local session and request a new on from their IDP).

Or use the SP's AttributeExtractor and AttributeChecker or sessionHook
features (where your custom code would run "under" the protected path
with the specific authnContextClass) and invalidate the local session
if the authnContextClass is not there, either blindly redirecting to
the IDP used (this time certainly with an authn request containing
your authnContextClassRef), or by giving the subject an HTML page with
info, links to click on, etc.
-peter