Hey Andrew- We have several pre-existing ASP applications, and a few ASP.Net one's as well. Our new application is a Java Portal (and an existing ASP.Net web application).
Part of the complexity is that we are a hosted solution and need to be able to add additional functionality for some of our partners without interrupting others. -Chris On Wed, Feb 25, 2009 at 12:27 PM, Andrew Feller <[email protected]> wrote: > 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
