Accessing different locations of the same SP

[Peter Schober]

* SAMUELE RILLI <samuele.rilli at unicam.it> [2016-09-01 12:31]:
> I set up a Shibboleth IdP 3.2.1 and a Shibboleth SP 2.5.4.
> The SP is configured to protect some locations, such as:
> https://sp.url/level1
> https://sp.url/level2
> 
> Each location is bound to a different custom authnContextClass: level1
> requires user-pwd, level2 requires user-pwd and OTP.
> Now, the authentication works on both locations, but once I'm authenticated
> to a level I can access any level in that SP. Instead, in my scenario, I am
> not supposed to access an higher level of authnContextClass: when
> authenticated to level1 I must re-authenticate in order to access level2.
> Is it possible to force this kind of behavior?

Requesting a specific authncontext is not the same thing as
implementing access control at a given resource, you need both.
E.g. (Apache httpd): require Shib-AuthnContext-Class <your-URI>

You can also map just the authclass to a custom internal attribute and
then perform access control on that, e.g. (in shibboleth2.xml):
  <AttributeExtractor type="Assertion" AuthnContextClassRef="authclass" />
and then in your Apache httpd config:
  require authclass <your-URI> <another-URI>

https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeExtractor#NativeSPAttributeExtractor-AssertionAttributeExtractor(Version2.5andAbove)

Once you enforce access control only subjects with the correct
authclass can access the resource. If the implied hierarchy between
"level1" and "level2" in your example represents an actual hierarchy
you may want to allow subjects coming in with an authclass of level2
to access resources only requiring level1 access as well.

But failing authorisation here of course means generating an HTTP 403
Forbidden error. It's up to you to create an appropriate error
message, using the Shib SP's error templates or httpd configuration,
to allow subjects to send another authn request with a
specific/"higher" authclass, instead of just leaving them stranded
with "access denied".

One way would be offering a link on the "access denied" page that
triggers a new authn request with a specific authclass that the
subject would have to follow.

Another may be making use of the SP's AttributeChecker handler with
flushSession="true" (or sessionHook, for integration of more complex
custom code), which nullifies a local SP session if certain
requirements are not met. That could then be used to trigger a new
authn request with the appropriate authclass requested.

-peter