MFA flow with TOTP plugin

[Cantor, Scott]

On 5/28/21, 1:21 PM, "users on behalf of Phil Chapman" <users-bounces at shibboleth.net on behalf of phil.chapman at adept.co.uk> wrote:

> The SP triggering authentication is surely known, so is the absence of this value due to some limitation that I
> don't understand, or a bug?

Neither, it's an example. You populate what you need to populate.

>    2. If an SP didn't specify a preferred authentication method

SAML doesn't do "preferred" methods. There's required and there's "I don't care", nothing in between.

> during initiation of the login, then is there any way for the SP to discover afterwards whether or not TOTP was
> used? The idp.authn.TOTP.addDefaultPrincipals configuration property implies that
> urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken will be added to the results, but after successful 2FA
> the ShibAuthenticationMethod and ShibAuthnContextClass server variables still only show
> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

https://wiki.shibboleth.net/confluence/display/IDP4/AuthenticationConfiguration

"Note that if you associate more than one supportedPrincipal value with a flow, the IdP will ordinarily pick one at random to use as a SAML "result" when it builds an assertion, assuming the SP didn't request a specific one. If you need to guarantee that a particular one will be used as a default, you can assign "weights" to them in a map bean that's defined in the authn-comparison.xml file named shibboleth.AuthenticationPrincipalWeightMap"

>    3. Again with the attribute resolver <QueryTemplate>, is there any remotely similar substitute for the
> deprecated $resolutionContext.principalAuthenticationMethod parameter?

No, because there is no single value involved.

-- Scott