Shibboleth Developers

[<>]

So I realize now what my problem is (although I have not figured out the
fix exactly).  The instructions here:

https://spaces.internet2.edu/display/SHIB2/IdPBetaTest

Specify to configure Apache to password protect /Authn/RemoteUser, but
the web.xml file that is being deployed by the war enables basic
authentication by Tomcat (using Tomcat's username/password file).  I
disabled the Apache authentication, added an appropriate
username/password to the Tomcat file and I get to the next step of the
process, but then Shibboleth fails with:

edu.internet2.middleware.shibboleth.idp.authn.provider.RemoteUserLoginSe
rvlet

I think that's just a typo in the web.xml file and should have been
RemoteUserAuthServlet.

I have the authentication working based on the above changes I did.  And
I am now seeing SAML responses sent to my SP (that's not to say
everything is working yet, but I wanted to explain how I solved this
problem, in case anyone else is encountering it).

-----Original Message-----
From: 

 
[mailto:]
 
Sent: Thursday, September 20, 2007 1:52 PM
To: 

Subject: Beta IDP Authentication

I am trying to use the recommended authentication in the initial beta
instructions (although HTTP Auth will not be useful to me later).  I
verified that I had Apache configured correctly by testing the
authentication against a random directory (jsp-examples) being served by
Tomcat through the JK connector (I'm using Apache 2.0.* and the latest
modjk for Apache 2.0.*).  

When I try to access https://myserver/shib-idp/Authn/RemoteUser my
username/password is never accepted.  It behaves as if I am entering the
wrong username/password.  It is the same username/password that I tested
and verified above when protecting a simple directory.  Additionally the
error page I get for a failed authentication is being generated by
Tomcat, where as the error page generated when I input the wrong
username and password for a diffect directory is generated by Apache.  

Any idea what might be going wrong?  It doesn't seem like Shibboleth
should be involved in this failure, but the fact that the same
protection works fine for jsp-examples another mount served by Tomcat
makes me think there is something special about the Shibboleth servlet
endpoint that is causing an issue.