<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When the profiles get to the login step, they do a step called CheckForInitialAuthentication, which you'll find in sso-abstract-flow.xml (and I realize now I never talked to you about it for CAS, which should be doing the same thing).<br></blockquote><div><br></div><div>Created an issue to add support for that to CAS flows:</div><div><a href="https://issues.shibboleth.net/jira/browse/IDP-761">https://issues.shibboleth.net/jira/browse/IDP-761</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyway, this all led to modifying the authentication flow so that if a session already exists when it runs, it does some extra steps, including optionally doing attribute resolution. The trigger was expected to be doing the initial authentication, because that gets a session created so that when the authn flow runs the second time, it will see that and trigger the attribute lookup.<br></blockquote><div><br></div><div>This is the bit I was missing. I saw that FilterFlowsByAttribute only does something meaningful in the presence of an existing IdP session, but that seemed useless to me. Now I see that I might be able to leverage that. I'll do some analysis and report back.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is all more theory for me than practice, but I thought about it primarily because it seems like you're trying to make the password part happen no matter what, and that mostly seems to do that for you, along with having it do the attribute lookup for you afterwards.<br></blockquote><div><br></div><div>Yes, I see that now. This seems like a promising approach.</div><div><br></div><div>M<a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank"></a><br>
</div><div><br></div></div></div>