I didn't quite follow but I found a Powerpoint presentation on CAS
Proxies:

https://calnet.berkeley.edu/developers/developerResources/cas/CASProxyin
g.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.

 

-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

Reply via email to