Logic for mfa-authn-config.xml
Les LaCroix
llacroix at carleton.edu
Thu Jan 11 12:17:40 EST 2018
>
> The second group would be applications that tailor the access they provide
> based on the type of authentication performed, perhaps later requesting
> (and requiring) MFA when sensitive/risky transactions are attempted.
Or where the institution knows that mfa correlates to another distinction
the application already makes; the application doesn't necessarily have to
make decisions based on the type of authN. It'd be nice, but one does not
always have that level of control/configuration over an app.
Use case: application X has some users with elevated access internally (the
application admins). By convention all those application administrators
have mfa available to them. They still want people without mfa to access
the application, because that's its main use.. But if you have mfa
available for some other reason, it's not a bad thing for you to have your
session mfa-protected. It's just not relevant to the application.
May I suggest some vocabulary for the second group: "mfa preferred", vs.
"mfa required".
-Les
------------------------------
Les LaCroix '79 | Strategic Technologist
Carleton College | 1 N. College St. | MS 3-ITS | Northfield, MN 55057
507.222.5455 | free/busy
<https://calendar.google.com/calendar/embed?src=llacroix%40carleton.edu&ctz=America/Chicago>
On Thu, Jan 11, 2018 at 11:00 AM, David Walker <dwalker at internet2.edu>
wrote:
> The second group would be applications that tailor the access they provide
> based on the type of authentication performed, perhaps later requesting
> (and requiring) MFA when sensitive/risky transactions are attempted.
>
> David
>
>
> On 01/11/2018 08:24 AM, Peter Schober wrote:
>
> * Paul B. Henson <henson at cpp.edu> <henson at cpp.edu> [2018-01-10 22:40]:
>
> Applications will fall into three groups; those that do not need MFA
> at all, those that will use MFA if available but still work with
> just a password otherwise, and those that strictly require MFA and
> will fail if it does not succeed. I'm not sure yet where this
> application delineation information will be stored.
>
> I may be restarting what Andrew and Tom already said but AFAIU that
> second group of service doesn't exist: Either the service requires MFA
> (and states that much in its request or in your local config) or it
> doesn't (meaning it will take what it gets).
>
> Not sure that helps (or is accurate) but maybe reducing the possible
> states to two (force MFA or don't) makes this easier for you?
>
> -peter
>
>
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180111/c94911e5/attachment.html>
More information about the users
mailing list