Interesting. At first blush though, that attack relies on a messed up virtual host setup, that doesn't 404 on an unrecognized host? I take your point though, specifying it separately is bulletproof against stupidity.
On 3/16/06, Scott Battaglia <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------- 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&kid0944&bid$1720&dat1642 _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
