Actually, I wasn't aware of the Gateway feature. I just looked it up, and I like it!
Here's the URL if anyone is interested -> http://www.ja-sig.org/wiki/display/CAS/gateway Thanks, Scott! -Chris On Wed, Feb 25, 2009 at 3:09 PM, Scott Battaglia <[email protected]>wrote: > 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 > > -- 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
