Edward,

There is one potential issue with your CAS Client configuration.  I apologize that I didn't see it before.  :-(

Your casUrlServerPrefix value is https://casserver:8443/CAS.  Was your war file names CAS.war or cas.war?  The default name is all lower case, and if your war file is cas.war, then you cannot refer to its endpoint as
https://casserver:8443/CAS.  It would have to be https://casserver:8443/cas.  Your web.xml fragment has two places with the URLs having uppercase CAS.

Adam

Edward Chen wrote:
Hi Scott,

Thank you for the suggestion. One thing I don't understand in your email 
about " a configuration error on the client side". Your "client side" 
means the application itself, not the CAS server??

I installed CAS 3.21 successefully in Tomcat and I have done nothing to 
any clients.

My application linked to CAS is an JSP application. Do I need to do 
anything about it before linking to CAS? I created a very simple test 
page -test.jsp. For the time being, I just want to redirect to open 
test.jsp after the CAS login. Do I need to do anything to test.jsp??

Edward

Scott Battaglia wrote:
  
If both of the TicketValidators are returning no response there may be 
a configuration error on the client side with regards to the server 
endpoint.  If you turn on DEBUG on the server and then try and log 
into the client, you should be able to see on the server any 
validation attempts.  If you see no ticket validation attempts, then 
the client is most likely misconfigured.

-Scott

On Mon, May 19, 2008 at 8:30 PM, Adam Rybicki <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:

    Edward,

    It's hard to tell what effect your cas.war file custom build may
    have on CAS itself.  Let's assume for the time being, that this is
    fine.

    Did you have a chance to look inside the Tomcat logs as the error
    message was suggesting?  Getting no response from CAS could be
    caused by a certificate error.  I looked at
    AbstractCasProtocolUrlBasedTicketValidator, and it is possible
    that this class would return null on a communication error with
    CAS server.  It logs the error and returns null.  Can you locate
    the log file?  I think that the CAS Client may be actually using
    the log file of your application.

    Adam

    Edward Chen wrote:
    
    Hi Scott and other experts,

    Hi,

    Just  a thought about this problem. I don't know if it will make a 
    difference.

    I think maybe the CAS in my tomcat  is different. Why?

    I deployed my CAS to Tomcat by other method - our own build.xml.

    CAS 3.2.1 is built with Maven 2.0.9. <http://2.0.9.> I generate cas.war not by Maven, 
    but by my build.xml

    The current problem seems to me that the CAS only talks itself and not 
    react to any applications. That is why there is

    "...The CAS server returned no response...." when CAS linking to an 
    application.

    What do you think?

    Edward


    Scott Battaglia wrote:
      
      
    Edward,

    Can you try using the CAS 20 filter and see if that works?

    -Scott

    On Fri, May 16, 2008 at 11:52 PM, Edward Chen <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 
    <mailto:[EMAIL PROTECTED]>> wrote:

        Here it's what I modify below. But it still doesn't work. I have the
        following exception. Can you tell what 's wrong with it? Anything
        wrong
        with my cas filter?? Please help--very urgent


         HTTP Status 500 -

        ------------------------------------------------------------------------

        *type* Exception report

        *message*

        *description* _The server encountered an internal error () that
        prevented it from fulfilling this request._

        *exception*

        javax.servlet.ServletException: The CAS server returned no response.
             
         org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:152)
             
         org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(AuthenticationFilter.java:103)

        *root cause*

        org.jasig.cas.client.validation.TicketValidationException: The CAS
        server returned no response.
             
         org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidator.java:162)
             
         org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:129)
             
         org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(AuthenticationFilter.java:103)

        *note* _The full stack trace of the root cause is available in the
        Apache Tomcat/5.5.25 logs._

        ------------------------------------------------------------------------


             Apache Tomcat/5.5.25



        ..........
        <filter>
            <filter-name>CAS Authentication Filter</filter-name>

        <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
                <init-param>
                  <param-name>casServerLoginUrl</param-name>
              <param-value>https://casserver:8443/CAS/login</param-value>
                </init-param>
                <init-param>
                  <param-name>service</param-name>

        <param-value>http://casserver:8080/Recruiting/test.jsp</param-value>
                </init-param>
                <init-param>
                  <param-name>serverName</param-name>
              <param-value>casserver:8080</param-value>
                </init-param>
              </filter>

              <filter>
                <filter-name>CAS Validation Filter</filter-name>

        <filter-class>org.jasig.cas.client.validation.Cas10TicketValidationFilter</filter-class>
                <init-param>
                  <param-name>casUrlServerPrefix</param-name>
              <param-value>https://casserver:8443/CAS</param-value>
                </init-param>
                <init-param>
                  <param-name>serverName</param-name>
              <param-value>casserver:8080</param-value>
                </init-param>
              </filter>

           <filter>
                 <filter-name>CAS HttpServletRequest Wrapper
        Filter</filter-name>

        <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>
           </filter>

          <filter-mapping>
              <filter-name>CAS Authentication Filter</filter-name>
              <url-pattern>/*</url-pattern>
          </filter-mapping>

          <filter-mapping>
              <filter-name>CAS Validation Filter</filter-name>
              <url-pattern>/*</url-pattern>
          </filter-mapping >

          <filter-mapping>
              <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
              <url-pattern>/*</url-pattern>
          </filter-mapping >
        .............


        Edward

        Adam Rybicki wrote:
        > Scott's right, of course.  The Thread Local filter is not needed for
        > what you need.  It becomes handy if you don't have access to the
        > HttpServletRequest.
        >
        > Adam
        >
        > Scott Battaglia wrote:
        >> On Fri, May 16, 2008 at 7:32 PM, Adam Rybicki
        <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]>
        >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
        >>
        >>     Edward,
        >>
        >>     Cross-posting to the wrong list (cas-dev) will not speed up
        a reply.
        >>
        >>     One thing you'll need is an additional filter.  Actually,
        two of
        >>     them, I think.  To make getRemoteUser() work, you'll need them
        >>     configured similar to this:
        >>
        >>       <filter>
        >>         <filter-name>CAS HttpServletRequest Wrapper
        Filter</filter-name>
        >>
        >>    
        <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>
        >>       </filter>
        >>
        >>       <filter>
        >>         <filter-name>CAS Assertion Thread Local
        Filter</filter-name>
        >>
        >>    
        <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class>
        >>       </filter>
        >>
        >>       <filter-mapping>
        >>         <filter-name>CAS HttpServletRequest Wrapper
        Filter</filter-name>
        >>
        >>         <url-pattern>/*</url-pattern>
        >>       </filter-mapping>
        >>
        >>       <filter-mapping>
        >>         <filter-name>CAS Assertion Thread Local
        Filter</filter-name>
        >>
        >>         <url-pattern>/*</url-pattern>
        >>       </filter-mapping>
        >>
        >>
        >>     What concerns me is that, while you are using the JA-SIG CAS
        >>     Client, the exception message you included appears to have come
        >>     from the Yale CAS Filter.  I don't think you need both.
        >>
        >>
        >> Adam beat me to it.  But you are including the configuration
        for the
        >> JASIG CAS Client but an error message from the Yale CAS client.
        >> That's impossible unless you have both of them configured, which I
        >> don't think has ever been tried.  I'd recommend just sticking with
        >> one of them.  If you merely wish to read the request.getRemoteUser,
        >> you also won't need the ThreadLocal filter either.
        >>
        >> -Scott
        >>
        >>
        >>
        >>     Adam
        >>
        >>     Edward Chen wrote:
        >>>     I installed CAS 3.2.1 and deployed successfully with LDAP
        in my
        >>>     Windows XP and Tomcat5.25. Now I want to link the simple jsp
        >>>     application in Tomcat to CAS. I modified the CAS filter in
        >>>     web.xml as bellow. If I comment out "CAS Validation Filter", I
        >>>     got redirected to CAS and passed CAS login and went back
        to the
        >>>     application. However, I got "null" value
        >>>     (<%=request.getRemoteUser()%>) in my test.jsp. It should be
        >>>     supposed to have the CAS login username. If I don't
        comment out
        >>>     "CAS Validation Filter", I got redirected to CAS and
        passed CAS
        >>>     login. But when CAS went back to the application, it
        throws out
        >>>     exception, something like "*exception*
        >>>     javax.servlet.ServletException: Unable to validate
        >>>     ProxyTicketValidator
        >>>     [[edu.yale.its.tp.cas.client.ProxyTicketValidator
        >>>     proxyList=[null]
        >>>     [edu.yale.its.tp.cas.client.ServiceTicketValidator ..... " It
        >>>     seems to me that the validation doesn't work. What is
        wrong with
        >>>     it? How to fix it? any recommendation?? any thing wrong
        with the
        >>>     following CAS filter?? Very urgent help needed!!! ........
        >>>     <filter> <filter-name>CAS Authentication Filter</filter-name>
        >>>    
        <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
        >>>     <init-param> <param-name>casServerLoginUrl</param-name>
        >>>     <param-value>https://xxxxxxxxx:8443/CAS/login</param-value>
        >>>     </init-param> <init-param> <param-name>service</param-name>
        >>>    
        <param-value>http://xxxxxxxxx:8080/Recruiting/test.jsp</param-value>
        >>>     </init-param> <init-param> <param-name>serverName</param-name>
        >>>     <param-value>xxxxxxx:8080/</param-value> </init-param>
        </filter>
        >>>     <filter> <filter-name>CAS Validation Filter</filter-name>
        >>>    
        <filter-class>org.jasig.cas.client.validation.Cas10TicketValidationFilter</filter-class>
        >>>     <init-param> <param-name>casUrlServerPrefix</param-name>
        >>>     <param-value>https://xxxxxxx:8443/CAS</param-value>
        >>>     </init-param> <init-param> <param-name>serverName</param-name>
        >>>     <param-value>xxxxxxxxxxx:8080/</param-value> </init-param>
        >>>     </filter> <filter-mapping> <filter-name>CAS Authentication
        >>>     Filter</filter-name> <url-pattern>/*</url-pattern>
        >>>     </filter-mapping> <!--filter-mapping> <filter-name>CAS
        >>>     Validation Filter</filter-name> <url-pattern>/*</url-pattern>
        >>>     </filter-mapping --> ...................
        >>>     ______________________________
        >>>     _________________
        >>>     Yale CAS mailing list
        >>>     [email protected] <mailto:[email protected]> <mailto:[email protected]>
        <mailto:[email protected] <mailto:[email protected]>>
        >>>     http://tp.its.yale.edu/mailman/listinfo/cas
        >>
        >>     _______________________________________________
        >>     Yale CAS mailing list
        >>     [email protected] <mailto:[email protected]> <mailto:[email protected]>
        <mailto:[email protected] <mailto:[email protected]>>
        >>     http://tp.its.yale.edu/mailman/listinfo/cas
        >>
        >>
        >>
        >>
        >> --
        >> -Scott Battaglia
        >> PGP Public Key Id: 0x383733AA
        >> LinkedIn: http://www.linkedin.com/in/scottbattaglia
        >>
        ------------------------------------------------------------------------
        >>
        >> _______________________________________________
        >> Yale CAS mailing list
        >> [email protected] <mailto:[email protected]> <mailto:[email protected]>
        >> http://tp.its.yale.edu/mailman/listinfo/cas
        >>
        > _______________________________________________
        > Yale CAS mailing list
        > [email protected] <mailto:[email protected]> <mailto:[email protected]>
        > http://tp.its.yale.edu/mailman/listinfo/cas
        >

        _______________________________________________
        Yale CAS mailing list
        [email protected] <mailto:[email protected]> <mailto:[email protected]>
        http://tp.its.yale.edu/mailman/listinfo/cas




    -- 
    -Scott Battaglia
    PGP Public Key Id: 0x383733AA
    LinkedIn: http://www.linkedin.com/in/scottbattaglia
    ------------------------------------------------------------------------

    _______________________________________________
    Yale CAS mailing list
    [email protected] <mailto:[email protected]>
    http://tp.its.yale.edu/mailman/listinfo/cas
      
        
        
    _______________________________________________
    Yale CAS mailing list
    [email protected] <mailto:[email protected]>
    http://tp.its.yale.edu/mailman/listinfo/cas

      
      
    _______________________________________________
    Yale CAS mailing list
    [email protected] <mailto:[email protected]>
    http://tp.its.yale.edu/mailman/listinfo/cas




-- 
-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
------------------------------------------------------------------------

_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
  
    

_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas

  
begin:vcard
fn:Adam Rybicki
n:Rybicki;Adam
org:Unicon, Inc.;Professional Services
adr:Suite 113;;3140 North Arizona Avenue;Chandler;AZ;85225;United States
email;internet:[EMAIL PROTECTED]
tel;work:+1-480-558-2400
tel;home:+1-310-265-8286
tel;cell:+1-310-980-2758
x-mozilla-html:FALSE
url:http://www.unicon.net/
version:2.1
end:vcard

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas

Reply via email to