So Andrew, Assuming that I had to go this route, I was thinking of applying some after advice around the the Ticket Granting Cookie Generator.
Does that seem like the best place for a Joinpoint? Thanks, -Chris On Wed, Feb 25, 2009 at 1:51 PM, Chris Hatton <[email protected]>wrote: > Ooops, forgot to respond to the authentication part...all applications > authenticate via a shared store (in our database). > > -Chris > > > > On Wed, Feb 25, 2009 at 1:36 PM, Chris Hatton <[email protected]>wrote: > >> 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
