Dave, You really need proxy callback URLs; that is, your polynymous application needs to authenticate on behalf of the user to other services using proxy CAS tickets?
Still a problem if you don't, but less problem to solve if only dealing with supporting the multiple service URLs and not multiple proxyCallbackUrls. How many brands are we talking about here? Six? Six hundred? Is it feasible to give *the login portion of* each brand its own path such that you could declare and map N instances of the Spring Security filters, one for each brand and therefore serverName ? Use a custom Filter to compute the request-based URLs and shove them into ThreadLocal such that your custom extension can read them from ThreadLocal where it needs them, since it doesn't have easy direct access to the ServletRequest? However, allowing the client to assert the serverName is theoretically dangerous and invites illicit delegated authentication to your application, cf. https://wiki.jasig.org/display/CASC/CASFilter . Best wishes, Andrew On 6/15/2011 3:52 PM, Dave Goodin wrote: > We have a grails web application that has multiple url's mapped to it > in order to provide client branding. > Were are using Spring Security Cas plugin to provide security. It in > turn has a dependency on the > com.springsource.org.jasig.cas.client:3.1.8 jar and uses the > Cas20ServiceTicketValidator. The ticket validator has a property > called proxyCallbackUrl that I want to be dynamic but currently it is > not. > > For example, client A accesses the site by https://www.clientA.com > <https://www.clienta.com/> and client B accesses the site by > https://www.clientB.com <https://www.clientb.com/>. I have configured > the CAS server service url's to correspond to these url's. > > My question is how can I configure a web app that services multiple > url's and the cas server to meet this need. I have been thinking that > maybe I could override the Cas20ServiceTicketValidator but haven't > been able to find a way to grab the URL a client is coming in on > because I don't have access to the HTTP request. > I have also been trying to think of a way to make the application > (regardless of the client URL) seem like a single application to the > CAS server. The downfall of our current design with this last idea is > that all of the branding logic we have implemented is based on the > client's url (and the client URL is a mandate by our business). > > Any guidance would be greatly appreciated. > -- > 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
