Re: [Unity-idm-discuss] signalling mfa usage

[Krzysztof B. <kb...@un...>]

Hi Sander,

W dniu 3.01.2023 o 15:14, Sander Apweiler pisze:
> Hi Krzysztof,
>
> On Tue, 2023-01-03 at 14:54 +0100, Krzysztof Benedyczak wrote:
>> Hi Sander,
>>
>> W dniu 3.01.2023 o 07:39, Sander Apweiler pisze:
>>> Dear Krzysztof,
>>> first of all happy new year and all the best for 2023.
>>>
>>> After enabling two factor authentication on our services, we want
>>> to
>>> signal the usage of it to the services. In SAML we want to use the
>>> https://refeds.org/profile/mfa in AuthnContextClassRef. In OIDC we
>>> want
>>> to use the acr claim. Is this possible within unity? I didn't find
>>> anything in the manual about setting AuthnContextClassRef or acr.
>> Unfortunately neither acr nor amr are not implemented in Unity as of
>> now. Same for SAML.
>>
>>> The second thing we are thinking about is proxying the information
>>> from
>>> the Upstream IdPs if there was 2FA used. I read that we can read
>>> the
>>> AuthnContextClassRef in SAML input translation profile.
>> Yes, it is exposed as an attribute in the context.
>>
>>
>>> Is there also
>>> an action which removes the old value, if this is not covered in
>>> the
>>> next login anymore?
>> Hm, I  don't understand the question. In general I don't think it is
>> possible to set AuthnContextClassRef in SAML response manually. It
>> should be possible to set manually acr in output profile for OAuth
>> AS,
>> although with some some extra work (i.e. one would need to put that
>> in
>> output profile + add to some scope, like profile).
> Let me try to explain it. When I store the value of the
> AuthnContextClassRef from remote IdP on an attribute and it signals
> that 2FA was used but the next login the AuthnContextClassRef is not
> released by the IdP anymore, I can not use the old value anymore and
> must assume that no 2FA was performed. Of course I can create some
> complex MVEL expression, but maybe there is an easier was to drop the
> old information if the AuthnContextClassRef is not send by the remote
> IdP anymore.

I would just overwrite the attribute each time setting it to what was 
provided or to some default value otherwise.

However, please keep in mind that, as we discussed long time ago, this 
is a generally imperfect workaround. Correctly, information on 
authentication context (from upstream IdP) should not be kept in an 
attribute but should be bound to login session and should be set there 
correctly on each authentication. This is very important if a given user 
can login both with remote IdP and with some local credential: in such 
case attribute storing authnContext from IdP will be there also after 
login with the local credential. So in general that's a bigger missing 
feature.

Best,
Krzysztof