...
Before proceeding further, you should apply the appropriate rules in a development environment to ensure that existing access to your system is blocked by an appropriate rule when plain authentication is done. Having done so, you can proceed with the second half of the process.
Example Apache2 configuration:
| Code Block |
|---|
RedirectMatch ^/$ /secure
<Location /secure>
Authtype shibboleth
ShibRequireSession On
<RequireAll>
require authnContextClassRef https://refeds.org/profile/mfa
require valid-user
</RequireAll>
</Location> |
Requiring Use
Obviously the goal is not to simply block access, but to actually make sure users that access your system normally will automatically be prompted to use a second factor at the appropriate times. This is possible in SAML by including information in the request message that tells the IdP to do this for you. Specifically, you must include a <RequestedAuthnContext> element containing the desired <AuthnContextClassRef> value to use.
...
Note that when this strategy is involved, applications have the opportunity for flexible "step-up" models in which users may be forced to elevate their authentication strength based on the actions they perform. While that is also possible with URL-based schemes, that can be difficult with many application frameworks because of the way URLs may be overloaded by them for different functions.
Example Apache2 Configuration
| Code Block |
|---|
RedirectMatch ^/$ /secure <Location /secure> Authtype shibboleth ShibRequireSession On <RequireAll> ShibRequestSetting authnContextClassRef https://refeds.org/profile/mfa require authnContextClassRef https://refeds.org/profile/mfa require valid-user </RequireAll> </Location> |
Error Handling
The other requirement to make use of this feature is error handling. A properly configured IdP that does NOT support a value requested by the SP is obligated to return an error to the SP. Handling that case is the SP's responsibility. Generally a static error response is not going to be suitable for most applications because it's not simple to distinguish this particular error in a generic error template. The SP has a feature to redirect to an application script to handle errors with the script able to switch off of some of the query string parameters to detect the particular SAML status involved.
...