Forced Authentication with Shibboleth SP
Single sign-on (SSO) allows users to authenticate once against an Identity Provider (IdP), and get "automatically" logged into one or more Service Providers (SPs), without need to re-authenticate for a period of time determined by the length of the IdP's "session" (often taking the form of a cookie stored in the user's browser).
Some services require an additional layer of security. They require the user to enter their login and password every time they enter the application. This is typically due to the nature of the application - i.e. higher-risk data like payroll - and hence the SP can send a SAML AuthnRequest with a special forceAuthn
flag, like so:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_d7d60924682b543f51b9f6eb9810b75e"
IssueInstant=""2020-01-01T00:00:00Z"
Destination="http://idp.example.com/idp/profile/SAML2/Redirect/SSO"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="http://sp.example.com/Shibboleth.sso/SAML2/POST"
Version="2.0"
ForceAuthn="true">
<saml:Issuer>http://sp.example.com/shibboleth</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/>
<samlp:NameIDPolicy AllowCreate="1" />
</samlp:AuthnRequest>
In order to configure Shibboleth SP to generate this kind of request, there are two elements in shibboleth2.xml
that need to be adjusted:
<Sessions lifetime="28800" timeout="3600" relayState="ss:mem" maxTimeSinceAuthn="10"
checkAddress="false" handlerSSL="true" cookieProps="https">
First, in the <Sessions>
element, set the maxTimeSinceAuthn
parameter to some short interval. This checks that an actual username and password was entered in the last specified number seconds (the example here sets it to 10 seconds).
Next, in the <SSO>
block:
<SSO entityID="http://idp.example.com/idp/shibboleth" forceAuthn="true"
discoveryProtocol="SAMLDS" discoveryURL="https://ds.example.org/DS/WAYF">
SAML2 SAML1
</SSO>
add the forceAuthn
flag set with a value of true
.
Step Up Authentication
Note, that these settings can be applied in any application declaration, whether it be the default setting, or you utilize an ApplicationOverride
to establish a second, logical SP. The latter scenario is often utilized when employing "step-up" authentication.
For example, you may have one or more paths which you'd want to protect with an added layer of security. In this case, you can deploy an ApplicationOverride
that's also integrated with your partner IdP, and protect that content with the second application in Shibboleth. In terms of Apache config, it may look something like this:
<Location /secure>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting entityID http://idp.example.com/idp/shibboleth
require shib-session
</Location>
<Location /secure/supersecure>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting applicationId MyForceAuthnApp
ShibRequestSetting entityID http://idp.example.com/idp/shibboleth
require shib-session
</Location>
where you configure an ApplicationOverride
with the id MyForceAuthnApp
to have the relevant <Sessions>
and <SSO>
blocks above.
Looking for support for Shibboleth? Look no further! Contact us for all of you SSO support needs!