Assuming you're not transmitting service tickets over a non-secure protocol, its a very low risk. If you are transmitting service tickets over non-secure mechanisms (i.e. http) then yes, you run the risk that someone can intercept it.
Moral of the story: don't run CAS or your CAS clients over non-secure protocols. If you're looking to validate remote host against the provided service url, I don't know if you can guarantee the remote host name will match in a clustered environment (I haven't actually tested this). You'd have to use some other mechanism probably (like certs). On Fri, Aug 2, 2013 at 11:13 AM, Ted Fisher <[email protected]> wrote: > Can someone help me understand how CAS assures that the host validating > a Service Ticket is the correct one? My thinking was that when a system > sends a request to validate an ST it must be the hostname from the defined > service. Is that not correct? I would think you would want that.**** > > ** ** > > The reason I’m concerned is because I accidentally found otherwise. While > setting up our CAS to release other attributes to certain services I was > trying the method of hacking casServiceValidationSuccess.jsp so they are > sent with the CAS authentication response (as a side note I’m curious about > other feedback regarding issues or concerns about using this method). I > wanted to test and see if the attributes were included. But, not being > much of a java programmer myself I thought I could spoof it more quickly / > easily from a browser. Using 2 PCs (actually 2 VMs on the same PC with > unique IPs) I authenticated to my defined service from one to generate an > ST and captured it from the CAS log. Then I included the ST in a browse > from the other PC to cas/serviceValidate for the service. This worked to > show me the CAS response so I could check that attributes were included > (they were J). The issue comes because when I first did this I thought > CAS would not validate a service from a system other than the host where > that URL lives. So, I had added an entry to /etc/hosts on the CAS server > to spoof it into thinking my PC was the service host (fine for my testing > environment and because I have control over hosts/DNS).**** > > ** ** > > But, when I did this again later I forgot to add the hosts file entry and > expected the cas/serviceValidate to fail. It did not and I still got the > attributes returned from CAS. **** > > ** ** > > Shouldn’t it be a security concern that I was able to do that from a host > other than the one housing the service?**** > > ** ** > > Your feedback is appreciated.**** > > ** ** > > Ted F. Fisher**** > > *Server Administrator* > > *Bowling Green State University* > > Information Technology Services**** > > 323 Hayes Hall**** > > Phone: 419.372.1626**** > > Email: *[email protected]***** > > [image: Description: BGSU]**** > > ** ** > > -- > 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
<<image001.gif>>
