3.3 SNAPSHOT: AuthN resolveAttribute not activating authn flow

[Cantor, Scott]

> FWIW, as an experiment I did also try to disable the filtering behavior of
> authentication results via the relevant property. Made no difference, sadly.

You're guaranteeing the result you want to apparently avoid if you don't filter the active results. Disabling filtering just makes it a guarantee that it will reuse the Password result. The default behavior is to honor the attribute and possibly not reuse the result, but in your case the filtering does not apply, so the question is why, but that has not changed in 3.3.

If you grab a snapshot from maybe three weeks back, you could try a test with that version.

> Is that behavior new to 3.3 by the way? Did the filtering of authn results
> always happen, or 3.3 just makes that configurable, or was that always there
> and I missed it?

https://issues.shibboleth.net/jira/browse/IDP-810

Fixed in 3.2.0 to make it it more aggressive and filter the results and not just the flows. It was defaulted to be more aggressive on the theory that all it would do is make SSO less likely.

> As far as I can tell, the password result in the authn context matches exactly
> in both cases.

I don't know what you're looking at, but the physical cause of the behavior is "the Subject inside the AuthenticationResult in the first case has more supported principals than the set configured statically for the Password flow in the second".

> The setup is fairly simple:
> 
> idp.authn.flows = Password|TB
> idp.authn.flows.initial = Password
> idp.authn.resolveAttribute = requiredAuthnCtx

None of that is relevant. The supported principals and what the Password flow is producing at runtime is what drives this.

> The authn/TB flow is an authentication flow that merges in the default
> principals plus an authn context class ref of http://example.org/q for
> instance. Could be anything. The “requiredAuthnCtx” attribute resolves to
> https://example.org/q

I don't know what you mean by "default" principals or merging. I think your flow may be broken, basically. If it's touching the result from the Password flow and supplanting that instead of producing its own result independently, that would cause the behavior I'm talking about. It would be changing what the Password flow originally produced and expanding its potential for reuse.

As an example, say the Password flow produced only the AuthnContextClassRefPrincipal for PasswordProtectedTransport. Then say another flow goes mucking with that and replaces that result with its own result containing an additional principal, but say it labeled it as belonging to authn/Password so it replaces the original. Then you'd have different behavior the next time in.

> If there is anything in particular in the logs that can help diagnose this, I am
> happy to share.

The whole log posted somewhere along with the general-authn-config file, but I think the underlying issue here is what that second flow is doing.

-- Scott