Re: [Unity-idm-discuss] Improvements MFA

[Sander A. <sa....@fz...>]

Hi Krzysztof,
sorry for the late answer. Last days were very busy.

On Mon, 2023-01-30 at 09:35 +0100, Krzysztof Benedyczak wrote:
> Hi Sander,
> 
> First of all thank you for that email. We will internally talk about
> it 
> more after the next release is out, but please find below some quick 
> comments.
> 
> W dniu 25.01.2023 o 08:56, Sander Apweiler pisze:
> > for the usage of MFA we want to provide some feedback. Some of this
> > things you already know.
> > 
> > - If OTP is wrong I have to redo the whole authentication. This
> > feels a
> > little bit annoying. On other platforms you just have to reenter
> > the
> > OTP, but not username & password.
> 
> Makes sense, though is more complex: this behavior makes sense for
> OTP 
> and maybe SMS as second factor, but completely not if say hardware
> token 
> (fido2) is used as second factor. But worth considering as credential
> dependent behavior. Shouldn't be big deal to be implemented.
Ok. I didn't had any time to test FIDO2. But I want to do.
> 
> > - Signalling MFA usage to SPs in common ways. There are already
> > some
> > common ways to signal the usage of MFA usage to services. This are
> > the
> > AuthnContextClassRef in SAML and the acr claim in OIDC. It would be
> > great if this is supported by unity, too.
> > - Proxying the MFA information from upstream IdP. If the upstram
> > IdP
> > already enables MFA and send the usage to services, MFA at unity
> > does
> > not increase the security anymore. Especially it the second factor
> > is
> > the same OTP generator. So it would be greate if there is a way to
> > transfer the information to the SPs of unity. I know we can build a
> > workaround but as you already mentioned storing information in
> > unity to
> > session bound attributes is not the best way.
> > - If the user enables MFA in unity but the upstream IdP already
> > preformed MFA, is would be great if there is a way for admins to
> > configure if unity performs MFA or not and just proxies the
> > information. As mentioned before there is no benefit if the second
> > factor is the same.
> 
> All 3 points above are mostly clear and true - a missing
> functionality 
> in Unity.
> 
> > - Have an additional authentication flow policy "step_up" which
> > does
> > not fall back to never, if the user has no MFA configured, but just
> > prohibits the operation/login.
> 
> Here I'm not sure if I understand. Do you mean that user needs to 
> provide two factors and if has only one set up then the authN fails? 
> Isn't that possible today?
We see "step_up" as something between required and never. This will be
only triggered if the user want to perform a "sensitiv" operation at a
connected service or within unity. To perform this operation the user
is send back to authentication and must perform a more secured
authentication using MFA. But this does not work if the policy switches
back to never, if the user has no MFA configured. In this case, the
user can not perform the step_up authentication and the authorization
fails. Hopefully it is more clear now.
> 
> > - Have different session lifetime for user who performed MFA. Since
> > the
> > MFA gives a better trust about the user account is not compromised,
> > it
> > would be nice if we can increase the session time for those user
> > who
> > authenticated with MFA. This would be a benefit for those, who are
> > doing the additional step.
> 
> Here I don't think this is a correct approach. What is the liking 
> between LoA and session lifetime? If any I'd say it is opposite: if
> you 
> are strongly authenticated, then you may potentially gain access to
> more 
> resources, and so your session should be shorter. But essentially I'd
> say there should be no dependency here.

In general I agree to you. Security is hard to combine with laziness or
"comfort" to users. This was one requirement by the management. If you
do not see this as a valid request, I'm fine.

Best regards,
Sander
> 
> Thank you a lot,
> Krzysztof
> 

-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

-----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens,
Prof. Dr. Astrid Lambrecht, Prof. Dr. Frauke Melchior
-----------------------------------------------------------------------
-----------------------------------------------------------------------