Dashboard > CAS Clients > ... > Java Client > Yale Java Client > Using CASFilter
Log In   View a printable version of the current page.
Using CASFilter
Added by Andrew Petro , last edited by Scott Battaglia on Feb 01, 2007  (view change)
Labels: 
(None)


CAS Filter

The CAS filter is the simplest way of CAS-protecting your Java Servlets application.

Configuring CASFilter

Just a few lines of XML need to be added to your web application's deployment descriptor (web.xml):

<web-app>
  ...
  <filter>
    <filter-name>CAS Filter</filter-name>
    <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
    <init-param>
      <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
      <param-value>https://secure.its.yale.edu/cas/login</param-value>
    </init-param>
    <init-param>
      <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
      <param-value>https://secure.its.yale.edu/cas/serviceValidate</param-value>
    </init-param>
    <init-param>
      <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
      <param-value>your server name and port (e.g., www.yale.edu:8080)</param-value>
    </init-param>
  </filter>

  <filter-mapping>
    <filter-name>CAS Filter</filter-name>
    <url-pattern>/cas-protected/*</url-pattern>
  </filter-mapping>
  ...
</web-app>

In this case, any URL beneath /webapp/cas-protected would require a CAS login. If you want to protect your entire web application, you can simply put /* for the URL pattern:

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

The serverName initialization parameter does not require a port number if you are using the standard HTTP port (80).

You can specify other initialization parameters to configure the behavior of the filter:

Required CASFilter init-params

init-param name usage
edu.yale.its.tp.cas.client.filter.loginUrl The URL whereat CAS offers its Login page. e.g. https://secure.its.yale.edu/cas/login
edu.yale.its.tp.cas.client.filter.validateUrl The URL whereat CAS offers its service ticket or proxy ticket validation service. e.g. https://secure.its.yale.edu/cas/serviceValidate or https://secure.its.yale.edu/cas/proxyValidate . Must be a proxyValidate service if you intend to accept any proxy tickets.
edu.yale.its.tp.cas.client.filter.serverName This parameter specifies the server name and port of the service being filtered (not of the CAS Server itself). E.g., www.yale.edu:8080 Either this parameter or the serviceUrl parameter must be set.
edu.yale.its.tp.cas.client.filter.serviceUrl This parameter replaces the serverName parameter above. It becomes the URL that CAS redirects to after login. If you have one specific point of entry to your web application and you want all logins to proceed through that page, you would specify the full URL of that page here. Either this parameter or the serverName parameter must be set.

Optional CASFilter init-params

init-param usage
edu.yale.its.tp.cas.client.filter.proxyCallbackUrl to obtain a Proxy Granting Ticket and thereby have your application proxy authentication to other services, you'll need to specify an http: URL where you'd like PGT, PGTIOU pairs sent. This will typically be a URL you've mapped to an instance of the ProxyTicketReceptor servlet.
edu.yale.its.tp.cas.client.filter.authorizedProxy to allow the filter to accept proxy tickets, you need to specify valid proxies through which the authorization must have proceeded. This initialization parameter accepts a whitespace-delimited list of valid proxy URLs. Only one URL needs to match for the login to be successful. Note that if you do want to accept proxy tickets, you will have to change the validateUrl above to proxyValidate rather than serviceValidate
edu.yale.its.tp.cas.client.filter.renew if set to the string, true, this is the equivalent of authenticating a ticket with renew=true passed as a parameter. This may be used for high-security applications where the user must enter his/her credentials again before accessing the filtered URLs.
edu.yale.its.tp.cas.client.filter.wrapRequest if set to the string "true" the CASFilter will wrap the request such that calls to getRemoteUser() return the authenticated username.
edu.yale.its.tp.cas.client.filter.gateway see gateway

Consuming the results of CASFilter

Once the user has logged into your application through the filter, the application may access the user's name through the session attribute, edu.yale.its.tp.cas.client.filter.user, or if you import edu.yale.its.tp.cas.client.filter.CASFilter in your JSP or servlet, simply CASFilter.CAS_FILTER_USER.

Accessing the authenticated username from Java
// either of these will work:
session.getAttribute(CASFilter.CAS_FILTER_USER);
session.getAttribute("edu.yale.its.tp.cas.client.filter.user");
Accessing the authenticated username via JSTL
<c:out value="${sessionScope[CAS:'edu.yale.its.tp.cas.client.filter.user']}"/>

Additionally, the client application may access a CASReceipt JavaBean-style object which exposes the username as well as additional information about the successful authentication, in the session attribute edu.yale.its.tp.cas.client.filter.receipt .

// either of these will work:
session.getAttribute(CASFilter.CAS_FILTER_RECEIPT);
session.getAttribute("edu.yale.its.tp.cas.client.filter.receipt");

Session attributes set by CASFilter

Session attribute usage
edu.yale.its.tp.cas.client.filter.user String representing the authenticated NetID
edu.yale.its.tp.cas.client.filter.receipt CASReceipt representing the results of CAS authentication. Use this object to programmatically access the proxy chain, whether the authentication was required to have been by presentation of primary credentials, etc.

Read more about CAS Filter behavior.

Remember: If you are using JSTL with the CAS filter and need to get hold of the user's name through the
session attribute "edu.yale.its.tp.cas.client.filter.user". Then this
is how to do it:

<c:out value="${sessionScope['edu.yale.its.tp.cas.client.filter.user']}"/>

You need to use the above method because the usual way to access
session scope variables won't work because JSTL uses the dot as an
identifier, therefore:

<c:out value="${sessionScope.edu.yale.its.tp.cas.client.filter.user}"/>

wouldn't work.

I have just installed CAS and if I use the serviceUrl configuration, then I don't get back the "edu.yale.its.tp.cas.client.filter.user" session attribute. Also, I don't get back a remote user if I use the wrapRequest init-param. So, right now I can't get back the authenticated user name from the CAS server. What am I doing wrong?

I am not sure how to post this technical question so this may be in the wrong place.

this sort of question can be asked on the CAS discussion emial list:
http://tp.its.yale.edu/mailman/listinfo/cas

Standart applications use request.getRemoteUser(), so they cannot use CASFilter directly.
To fix this problem, i has write a small wrapper, that CASFilter use for set RemoteUser:

public class CASWrapper extends javax.servlet.http.HttpServletRequestWrapper {
        private String remoteUser=null;

        public CASWrapper(HttpServletRequest req)

Unknown macro: {             super(req);         }

        public void setRemoteUser(String user)
Unknown macro: {             remoteUser=user;         }

        public String getRemoteUser()
Unknown macro: {             return remoteUser;         }

}

This wrapper is used when CASFilter continue processing the request to chain:
// -- in CASFilter.doFilter(...) ---
        CASWrapper wrapper=new CASWrapper((HttpServletRequest)request);
        wrapper.setRemoteUser(receipt.getUserName());
        fc.doFilter(wrapper, response);
//------------

In the table above there is a note about the (optional) parameter:

edu.yale.its.tp.cas.client.filter.wrapRequest

if set to the string "true" the CASFilter will wrap the request such that calls to getRemoteUser() return the authenticated username.

Powered by a free Atlassian Confluence Open Source Project License granted to Java Architectures Special Interest Group. Evaluate Confluence today.
Powered by Atlassian Confluence 2.7.3, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators