Hi Leif, The Java CAS Client isn't currently designed to support multiple CAS servers simultaneously, so you're going to end up writing custom code for your use case unless you can accept declaring and configuring instances of the existing library multiply and differently for different per-customer paths, which as you point out has some scaling problems.
You might choose to live with those known problems. You will, after all, have to maintain this per-client configuration somewhere. Strictly speaking, you don't have to maintain the current configuration in web.xml -- you can wire up the CAS ticket validation components using Spring instead, or even make use of Spring Security's or Apache Shiro's CAS support. The login URLs differing per-customer aren't the hardest part of this integration problem. That's just a UI consideration in terms of where to redirect the request for authentication, and indeed you could be putting a link to that URL in whatever per-client login experience you're providing in your expense reporting application and avoiding configuring a login URL into CAS-related Java objects entirely. Depends on details of the CAS login user experience you're providing. Rather, the hardest part of this problem is in knowing, on the redirect back from CAS, which CAS server configuration to use to validate the presented service ticket, and in getting the service ticket validation machinery to use that correct-for-this-customer CAS server. You might trigger that off a request parameter (with custom code) or off a specific per-customer path (suitable for mapping in web.xml, and thus avoiding customization to the Java CAS Client.) Anyway. If you do end up customizing the Java CAS Client to support multiple CAS servers at once, I do hope you'll share the customizations. They might be of interest to other CAS-supporting SaaS providers, and indeed you might find willing collaborators on making these extensions. Kind regards, Andrew PS: Nice postcards. http://www.chromeriver.com/postcards/ On Tue, Oct 30, 2012 at 2:21 PM, Leif Bennett <[email protected]>wrote: > Hi! > > Our company provides a software service (expense reports) to multiple > customer organizations. We handle authentication several ways, and are > adding CAS for a particular customer. The Java client looks to work well > for this first customer, but we expect to have more CAS customers in the > future. Each of these would have their own independent CAS server. > > What's the right way to handle the situation where an application needs to > authenticate using CAS, but the CAS server login URL can be different for > each login attempt? We'd like to use the Java client if possible, with as > few modifications as possible. But we don't want to add a different filter > chain and login URL to web.xml for each customer; that doesn't scale > acceptably. > > I'd thought of having the servlet and filters configured to handle a > wildcarded URL, with the wildcarded part of the URI giving the customer > name; that would let a modified filter look up the correct server login URL > for this login. But the final keyword on doFilter() and non-dynamic server > login URL combine to prevent us from extending the existing filters. Is > there a better way than making our own slightly modified copy of them? > > I've looked over the docs and archives without finding a better answer. > > Leif Bennett > Chrome River Technologies > http://www.chromeriver.com > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
