On Wed, Feb 25, 2009 at 5:30 PM, Chris Hatton <[email protected]>wrote:
> Actually, I wasn't aware of the Gateway feature. I just looked it up, and > I like it! Glad to hear that! ;-) -Scott > > > 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 > > -- 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
