CAS Proxying and Web

childlikenumberSecurity

Nov 5, 2013 (3 years and 5 months ago)

66 views

CAS Proxying and Web
Services

The

somewhat

“easy

way”

Presented

By
:

Joseph

Mitola

Programmer/Analyst

Office

Of

The

Registrar

Application Inventory


Things to consider when CAS
-
enabling your applications

1)
Is your application a good candidate to act as a “CAS Proxier” or a
main application that calls one or more “CAS Proxies”?


Does it serve as a web application portal?


Is it a “main entry point” that references other “CAS
-
enabled”
applications?

2)
Is your application a good candidate to act as a “CAS Proxy”?


Does it provide a re
-
useable service?


Can a major function of your application be converted into a web
service? Or maybe many functions can be converted into a web service
API?

3)
Do both of the above apply?

4)
Is your application just a simple CalNet authenticated application?


Does NOT provide any re
-
useable services and/or does NOT serve as a
“main entry point” or portal.

Basic CAS Authentication


A user makes a request to your application


Your application returns a form with an action to post to CAS and the URL of the your application included so CAS can redirec
t b
ack to
your application


Your identity must be verified by CalNet.
<br/>

<form

method
="
get
"
action
="
https://auth
-
test.berkeley.edu/cas/login
">

<input

name
="
service
"
value
="
{your app's URL here}
"
type
="
hidden
">

<input

type
="
submit
"
value
="
Login using CalNet.
“ />

</form>


User is sent to CAS where they provide their CalNet authentication credentials.


If the CAS login is valid, CAS redirects back to your application with a CAS “ticket” in the query string of your application
’s
URL.


Your application then makes an HTTP post or get request to CAS (NOT a redirect) calling the serviceValidate method and provid
ing

the
“ticket” and “service” arguments.


https://auth
-
test/berkeley.edu/cas/serviceValidate?ticket=
“{ticket string received from CAS in previous
step}”
&service=
“{your application's URL}”


CAS verifies the ticket provided by your application and returns a success or failure status indication response in XML


<
cas:serviceResponse

xmlns:cas
=
“http://www.yale.edu/tp/cas”
>


<
cas:authenticationSuccess
>


<
cas:user
>{CalNet ID}</
cas:user
>


</
cas:authenticationSuccess
>

</
cas:serviceResponse
>


OR


<cas:serviceResponse
xmlns:cas
=
“http://www.yale.edu/tp/cas”
>


<cas:authenticationFailure
code
=
“INVALID_TICKET”
>


ticket 'ST
-
8
-
qmKXGzftOK12k4Pa1dgXPRWtGaEsIlGbdoX
-
20' not recognized


</cas:authenticationFailure>

</cas:serviceResponse>

CAS Proxy Authentication


Applications that implement CAS can be modified to use CAS Proxy with relatively few changes....


The bulk of the changes needed are to the main “entry point” application or portal and NOT so much to the application
or web service being proxied


The URL used by your “main entry
-
point application” to validate the ticket and the arguments sent to
CAS differ slightly


Basic CAS Login URL and Arguments


https://auth
-
test/berkeley.edu/cas/serviceValidate?ticket=
“{ticket string received from CAS}”
&service=
“{your
application's URL}”


CAS Proxy URL and Arguments


https://auth
-
test/berkeley.edu/cas/serviceValidate?ticket=
“{ticket string received from CAS}”
&service=
“{your
application's URL}”
&pgtUrl=
“{your proxy callback URL}”


When you add the pgtUrl argument to the serviceValidate method when making a request to CAS, you
will receive slightly different results


Not using the pgtUrl argument


<
cas:serviceResponse

xmlns:cas
=“http://www.yale.edu/tp/cas”>


<
cas:authenticationSuccess
>


<
cas:user
>{CalNet ID}</
cas:user
>


</
cas:authenticationSuccess
>

</
cas:serviceResponse
>


Using the pgtUrl argument


<
cas:serviceResponse

xmlns:cas
=“http://www.yale.edu/tp/cas”>


<
cas:authenticationSuccess
>


<
cas:user
>{CalNet ID}</
cas:user
>


<
cas:proxyGrantingTicket
>{proxy granting ticket IOU}</
cas:proxyGrantingTicket
>


</
cas:authenticationSuccess
>

</
cas:serviceResponse
>


CAS will independently contact the application specified by pgtUrl (pgtUrl is your “Proxy Callback URL”).
It MUST reside on a secure server with a valid VeriSign or RSA Authority SSL Certificate enabled


CAS Proxy Authentication


If your Proxy Callback URL is on the same application directory as your “main entry point” application, it can share applicat
ion

variables. Assuming this is the case, it can store the pgtIou/pgtId pair in an Application variable (e.g.
Application
(<value of
pgtIou
>) = <value of
pgtId
>) when CAS sends a request to it


Application(Request.QueryString.Item("pgtIou")) = Request.QueryString.Item("pgtId")


The main (Proxier) application retrieves the pgtId value from the Application variable stored by the pgtUrl and then makes an

HTTP post or get request to CAS calling the proxy method this time passing in the targetService and pgt arguments


https://auth
-
test/berkeley.edu/cas/proxy?targetService=
“{your proxy application URL}”
&pgt=
“{value of the
Application(<proxy granting ticket IOU>) variable}”


The main (Proxier) application retrieves the “real proxy ticket” from CAS


<
cas:serviceResponse
>


<
cas:proxySuccess
>


<
cas:proxyTicket
>PT
-
957
-
ZuucXqTZ1YcJw81T3dxf</
cas:proxyTicket
>


</
cas:proxySuccess
>

</
cas:serviceResponse
>


The main (Proxier) application makes either a SOAP
-
like web service request OR a Representational state transfer (REST)
request sending in the proxy application arguments along with the required proxyTicket argument.


The CAS Proxied application checks for the presence of a “proxyTicket” in it’s URL query string. If one exists, it makes an
HTTP post or get to CAS specifying the proxyValidate method.


https://auth
-
test/berkeley.edu/cas/proxyValidate?ticket=
“{the value of the proxyTicket in your proxy
application’s URL}”
&service=
“{your proxy application URL}”


CAS verifies the proxyTicket provided by the CAS proxied application and returns a success or failure status indication
response in XML


<
cas:serviceResponse

xmlns:cas=“http://www.yale.edu/tp/cas”>


<
cas:authenticationSuccess
>


<
cas:user
>{CalNet ID}</
cas:user
>


<
cas:proxies
>


<
cas:proxy
>{the proxy callback URL}</
cas:proxy
>


</
cas:proxies
>


</
cas:authenticationSuccess
>

</
cas:serviceResponse
>

A Visual Representation

A “real life” Example


The Hello World CAS Proxy Web Service


https://ordev.berkeley.edu/ProxyWebService/HelloService.asmx?WSDL

Sign On to “CAS Proxier”

Call Proxy from Main Application

If the proxy application handled
arguments, you would enter
those here

Clicking here calls the CAS
Proxy and sends a valid proxy
ticket along with any other
application specific arguments

Receive Proxy response without
leaving Main application

The text in blue is the returned response from the Hello World web service. Note that it
knows who I am and what CAS proxies has called it, even though the only argument I
sent it was a CAS proxy ticket. Also, note that I have never left the Main application.
The CAS proxied application response is embedded

Online Resources


Documentation on integrating CAS Authentication with Forms
Authentication in ASP.Net 2.0


https://calnet.berkeley.edu/developers/developerResources/cas/
ASP.NetCASAuth.pdf


http://www.ja
-
sig.org/wiki/display/CASC/CAS+Proxying+with+Classic+ASP


CAS Proxying with Classic ASP


http://www.ja
-
sig.org/wiki/display/CASC/CAS+Proxying+with+Classic+ASP


Tom O'Brien has an online demo on CAS Proxy
Authentication


https://students.berkeley.edu/osl/hellocas/MainApp.asp


Some excerpts from this presentation were taken from Tom
O'Brien’s documentation


http://studentstest.berkeley.edu/documentation/CASProcess.pdf