authnContextClassRef for a specific url

[Idar Borlaug]

Thanks for the quick response, I will remove the mapper feature in
shibboleth2.xml and use apache.

I have full control over the page returned if the wrong login is used, i
check the attributes in my application.

Would a javascript redirect to logout url with redirect to the same page be
a good solution?
403 page -> redirect to shibboleth.logout?url= same url

On Mon, Jun 1, 2015 at 10:42 AM Peter Schober <peter.schober at univie.ac.at>
wrote:

> * 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
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-- 
Idar Borlaug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150601/dbd5ce1a/attachment.html>