How to /Authn/RemoteUser with IdP 3.0

[Scott Koranda]

On Sat, May 16, 2015 at 6:00 PM, Kathy E. Wright <kewrig at clemson.edu> wrote:
> I cannot duplicate our current IdP 2.4 configuration which uses
> /idpAuthn/RemoteUser with Apache ajp_proxy to delegate authentication to our
> campus SSO portal as described here:
>
> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthRemoteUser
>
> In our test IdP v3, I have the following configuration:
>
> /opt/shibboleth-idp/idp.properties
>
> idp.authn.flows= RemoteUser
> idp.authn.flows.initial = RemoteUser
>
> Logs indicate REMOTE_USER is being used:
>
> 2015-05-16 17:37:05,610 - INFO
> [net.shibboleth.idp.authn.impl.RemoteUserAuthServlet:135] -
> RemoteUserAuthServlet will process REMOTE_USER, along with attributes [] and
> headers []

All that is necessary for that entry to be logged is that the servlet
is "loaded". Even if you did not set idp.authn.flows to "RemoteUser"
and set it, for example, to "Password", you would still see that entry
logged.

By itself that log entry does not indicate that the RemoteUser flow is
being used for a particular request.

>
> But we get the following error:
> [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:271] - Profile
> Action SelectAuthenticationFlow: No potential flows left to choose from,
> authentication will fail in the logs

Are you confident that the RemoteUser servlet is properly "protected"
by your campus SSO portal and that REMOTE_USER is being populated so
that the servlet can consume it?

During the flow is your browser directed to the campus SSO portal and
you are correctly authenticating, or is your browser never making it
to the campus SSO portal and instead the IdP is immediately sending it
back to the SP with the SAML error shown below?

As Scott C noted in his reply to you

http://marc.info/?l=shibboleth-users&m=142706776320231&w=2

you will see that error in the log file if the servlet does not pick
up anything from REMOTE_USER.

>
> From the browser we see the following error:
> Error from identity provider:
>
> Status: urn:oasis:names:tc:SAML:2.0:status:Requester
>
> Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
>
> Message: An error occurred.
>

If you are confident that the servlet is properly protected and
REMOTE_USER is being set for the servlet, then to also aid your
troubleshooting it will be helpful to know precisely what the
authentication request sent from your test SP to the IdP contains. You
can either turn up debugging for the IdP to log it or use a tool like
the SAML Tracer plugin for Firefox.

The reason to know what the SP is sending is that the SP request is
factored into the logic that the IdP uses to determine if it can
satisfy the request. The details of the logic are explained at

https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection

It is possible that the test SP you are using is making a specific
request that the IdP cannot satisfy with the "out of the box"
configuration for RemoteUser. The "out of the box" configuration is
explained at

https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationConfiguration

In short, the "out of the box" configuration has support for (assuming SAML2)

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
urn:oasis:names:tc:SAML:2.0:ac:classes:Password

If the SP is asking for something specific and it is not one of those
two, then the IdP cannot satisfy the request.

So it will be helpful to know whether or not the SP is asking for a
requested authentication context(s) and if so which one(s), or if the
SP has no requested authentication context.

Of course if you have not already done so, turning the log level up to
DEBUG will show more details about how the IdP is deciding it has "no
potential flows left to choose from."

Scott K