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 redirect back to your application  Your identity must be verified by CalNet. 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 providing the “ticket” and “service” arguments.  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  {CalNet ID} OR ticket 'ST-8-qmKXGzftOK12k4Pa1dgXPRWtGaEsIlGbdoX-20' not recognized

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 string received from CAS}”&service=“{your application's URL}”  CAS Proxy URL and Arguments 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 {CalNet ID}  Using the pgtUrl argument {CalNet ID} {proxy granting ticket IOU} 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 application variables. Assuming this is the case, it can store the pgtIou/pgtId pair in an Application variable (e.g. Application( ) = ) 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  proxy application URL}”&pgt=“{value of the Application( ) variable}” The main (Proxier) application retrieves the “real proxy ticket” from CAS  PT-957-ZuucXqTZ1YcJw81T3dxf 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.  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  {CalNet ID} {the proxy callback URL}

A Visual Representation

A “real life” Example The Hello World CAS Proxy Web Service 

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  ASP.NetCASAuth.pdf ASP.NetCASAuth.pdf  sig.org/wiki/display/CASC/CAS+Proxying+with+Classic+ASP sig.org/wiki/display/CASC/CAS+Proxying+with+Classic+ASP CAS Proxying with Classic ASP  sig.org/wiki/display/CASC/CAS+Proxying+with+Classic+ASP sig.org/wiki/display/CASC/CAS+Proxying+with+Classic+ASP Tom O'Brien has an online demo on CAS Proxy Authentication  Some excerpts from this presentation were taken from Tom O'Brien’s documentation 