3.3 SNAPSHOT: AuthN resolveAttribute not activating authn flow

[Misagh Moayyed]

I can't say whether it should or shouldn't based on that information. By default, the filtering action applies to both flows and results, meaning it will filter out the Password result if and only if the attribute values don't include a value that matches it. 
FWIW, as an experiment I did also try to disable the filtering behavior of authentication results via the relevant property. Made no difference, sadly. 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? 


That implies that the Password result is not the same as the static description of the Password flow's supported principals. The result must have more inside the Subject in the first case vs the second. 
As far as I can tell, the password result in the authn context matches exactly in both cases. 


Maybe at least with the password configuration I could take a stab at it. Shouldn't matter that much what the secondary flow is, I just need to set up the primary the way you are and know what the attribute value(s) are for the user. 

There also seems like a ton of logging elided there. 
The setup is fairly simple:

idp.authn.flows = Password|TB
idp.authn.flows.initial = Password
idp.authn.resolveAttribute = requiredAuthnCtx

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

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161024/617983fa/attachment.html>