MFA and authn/OIDCRelyingParty as second factor

[Pierre SAGNE]

Le 25/10/2024 à 16:25, Philip Smart via users a écrit :
>> Hi,
>>
>> I am currently trying to use the MFA in the following way :
>>
>> * First, authenticate with authn/Password (LDAP) (first factor)
>>
>> * then, use authn/OIDCRelyingParty to delegate authentication to another
>> OP which can use some more secure authentication (like TOTP and other
>> things) (second factor)
>>
>> * finally I want to make sure that the identiy of the user is the same
>> in my first factor and my second factor, and it is where things are more
>> complicated.
>>
>> I have a "mail/email" attribute which i can compare in both IdPs.
>>
>> I try to do it inside a MFA strategy, after my authn/OIDCRelyingParty
>> authentication.
>>
>> The problem is that the principal I get using
>> usernameLookupStrategy.apply(input) in my strategy is modified after the
>> authn/OIDCRelyingParty authentication (it is now the sub I received).
> Yes, the second authentication flow (OIDCRP) is overwriting the SubjectCanonicalizationContext the Password flow set. Hence the principalName that strategy pulls out is now based on the OIDCRP flow, and not the Password flow. All the subjects (and Principals e.g., UsernamePrincipal) are stored in an authentication result for each authentication flow, so what comes out of each flow is not lost, but that context is effectively re-used.
> After MFA has been completed, the authentication results (and Principals) are merged and a new SubjectCanonicalizationContext is sent through a final C14N step to give you the final principal.
>
>> So I can no longer resolve my LDAP mail address.
> Can you resolve those just after the first step using the correct principal? Otherwise, you might need a lookup strategy that pulls the principal from the Subject contained in the AuthenticationResult from the Password flow (although somebody may have a better idea than that).
Yes, if I trigger a strategy just after the first step, I have the right 
principal, and can resolve my mail attribute from the LDAP
>
>> And I cannot resolve my "upstream_mail" either, which is defined like this :
>>
>> ??? <AttributeDefinition id="upstream_mail"
>> xsi:type="SubjectDerivedAttribute" principalAttributeName="email"/>
> My understanding is the SubjectContext (where the SubjectDerivedAttributes come from) is created after all authentication flows have been completed (which includes the MFA flow). I did not think this existed during MFA.
>
>> The problem only occurs inside the MFA post second factor strategy though.
>>
>> If I do the exact same thing inside a context check interceptor, I get
>> the right principal and both my attributes are correctly resolved : mail
>> from LDAP and upstream_mail from the OIDC OP.
>>
>> Is there a subtlety I am missing if I want to do it inside a MFA
>> strategy (which would be cleaner for my use case), or is doing it inside
>> the context check interceptor my only solution?
> I realise I’ve not helped you find a solution. I’d need to think more about that.
Thanks a lot. I'll go with the context check interceptor for now. It can 
work like this if I don't have to something else after. But I'd like to 
do it inside the MFA, to be able to abort as soon as possible if I 
detect that it's not the same user.
>
>> Best regards,
>>
>> --
>> Pierre Sagne.
> Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under company number. 05747339, VAT number GB 197 0632 86. Jisc’s registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.
>
>
> Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.
>
>
> Jisc Commercial Limited is a wholly owned Jisc subsidiary and a company limited by shares which is registered in England under company number 09316933, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800.
>
>
> For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice