<div dir="ltr">Thanks for the quick response, I will remove the mapper feature in shibboleth2.xml and use apache.<br><br>I have full control over the page returned if the wrong login is used, i check the attributes in my application.<br><br>Would a javascript redirect to logout url with redirect to the same page be a good solution?<br>403 page -> redirect to shibboleth.logout?url= same url</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 1, 2015 at 10:42 AM Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Idar Borlaug <<a href="mailto:idar.borlaug@gmail.com" target="_blank">idar.borlaug@gmail.com</a>> [2015-06-01 10:10]:<br>
> I have tried to configure this in apache and in shibboleth2.xml with:<br>
<br>
Jfyi: Note that with Apache httpd native configiuration directives are<br>
recommended over use of the request mapper.<br>
<br>
> <RequestMapper type="Native"><br>
> <RequestMap><br>
> <Host name="<a href="http://domain.no" target="_blank">domain.no</a>"><br>
> <Path name="/highsecurity" authnContextClassRef="urn:oasis:names:tc:SAML:2.0:ac:classes:HighSecurity /><br>
> </Host><br>
> </RequestMap><br>
> </RequestMapper><br>
><br>
> This works fine if you are not logged in, but if you have already got a<br>
> shibboleth session it won't reauthenticate. Is there some way to force<br>
> reauthentication or drop the already existing session?<br>
<br>
There are two issues here, your current one about the above doing<br>
nothing for/to authenticated users, and the "future" one of the SP not<br>
"reauthenticating" users that fail authz:<br>
<br>
The issue you're seeing already is that the above will only influence<br>
SAML2 authn requests sent to an IDP. Obviously (?) if I already have<br>
an SP session valid for that path the SP will not issue an<br>
authentication request.<br>
<br>
The second ("future") issue is that even if you added an access<br>
control rule that enforced the authnContextClass you requested is in<br>
the response from the IDP any requests that fail this requirement (do<br>
not contain the authnContextClass you wanted) will be stuck with<br>
failed authorization (HTTP 403).<br>
Whenever authz fails the SP (or httpd) will not and cannot just resend<br>
the subject to the IDP again, mostly because it has no way of<br>
distinguishing that from properly failed authorization (i.e., when the<br>
subject should not have access to the resource).<br>
<br>
You could likely handle that with httpd configuration (catching HTTP<br>
403 and handling them better, e.g. by giving subjects the means to end<br>
their local session and request a new on from their IDP).<br>
<br>
Or use the SP's AttributeExtractor and AttributeChecker or sessionHook<br>
features (where your custom code would run "under" the protected path<br>
with the specific authnContextClass) and invalidate the local session<br>
if the authnContextClass is not there, either blindly redirecting to<br>
the IDP used (this time certainly with an authn request containing<br>
your authnContextClassRef), or by giving the subject an HTML page with<br>
info, links to click on, etc.<br>
-peter<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr">Idar Borlaug<div><br></div></div>