apache2/idp kerberos RemoteUserInternal with Password flow fallback
sahli at gyselroth.com
Fri May 29 05:34:36 EDT 2015
On 05/19/2015 2:57 PM, Cantor, Scott wrote:
>>Because then I get the RemoteUser flow immediately (right after
>>redirection from the sp) instead the Password flow.
>>How can I configure it to always execute the Password flow first and the
>>RemoteUser flow only with the _eventId_authn param?
>The order it tries them should be based on the order in the descriptor list. As long as the Password flow doesn't "fall into" the RemoteUser flow by
>returning something that turns into ReselectFlow, the other shouldn't run.
"order in the descriptor list" means "idp.authn.flows = Password|RemoteUser" ?
Or is there another way to order the flows?
With all configs I have tried, it always selects the authn/RemoteUser first.
And I don't see any Password flow releated logs and no "ReselectFlow".
2015-05-29 11:20:46,828 - DEBUG [net.shibboleth.idp.authn.impl.PopulateAuthenticationContext:158] - Profile Action PopulateAuthenticationContext: Installed 2 authentication flows into AuthenticationContext
2015-05-29 11:20:46,850 - DEBUG [net.shibboleth.idp.session.impl.PopulateSessionContext:131] - Profile Action PopulateSessionContext: No session found for client
2015-05-29 11:20:46,862 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByForcedAuthn:53] - Profile Action FilterFlowsByForcedAuthn: Request does not have forced authentication requirement, nothing to do
2015-05-29 11:20:46,872 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByPassivity:53] - Profile Action FilterFlowsByPassivity: Request does not have passive requirement, nothing to do
2015-05-29 11:20:46,883 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByNonBrowserSupport:53] - Profile Action FilterFlowsByNonBrowserSupport: Request does not have non-browser requirement, nothing to do
2015-05-29 11:20:46,896 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:241] - Profile Action SelectAuthenticationFlow: No specific Principals requested
2015-05-29 11:20:46,898 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:267] - Profile Action SelectAuthenticationFlow: No usable active results available, selecting an inactive flow
2015-05-29 11:20:46,898 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:309] - Profile Action SelectAuthenticationFlow: Selecting inactive authentication flow authn/RemoteUser
>Using multiple flows is always going to be harder than just using one custom flow with all of the features desired. Trying to orchestrate things through >code that doesn't really know what you're trying to achieve ends up creating as many problems any it solves. Code reuse is fine, but if you have the >ability to code things up, one login flow is always better than two.
Not the easiest solution, but maybe possible...
More information about the users