Multiple authentication levels for a single application

Morgan, Andrew Jason morgan at oregonstate.edu
Tue Aug 27 10:59:17 EDT 2019


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.

Andy

________________________________
From: users <users-bounces at shibboleth.net> on behalf of Guillaume Rousse <guillaume.rousse at renater.fr>
Sent: Tuesday, August 27, 2019 3:43 AM
To: users at shibboleth.net <users at shibboleth.net>
Subject: Multiple authentication levels for a single application

Hello list.

I'm currently experimenting with strong authentication requirements.
It's quite easy when a given application requires the same
authentication method for all its users, by having a
<samlp:RequestedAuthnContext> element inserted in the SAML request by
the SP, and letting the IdP compute which authentication flow matches
the request.

However, it seems a little more complex to have different requirements
for different user classes in a single application. Such a scenario
would for instance mandate MFA authentication for admins, while
password-based authentication would be enough for normal users. Whereas
I'm confortable with the access control implementation in the
application itself, I don't see how the let the user choose which
authentication method to use.

Either I need a way for the SP to issue two different kind of login
requests, each using a different content in
<samlp:RequestedAuthnContext> element, so as to have a single IdP select
the correct authentication flow accordingly. I guess using different
session initiators handlers, at different URLS, would be enough, but
then I'll need different authentication links/buttons in the application
( "login as user", and "login as admin").

Either I use two different IdPs, each implementing only one
authentication flow (password for one, MFA for the other), and I use a
discovery service for the user to select which one to use. In this case,
each IdP will always reply with the relevant authentication result,
whatever the content of the <samlp:RequestedAuthnContext> element,
meaning simplified SP configuration.

I can also imagine using a single IdP, with MFA flow, and a conditional
flow selection to automatically short-circuit the second factor
authentication for users not needing it, but then I'll need a way to
share the list of admins between the application and the IdP itself to
avoid duplication and incoherences.

Advices and suggestions welcome here.

Regards.
--
Guillaume Rousse
Pôle SSI

Tel: +33 1 53 94 20 45
www.renater.fr<http://www.renater.fr>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190827/dab8651f/attachment.html>


More information about the users mailing list