Thank you. Will make sure I am doing all you've written prior to writing again.<div><br></div><div>Kathy<br><br>On Saturday, May 16, 2015, Scott Koranda <<a href="mailto:skoranda@gmail.com">skoranda@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, May 16, 2015 at 6:00 PM, Kathy E. Wright <<a href="javascript:;" onclick="_e(event, 'cvml', 'kewrig@clemson.edu')">kewrig@clemson.edu</a>> wrote:<br>
> I cannot duplicate our current IdP 2.4 configuration which uses<br>
> /idpAuthn/RemoteUser with Apache ajp_proxy to delegate authentication to our<br>
> campus SSO portal as described here:<br>
><br>
> <a href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser</a><br>
><br>
> In our test IdP v3, I have the following configuration:<br>
><br>
> /opt/shibboleth-idp/idp.properties<br>
><br>
> idp.authn.flows= RemoteUser<br>
> idp.authn.flows.initial = RemoteUser<br>
><br>
> Logs indicate REMOTE_USER is being used:<br>
><br>
> 2015-05-16 17:37:05,610 - INFO<br>
> [net.shibboleth.idp.authn.impl.RemoteUserAuthServlet:135] -<br>
> RemoteUserAuthServlet will process REMOTE_USER, along with attributes [] and<br>
> headers []<br>
<br>
All that is necessary for that entry to be logged is that the servlet<br>
is "loaded". Even if you did not set idp.authn.flows to "RemoteUser"<br>
and set it, for example, to "Password", you would still see that entry<br>
logged.<br>
<br>
By itself that log entry does not indicate that the RemoteUser flow is<br>
being used for a particular request.<br>
<br>
><br>
> But we get the following error:<br>
> [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:271] - Profile<br>
> Action SelectAuthenticationFlow: No potential flows left to choose from,<br>
> authentication will fail in the logs<br>
<br>
Are you confident that the RemoteUser servlet is properly "protected"<br>
by your campus SSO portal and that REMOTE_USER is being populated so<br>
that the servlet can consume it?<br>
<br>
During the flow is your browser directed to the campus SSO portal and<br>
you are correctly authenticating, or is your browser never making it<br>
to the campus SSO portal and instead the IdP is immediately sending it<br>
back to the SP with the SAML error shown below?<br>
<br>
As Scott C noted in his reply to you<br>
<br>
<a href="http://marc.info/?l=shibboleth-users&m=142706776320231&w=2" target="_blank">http://marc.info/?l=shibboleth-users&m=142706776320231&w=2</a><br>
<br>
you will see that error in the log file if the servlet does not pick<br>
up anything from REMOTE_USER.<br>
<br>
><br>
> From the browser we see the following error:<br>
> Error from identity provider:<br>
><br>
> Status: urn:oasis:names:tc:SAML:2.0:status:Requester<br>
><br>
> Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed<br>
><br>
> Message: An error occurred.<br>
><br>
<br>
If you are confident that the servlet is properly protected and<br>
REMOTE_USER is being set for the servlet, then to also aid your<br>
troubleshooting it will be helpful to know precisely what the<br>
authentication request sent from your test SP to the IdP contains. You<br>
can either turn up debugging for the IdP to log it or use a tool like<br>
the SAML Tracer plugin for Firefox.<br>
<br>
The reason to know what the SP is sending is that the SP request is<br>
factored into the logic that the IdP uses to determine if it can<br>
satisfy the request. The details of the logic are explained at<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection</a><br>
<br>
It is possible that the test SP you are using is making a specific<br>
request that the IdP cannot satisfy with the "out of the box"<br>
configuration for RemoteUser. The "out of the box" configuration is<br>
explained at<br>
<br>
<a href="https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationConfiguration" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationConfiguration</a><br>
<br>
In short, the "out of the box" configuration has support for (assuming SAML2)<br>
<br>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport<br>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password<br>
<br>
If the SP is asking for something specific and it is not one of those<br>
two, then the IdP cannot satisfy the request.<br>
<br>
So it will be helpful to know whether or not the SP is asking for a<br>
requested authentication context(s) and if so which one(s), or if the<br>
SP has no requested authentication context.<br>
<br>
Of course if you have not already done so, turning the log level up to<br>
DEBUG will show more details about how the IdP is deciding it has "no<br>
potential flows left to choose from."<br>
<br>
Scott K<br>
--<br>
To unsubscribe from this list send an email to <a href="javascript:;" onclick="_e(event, 'cvml', 'users-unsubscribe@shibboleth.net')">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br><br>-- <br>Sent from Gmail Mobile<br>