How to /Authn/RemoteUser with IdP 3.0

[Kathy E. Wright]

Thank you. Will make sure I am doing all you've written prior to writing
again.

Kathy

On Saturday, May 16, 2015, Scott Koranda <skoranda at gmail.com> wrote:

> On Sat, May 16, 2015 at 6:00 PM, Kathy E. Wright <kewrig at clemson.edu
> <javascript:;>> 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
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net <javascript:;>
>


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150517/3462bd72/attachment.html>