Brian,

There are specific reasons that CAS clients are not recommended to rely on the HttpServletRequest to retrieve the host name.

This is documented here: http://www.ja-sig.org/wiki/display/CAS/CASFilter

All Java clients distributed by Yale rely on providing either a hostname specifically, or the exact service URL.

-Scott

Scott Battaglia
Application Developer, Architecture & Engineering Team
Enterprise Systems and Services, Rutgers University
v: 732.445.0097 | f: 732.445.5493 | [EMAIL PROTECTED]


Baz wrote:
Hi all,
I've been implementing acegi integration with Eduserv Athens[1] and
have been chatting to Luke about some oddities in the CAS integration
(Athens and CAS are quite similar, so I was getting up to speed by
browsing the code). A couple of these have been raised as bugs[2] but
there's other bits I'd like to ask about.

- is org.acegisecurity.ui.cas.ServiceProperties.get/setService() required?
It seems to me that this duplicates configuration elsewhere, since it
can only have the value that would be calculated by this method (if
you add this to CasProcessingFilter):
    public String getService(HttpServletRequest request) {
        int serverPort = request.getServerPort();
        String scheme = request.getScheme();
        StringBuffer sb = new StringBuffer(scheme);
        sb.append("://");
        sb.append(request.getServerName());
        if (!(serverPort == 80 && "http".equalsIgnoreCase(scheme))
                && !(serverPort == 443 && "https".equalsIgnoreCase(scheme))) {
            sb.append(":").append(serverPort);
        }
        sb.append(request.getContextPath());
        sb.append(getFilterProcessesUrl());
        return sb.toString();
    }

(incidentally a similar fragment to this is duplicated throughout the
acegi code, pretty much everywhere PortResolver is used?)

In the current setup, you can't use this code because
CasProxyTicketValidator.confirmTicketValid() doesn't get access to the
request. However, it's only called from
CasAuthenticationProvider.authenticateNow, which has access to
WebAuthenticationDetails constructed from the request, so the filter
can make this information available there?

The other thing I wanted to ask about isn't specific to CAS. I'd
extended AbstractProcessingFilter and implemented
AuthenticationEntryPoint as separate classes, much the same as all the
rest of the com.acegisecurity.ui packages. However I noticed that
these both required the same config information, and simply making a
single class that 'extends AbstractProcessingFilter implements
AuthenticationEntryPoint' took the entry point down to 2 lines of
code.

Looking at the other ui packages, it seems that there is a similar 1:1
correspondence between filters and entry points, with the duplicate
config issue being handled in different ways (Basic+Digest auth
delegates from the filter to the entry point, CAS uses
ServiceProperties to factor out the common code)

Looking at this, and the way that the 'Filter' classes aren't really
(the lifecycle methods arent used, and they're all marked 'do not use
directly') shouldn't all of these implement something like:

public interface AuthenticationFilter { // not a javax.servlet.Filter
    // each filter is its own entry point.
    public void commence(ServletRequest request, ServletResponse response,
        AuthenticationException authException)
        throws IOException, ServletException;
    // the acegi filters are all http-only.
    void doFilter(HttpServletRequest request, HttpServletResponse
servletResponse, javax.servlet.FilterChain filterChain) throws
java.io.IOException, javax.servlet.ServletException;
}

I can that in the code sometimes things identical interfaces have been
split for type safety (like AuthenticationEntryPoint and
ChannelEntryPoint) but I can't see why this argument hasn't been
applied to the Authentication Filters, since they can't be used as
servlet filters.

I've seen the 'servlet-container-managed' stuff in FilterToBeanProxy,
but to me this looks like something that can be taken as read from the
interface: *anything* that is a javax.servlet.Filter is container
managed by design, whereas anything that is derived from an acegi
filter-like interface isn't.

Anyhoo, thats *way* more than enough for a first message... sorry if
I'm rehashing old discussions.

Cheers,
Baz

[1] http://www.athensams.net , the blurb: de facto standard for secure
access management for UK Education and Health sectors, holds 3 million
user accounts from over 2,000 organisations and controls access to 260
online services. I'm doing this for one of those services.

[2] http://opensource2.atlassian.com/projects/spring/browse/SEC-228
http://opensource2.atlassian.com/projects/spring/browse/SEC-229


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=k&kid0944&bid$1720&dat1642
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

Reply via email to