And thanks to Andrew too! Your attention to this mailing list is pretty outstanding--I think we all appreciate that.
-Chris On Wed, Feb 25, 2009 at 9:24 PM, Scott Battaglia <[email protected]>wrote: > > 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 > > -- 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
