Follow up question: Marvin mention "There are few requirements for the proxy URL to validate correctly:" - Must be https scheme - The cert on the client must be trusted by the server - Client must return a 200 HTTP response
I think from my experience and the experience of others on this list (both recently and in the past which I found googling) a wild card cert does not satisfy the second condition of "The cert on the client must be trusted by the server" if the client app and the CAS server are on the same host. It must be host specific cert. Is this true and if so why? My SSL - "fu" is not strong enough for me to grasp the answer to this. -perry -----Original Message----- From: Koob, Perry B. [mailto:[email protected]] Sent: Friday, March 20, 2009 9:43 AM To: [email protected] Subject: RE: [cas-user] Configure CAS and SSL Got it. -----Original Message----- From: William G. Thompson, Jr. [mailto:[email protected]] Sent: Friday, March 20, 2009 9:41 AM To: [email protected] Subject: Re: [cas-user] Configure CAS and SSL On Fri, Mar 20, 2009 at 9:52 AM, Koob, Perry B. <[email protected]> wrote: > I didn't quite follow but I found a Powerpoint presentation on CAS Proxies: > > https://calnet.berkeley.edu/developers/developerResources/cas/CASProxying.ppt > > and I think I get it. > > > > So if I plan on implementing the dream of a single sign on with uportal I > need the CAS proxy, if I am just using CAS to authenticate individual apps > then I do not. Correct. But what a sweet dream it is! :) The generalized case for Proxy is anytime an application wants to consume 3rd party protected services on behalf of a user. The downstream services will need a way to know that the request is coming from an authenticated user. CAS Proxy is a way to do this without having to replay a users credentials or have some other secret key per service. The downstream service validates the Proxy Ticket with CAS and knows that the it is a proxied ticket from the calling application on behalf of the user. The downstream service decides if they will honor the proxy and then authorization and other business logic based on the user can proceed normally. Bill > > > > -perry > > > > From: Scott Battaglia [mailto:[email protected]] > Sent: Friday, March 20, 2009 8:36 AM > To: [email protected] > Subject: Re: [cas-user] Configure CAS and SSL > > > > > > On Fri, Mar 20, 2009 at 9:30 AM, Koob, Perry B. <[email protected]> wrote: > > I think I see. So CAS Proxying is like aliasing. User authenticates > against CAS and with CAS proxy the client thinks the use is someone else. > Important for database access kind of things, but not preferred behavior > with most web applications where you want the user who authenticated to be > used for authorizations. > > No, the downstream applications will always know who the user is. They'll > receive the additional information on how the user got there (i.e. from > https://my.rutgers.edu/proxy) and can decide whether to let a user into the > system based on that information in addition to any other authorization > decisions. > > -Scott > > > > > -perry > > -----Original Message----- > From: Marvin Addison [mailto:[email protected]] > > Sent: Friday, March 20, 2009 8:21 AM > To: [email protected] > Subject: Re: [cas-user] Configure CAS and SSL > >> Oh interesting. When is it appropriate/not necessary to use the >> proxyCallbackUrl? > > It's necessary and appropriate only in the case where you want your > CAS client to authenticate other services on the user's behalf -- this > is the CAS proxy feature. > >> I thought that was how your client apps knew the ticket is valid. > > The client knows the ticket is valid by sending a message to the > server. In the proxy case, the server additionally sends a message to > the client at the callback URL. There are few requirements for the > proxy URL to validate correctly: > - Must be https scheme > - The cert on the client must be trusted by the server > - Client must return a 200 HTTP response > > It is entirely possible for a proxying CAS client to authenticate > properly (validate its service ticket) and fail proxy ticket > validation (fail to get PGTIOU). > > M > > -- > > 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 -- 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
