MFA flow with TOTP plugin

[Phil Chapman]

Thanks Scott.  FWIW I'm working with a fresh install of v4.1.

After reading your reply I went through all the config files/options that I'd changed, and found the problem.  Following our earlier conversation about shibboleth.authn.JAAS.LoginConfigurations I'd ended up with a block in password-authn-config.xml like this...

<util:list id="shibboleth.authn.JAAS.LoginConfigurations">
    <bean id="RegularLogin" parent="shibboleth.Pair">
        <property name="first"><value>ShibUserPassAuth</value></property>
        <property name="second">
            <util:list>
                <bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
                <bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken" />
            </util:list>
        </property>
    </bean>
    <bean id="OtherLogin" parent="shibboleth.Pair">
        <property name="first"><value>ShibOtherLoginAuth</value></property>
        <property name="second">
            <util:list>
                <bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="my:other:authn:method" />
            </util:list>
        </property>
    </bean>
</util:list>

...and it appears that my custom JAAS credential validator was taking this to mean that it could produce a Subject with a TimeSyncToken context class principal.  Quite how it then got through the authn.properties setting...

idp.authn.Password.supportedPrincipals = \
    saml2/urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport, \
    saml2/my:other:authn:method

...I don't know, but as soon as I removed the (unnecessary, I now see) TimeSyncToken line from JAAS.LoginConfigurations, the IdP started behaving the way I wanted/expected.

Thanks again,
Phil.

-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: 21 July 2021 18:33
To: Shib Users <users at shibboleth.net>
Subject: Re: MFA flow with TOTP plugin

(And to clarify, the point of the weight map is NOT to affect what you get when you request PPT. That's not changeable. What it does is tell the IdP what to do when the SP provides no guidance and the IdP has two values to pick from, then it consults the weight map to pick the one to use, and why you typically would weight "better" stuff higher.)

-- Scott

On 7/21/21, 1:27 PM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

    The supportedPrincipals values look kosher, and so there is absolutely no way that Password running alone could return TimeSyncToken unless you deliberately manipulated something in code to alter things. If it reported TimeSyncToken, it ran a flow that produced a final Subject at the end that contains that Principal.

    Basically this is flat out impossible without deliberate subversion:
    " If I add a "RelyingPartyByName" override to relying-party.xml, specifying "defaultAuthenticationMethods" as ...TimeSyncToken for selected SPs, then that's what's always reported to those SPs, even if TOTP wasn't used."

    It is the case that you cannot have the SP request PPT or configure the IdP to act like the SP requested PPT and ever get anything but PPT or an error.That is dictated by the standard. So no, that's impossible to end up with TST in that case, but you should never need to have an SP request PPT so it doesn't matter.

    If the SP requests TOTP or a relying party rule says TOTP, it should get TOTP and that's all that should matter. But it will not get that if the IdP didn't run a flow producing a Subject with a TOTP context class principal.

    Perhaps you have XML lying around from pre-4.1 days with different settings for the flows.

    The default for Password and TOTP will be to populate the Subject with exactly what is claimed as supported, so it's automatic, and the MFA flow will just merge everything. You can't get TOTP out in that scenario without running TOTP then or during an earlier request, it's really that clear cut.

    -- Scott


    -- 
    For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!KGKeukY!jOtX2tCl8oHgr6CQQsOUepOWTZsh2CLm504A-CWeH5WQvB5BfKZN1xJAPcNRKow$ 
    To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-- 
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210726/9861a039/attachment.htm>