X509Internal module and urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport AuthnContextClassRef

[GALLIANO Nicolas]

I have installed "from scratch" the 4.1.7. 
But you are right. 
The authn.properties was not loaded :(
After included it in the idp.additionalProperties ... the authnContext is "normal" even with the x509 flow
And the x509 principal must be supported by the mfa flow :).
All works fine (with samlrequest ppt, x509 auth requirements or not).
So sorry :(
Thanks for your help and explanations.
nico


-----Message d'origine-----
De : Cantor, Scott <cantor.2 at osu.edu> 
Envoyé : jeudi 2 juin 2022 22:17
À : GALLIANO Nicolas <nicolas.galliano at dsi.cnrs.fr>; Shib Users <users at shibboleth.net>
Objet : Re: X509Internal module and urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport AuthnContextClassRef

On 6/2/22, 3:38 PM, "GALLIANO Nicolas" <nicolas.galliano at dsi.cnrs.fr> wrote:

>    ==> How can i do that ? we "simply" have a x509Internal flow run in 
> an mfa flow. It works as in v4.0 but now the authnContext associated with this flow is PPT.

An upgraded IdP from 4.0 without a lot of other changes would not pay any attention to authn.properties at all, it's not included in older versions and is not loaded in an upgraded system without other changes. Yet you're looking at that. Either you're just confused about that, or you did not upgrade.

You should probably go back to 4.0 and the original config you had working, start over, upgrade to 4.2 in place, and then see what it does. I think you either upgraded incorrectly or tried to "freshen" the configuration to match the 4.1 defaults and changed it in the process.

> And i tried to "play" with the AuthenticationPrincipalWeightMap map only to change this strange behaviour.

It can change the response, but in the end the value is still part of the result and if an SP requested PPT for some reason, it would produce the wrong outcome. So you don't want to do that.

>    ==> so with this default properties the mfa flow should work fine 
> (with x509 or password flow run inside) and not using PPT authnContext when authenticated with the x509Internal flow ?

An upgraded IdP doesn't use authn.properties to begin with, but assuming it had been adjusted to do so, what you posted is not in fact totally correct, no. If you have the MFA flow calling the X509 flow, then you need to include the X509 flow's supportedPrincipals in the MFA flow's supportedPrincipals, because it's not going to handle requests properly unless you do (e.g, a request for one of the X509 contexts). I realize you aren't making those kinds of requests but you have to account for them.

But will that mistake cause it to include PPT? No, it wouldn't, not unless you made another change and told it to auto-add the MFA flow's supportedPrincipals into the result by changing idp.authn.MFA.addDefaultPrincipals, which is false by default. Or unless maybe you have old XML configuration lying around from before that is conflicting with the properties and was set to do that.

>    ==> So a principal not supported can be added to subject ?

It's possible, but not without unusual effort.

> In our case, the uniq flow defined is MFA. In default properties mfa 
> does not support X509 principal. But the authentication works.

If it was working, we wouldn't be having this conversation. Working includes producing the right results.

>    Is because x509 supported principals "extend" those already supported by the mfa flow ?

No, they don’t extend each other, it's because the values don't actively get in the way unless an SP requests something, a relying-party setting forces something, or you set the auto-add property for the flow.

    ==> i don't know where and how i can do it. We use default idp and authn properties values :(

You can't be unless you didn't actually upgrade or made a lot of other complex changes after upgrading. That's why it's not required to make those changes,  and why it's not a good idea to dive into updating files immediately. Upgrades don't require that extra step.

> What i don't understand is how the idp knows what kind of authnContext 
> used in the samlresponse if nothing is required in the samlrequest nor in the metadata.

It picks one at random from the values that are inside the Java Subject it builds.

> I was supposing that the authn flow used indicated to the idp which 
> factor to use and then what the authnContext was.

It can’t, flows can produce any number of possible values, so it has to pick only one to include in the response.

>    Is an incorrectly usage of the mfa flow can explain this strange behaviour ?

No, it's your configuration, and you should roll back to where you were, skip 4.1 and just go to the current version in place and evaluate from there.

Once you have a *working* upgraded 4.2 IdP, then you can spend time looking at the 4.1 changes that allow use of authn.properties, if you even care enough to do so. That's not that easy to do and can be error prone, and I imagine that's what happened here.

-- Scott


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6789 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20220602/844fea1f/attachment.p7s>