I'm going to jump in here, forgive me for piggybacking on this thread... I posted a separate thread earlier in the week looking for PL-SQL examples or preferably Oracle forms and reports support -- can anyone point me in the right direction for documentation there? Best Regards, MG
________________________________ From: Andrew Feller [mailto:[email protected]] Sent: Wednesday, February 25, 2009 1:27 PM To: [email protected] Subject: Re: [cas-user] Simple support for a gradual migration to CAS Chris, What type of legacy applications are we talking about? Java, PHP, .NET, Python, Ruby on Rails? Can you elaborate more on the method you currently use for SSO / authentication? A- On 2/25/09 12:57 PM, "Chris Hatton" <[email protected]> wrote: You're pretty close, Andrew. I want my service application to be able to know how the user was authenticated (whether it was via CAS for our new apps, or via a legacy mechanism). Ideally, the service should be able to determine which authentication mechanism to utilize. In this way, my service application could continue to support users on legacy applications as well as our newer applications. I am definitely good with the restrictions on the CASTGC. I thought that I saw a few other cookies (but it's possible that Tomcat put those there for me). Unfortunately, we don't have the time/resources to unify all of our authentication mechanisms at this time. That's why I am trying to make just the one service smart enough to make the decision. -Chris On Wed, Feb 25, 2009 at 11:35 AM, Andrew Feller <[email protected]> wrote: Chris, So you want to have this converted application to be aware of both your legacy method (which is a cookie or some other scheme?) and CAS protected? Is this a Java application? We have deployed CAS in a similar situation, however we were able to do the work necessary to setup CAS to handle our legacy Identity Management solution behind the scenes. We are in the process of positioning CAS as the SSO / Authentication service for all of our new and legacy applications. The only cookie generated by CAS is the SSO cookie (CASTGC), which should never be visible to your applications in any form. If it was exposed to an application and the application was compromised, then someone could hijack CAS sessions and impersonate as someone else. I suppose my advice would be to make either your legacy system or CAS to be the primary entry point and do the work necessary to integrate the two systems there and keep your applications simple until you can phase out the older system. If you are being really adventurous and you can wing it (time and plausibility), you could work on some custom integration solution where CAS can respond to your legacy system. $0.02, A- On 2/25/09 12:13 PM, "Chris Hatton" <[email protected]> wrote: Hey everyone- We are in the process of rolling out CAS as our internal SSO mechanism, but it will only affect a subset of our existing web applications for the first release. Essentially, I need to CAS-ify one of our applications such that is aware of whether the user was authenticated by CAS (or one of our legacy mechanisms). My initial thought is to add a cookie at Login time via CAS asserting that the user was authenticated by CAS. This cookie would then be used by downstream CAS-ified apps to determine whether to request the CAS service ticket, or to use one of the other mechanisms. I considered one of the existing CAS cookies, but CAS and the service will not reside on the same fully-qualified domain. https://cas.mycompany.com http://service.mycompany.com I figured that I would set the new cookie at the base domain, i.e.: Request.Cookies.Add("*.mycompany.com <http://mycompany.com> <http://mycompany.com> <http://mycompany.com> <http://mycompany.com> ", authenticatedByCasCookie) Any thoughts on this approach and/or tips on how to extend CAS to support this? Thanks! -Chris Hatton -- Andrew Feller, Analyst LSU University Information Services 200 Frey Computing Services Center Baton Rouge, LA 70803 Office: 225.578.3737 Fax: 225.578.6400 -- 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
