Multiple authentication levels for a single application

[Guillaume Rousse]

Le 27/08/2019 à 17:44, Guillaume Rousse a écrit :
> Le 27/08/2019 à 16:59, Morgan, Andrew Jason a écrit :
>> I haven't looked recently, but the InCommon certificate service app 
>> (run by Comodo) used the following methodology:
>>
>>  1. Send an authnRequest with no authnContextClassRef (or was it
>>     PasswordProtectedTransport?)
>>  2. After successful auth, lookup the user to see if MFA is required for
>>     this user
>>  3. If MFA is required for that user, send another authnRequest with the
>>     authnContextClassRef set to https://refeds.org/profile/mfa
>>
>> This allows the application to decide if MFA is required, and it uses 
>> SSO to avoid prompting the user for their password twice.
> That seems great.
> 
> I didn't considered the possibility for an application to chain multiple 
> authentication requests. Is there any documentation available somewhere 
> about how to implement this  ?
I tried this strategy, as it lets the application in full control of the 
process.

When connecting, the application issues a first authentication request, 
with just minimal 
'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport' 
authentication class requirement.

The IdP replies, asking the user for its password.

The application then issue a new authentication request, this time with 
'https://refeds.org/profile/mfa' authentication class requirement.

The IdP replies, this time requesting a second factor for the user.

In order to achieve this behaviour, tough, I had to ensure only the MFA 
flow was allowed, and to make it short-circuitable, using 
Programmatically Selecting Flows strategy documented on the wiki, so as 
to skip the second factor step if only password was required:

<bean id="checkSecondFactor"  parent="shibboleth.ContextFunctions.Scripted"
  factory-method="inlineScript">
   <constructor-arg>
     <value>
       <![CDATA[
// check current context
authCtx = 
input.getSubcontext("net.shibboleth.idp.authn.context.AuthenticationContext");
mfaCtx = 
authCtx.getSubcontext("net.shibboleth.idp.authn.context.MultiFactorAuthenticationContext");
if (mfaCtx.isAcceptable()) {
     nextFlow = null;
} else {
     nextFlow = "authn/Duo";
}
nextFlow;
]]>
     </value>
   </constructor-arg>
</bean>

Any attempt to avoid this kind of conditional strategy, and rely instead 
on builtin IdP authentication flow selection mechanism resulted in the 
user being presented password entry form twice, defeating the SSO 
purpose.  Whereas this behaviour is consistent with the MFA flow 
documentation, this seems quite cumbersome for something which looks 
like a trivial use case.

Regards.
-- 
Guillaume Rousse
Pôle SSI

Tel: +33 1 53 94 20 45
www.renater.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3637 bytes
Desc: Signature cryptographique S/MIME
URL: <http://shibboleth.net/pipermail/users/attachments/20190902/cb0d13f7/attachment.p7s>