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

GALLIANO Nicolas nicolas.galliano at dsi.cnrs.fr
Thu Jun 2 19:37:57 UTC 2022


Scott,

When you say  :
- " in your case this doesn't make any sense to bother with because you're starting with the wrong data to begin with. You are causing it to add a Principal that should not be there" :
==> 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. And i tried to "play" with the AuthenticationPrincipalWeightMap map only to change this strange behaviour.
So how "wrong data" (x500 principal ?) can "be there" ?

- " An MFA flow that only runs X509 and doesn't auto-add should be building a subject that only contains the supportedPrincipals of the X509 flow." :
 ==> it's what our mfa flow does. The mfa flow exit successfully and do not route to the password flow. The authn is well done. 
It's what do the "Profile Action FinalizeAuthentication " run after the "Profile Action X500SubjectCanonicalization" ?

- " Since that's not what it's doing, something has been incorrectly changed to conflict with that outcome, or you're running the Password flow in every case and it's including a result from that in the final merge." :
==> no password flow is used when x509 flow exit successfully. But now the authnContext is always PPT "by default".

- " For Password and X509, you typically just leave it, and it adds in whatever the supportedPrincipals are into the Subject as a default behavior that's generally correct. Password adds its values and X509 would add its values." : 
==> 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 ?

#### X509 ####
idp.authn.X509.supportedPrincipals = \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:X509, \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient

#### X509Internal ####
idp.authn.X509Internal.supportedPrincipals = \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:X509, \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient

#### MFA ####
idp.authn.MFA.supportedPrincipals = \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol, \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:Password
 

- " That's what's supported, that's not what's added to the result" :
==> So a principal not supported can be added to subject ?
In our case, the uniq flow defined is MFA. In default properties mfa does not support X509 principal. But the authentication works.
Is because x509 supported principals "extend" those already supported by the mfa flow ?

- "unless you change the defaults to tell it to auto-add them" : 
==> i don't know where and how i can do it. We use default idp and authn properties values :(

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.
I was supposing that the authn flow used indicated to the idp which factor to use and then what the authnContext was. 
But in our case not :(.
So if no defaultAuthenticationMethods nor AuthenticationPrincipalWeightMap are configured how can the idp choose ?
Is an incorrectly usage of the mfa flow can explain this strange behaviour ?

Thanks again (and sorry)  for the time spent with me.
nico

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

On 6/2/22, 12:21 PM, "users on behalf of Cantor, Scott via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    >    About the supported principals by the mfa flow, it's the same with this configuration :
>
>    That's what's supported, that's not what's added to the result 
> unless you change the defaults to tell it to auto-add them, which is not normally the right thing to do.

Specifically, the supportedPrincipals settings tell the system how to deal with requests that stipulate one of those values. When there's nothing requested, they *only* matter when the corresponding addDefaultPrincipals property for the flow is enabled, which it is not for MFA by default.

For Password and X509, you typically just leave it, and it adds in whatever the supportedPrincipals are into the Subject as a default behavior that's generally correct. Password adds its values and X509 would add its values.

An MFA flow that only runs X509 and doesn't auto-add should be building a subject that only contains the supportedPrincipals of the X509 flow.

Since that's not what it's doing, something has been incorrectly changed to conflict with that outcome, or you're running the Password flow in every case and it's including a result from that in the final merge.

-- 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/7fb842b7/attachment.p7s>


More information about the users mailing list