Is there a reason why you can't use use the Gateway feature of the CAS client/server?
It essentially sends a request to the CAS server. If the user authenticated with the CAS server, it sends a ticket back. Otherwise, it just sends the browser back to the application without displaying the login page. -Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Wed, Feb 25, 2009 at 5:05 PM, Chris Hatton <[email protected]>wrote: > 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 > > -- 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
