We have pretty good control of the domain, but you are exactly correct, it is definitely not a good way to go with security. I will just tell our guys that we will have to come up with another solution. Thanks for the voice of reason for security, Scott. I appreciate your ideas on this problem.
On Thu, Sep 17, 2009 at 8:35 AM, Scott Battaglia <[email protected]>wrote: > I would not recommend changing the domain to .domain.edu, especially if > you're not in complete control of everything under .domain.edu. That's > just asking for a student to write some code to "borrow" someone's cookie > and have some fun. > > > On Thu, Sep 17, 2009 at 10:27 AM, Ryan Andreasen <[email protected] > > wrote: > >> We have new portal software for our University that has been purchased and >> our shop wants to make it SSO with our CAS server. The only thing is that >> the software is so proprietary all we can do are modify pieces of it here >> and there. So we don't have the ability to CASify it; all we can change are >> little portlets like the login portlet, etc. Our idea to CASify it was >> going to be in the login portlet to check for the existence of the TGT >> cookie; if it wasn't there show them a link asking them to login. If it was >> there, get the TGT and use the RESTful CAS API to get a service ticket and >> then validate the service ticket. The portal lives on a different server at >> a different path. So I was successfully able to change the TGT path from >> server.domain.edu to just .domain.edu, but since I can't change the the >> TGT path our portlet can't see the cookie. I noticed that the >> InitialFlowSetupAction is a final class, doesn't that mean it really isn't >> meant to be subclassed and replaced? >> >> I appreciate your help on this. >> >> - Ryan >> >> >> On Thu, Sep 17, 2009 at 8:16 AM, Scott Battaglia < >> [email protected]> wrote: >> >>> On Thu, Sep 17, 2009 at 10:14 AM, Ryan Andreasen < >>> [email protected]> wrote: >>> >>>> Thanks for your reply Scott. So it sounds like there is no way to >>>> change the cookie's path then, is that correct? >>>> >>> >>> Not unless you replace that InitialFlowSetupAction (if you want, you >>> could open a JIRA issue for us to expose a flag to turn off the >>> auto-config). Is there a particular reason you want to change the cookie >>> path scope? >>> >>> Cheers, >>> Scott >>> >>> >>>> >>>> On Wed, Sep 16, 2009 at 7:29 PM, Scott Battaglia < >>>> [email protected]> wrote: >>>> >>>>> We actually do that on purpose because the cookie should be scoped as >>>>> minimally as possible so we have it set on the first request (because >>>>> Servlet 2.4 doesn't have the ContextPath on the ServletContext) in order >>>>> to >>>>> do autoconfiguration (we also didn't just want to assume everyone deployed >>>>> to /cas). Once Servlet 2.5 is more popular (and maybe its popular >>>>> enough?) >>>>> we can access the servlet context from within the Spring Application >>>>> Context >>>>> and set it in the config via that, this way people can change it there if >>>>> they really wanted to. Our goal is to make sure its always set to the >>>>> proper context path. >>>>> >>>>> Cheers, >>>>> Scott >>>>> >>>>> >>>>> On Wed, Sep 16, 2009 at 6:57 PM, Ryan Andreasen < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> I noticed in the spring-configuration folder that there is a >>>>>> ticketGrantingTicketCookieGenerator.xml file. It looks like this file >>>>>> is >>>>>> used to set properties of the TGT cookie such as name, cookie age, >>>>>> path, and >>>>>> domain. >>>>>> >>>>>> I have been playing around with changing the domain & path. By >>>>>> changing the >>>>>> values in that file for the domain, CAS honors it and sure enough >>>>>> creates >>>>>> the TGT for the domain specified. However, if I change the path in >>>>>> the >>>>>> ticketGrantingTicketCookieGenerator.xml, CAS still creates the cookie >>>>>> with a >>>>>> path of "/cas", not what I specified in the xml file. I am using CAS >>>>>> 3.3.1. >>>>>> Is this desired, or a bug? It looks like there is a class >>>>>> "InitialFlowSetupAction" that sets the path also/instead, but I don't >>>>>> really >>>>>> see what it is doing. >>>>>> >>>>>> Any comments are GREATLY appreciated. >>>>>> >>>>>> Thanks! >>>>>> -- >>>>>> View this message in context: >>>>>> http://www.nabble.com/Changing-TGT-Cookie-Path-tp25482399p25482399.html >>>>>> Sent from the CAS Users mailing list archive at Nabble.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 >>>>> >>>>> >>>> -- >>>> 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 >>> >>> >> -- >> 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 > > -- 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
