Thanks Dmitriy, much appreciated. I'll give that a go tomorrow.
Matty On Monday, May 9, 2016 at 6:00:42 PM UTC+1, Dmitriy Kopylenko wrote: > > OK, as SS framework is interface-based and super flexible, you might need > to do it the following way: > > 1) Implement custom AuthenticationDetailsSource to get the “details” of > the dynamic service URL to the SS machinery: > https://github.com/spring-projects/spring-security/blob/master/core/src/main/java/org/springframework/security/authentication/AuthenticationDetailsSource.java#L25 > > You could see how the default one is implemented which simply uses the > service property: > https://github.com/spring-projects/spring-security/blob/master/cas/src/main/java/org/springframework/security/cas/web/authentication/ServiceAuthenticationDetailsSource.java#L83 > Your > implementation could do whatever is necessary. > > 2) And then you MUST inject this implementation into the > ‘CasAuthenticationFilter’ in order for it to take effect (the > AbstractAuthenticationProcessingFilter exposes the setter): > https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/authentication/AbstractAuthenticationProcessingFilter.java#L409 > > Please note that this is all in theory, and if this does not work as > advertised, you should abandon Spring Security altogether ;-)) > > Best, > D. > > On May 9, 2016, at 11:50 AM, Matthew <[email protected] > <javascript:>> wrote: > > Hello all, > > I am currently attempting to implement CAS authentication with dynamically > defined service URLs, since we have various domain mappings (for dynamic > theming) that point to the same application(s). > > We need url-a.com/ to work identically to url-b.com/, for example, and we > have made some progress towards this by overriding the *createServiceUrl* > method in CasAuthenticationEntryPoint (on the CAS client side of things). > Initially, we just returned a dynamically constructed String from the > HttpServletRequest, but it became apparent that further "behind the scenes" > processing was still directly referencing the properties file. > > Following on from that, we put a lot of effort into overriding the > ServiceProperties class. The key method (*getService()*) is final, and > cannot be overridden (which would have solved our problems immediately), so > we spent time in trying to implement our own ServiceProperties class and > attempt to change all references over to this via the xml config - but > again this failed. > > The latest attempt to at least get *something* working was to use the > public method *setService()* in ServiceProperties, and call it just > before we return from createServiceUrl in CasAuthenticationEntryPoint. This > proved to work in an isolated fashion: The behind-the-scenes processing > worked, and the dynamic domain/URL didn't pose a problem. *However*, > further examination proved that this method was setting the value of > *service* globally for all sessions, such that if user A visited the > login screen via domain A, and user B visited the login screen via domain B > - before user A had entered their login details - then authentication would > fail since user A continued to effectively authenticate against domain B. > We've basically created a race condition. > > Naturally, setting anything globally for what should essentially be an > individual solution is not ideal, but can anyone suggest a solution? > > Is there an aesthetically pleasing way of overriding the getService() > method in ServiceProperties? And, if so, would this actually solve what we > are aiming to do? > > Thanks in advance, > > > Matty > > > > -- > You received this message because you are subscribed to the Google Groups > "CAS Developer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/. > > > -- You received this message because you are subscribed to the Google Groups "CAS Developer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/a/apereo.org/group/cas-dev/.
