It is JICS from Jenzabar; I haven't worked with it at all. In talking with our guy who is working on the authentication of it he made it sound like we couldn't do the normal CASification of a web application. I just explained things a little more to him and he is thinking he might be able to just do some redirection to CAS etc.; if that is the case, I have wasted your time in even asking the original question, sorry! I think we will try to approach it as a normal CASification and then go from there.
Thanks! - Ryan On Thu, Sep 17, 2009 at 8:45 AM, Scott Battaglia <[email protected]>wrote: > I'm not familiar with the application but how does it obtain the user? > > On Thu, Sep 17, 2009 at 10:41 AM, Ryan Andreasen <[email protected] > > wrote: > >> 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 >> >> > -- > 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
