CAS Proxying and Web Services The somewhat “easy way” Presented By: Joseph Mitola Programmer/Analyst Office Of The Registrar
Application Inventory n 1) Things to consider when CAS-enabling your applications Is your application a good candidate to act as a “CAS Proxier” or a main application that calls one or more “CAS Proxies”? ¡ ¡ 2) Is your application a good candidate to act as a “CAS Proxy”? ¡ ¡ 3) 4) Does it serve as a web application portal? Is it a “main entry point” that references other “CAS-enabled” applications? 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? Do both of the above apply? Is your application just a simple Cal. Net authenticated application? ¡ Does NOT provide any re-useable services and/or does NOT serve as a “main entry point” or portal.
Basic CAS Authentication n n n 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 Cal. Net. <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 Cal. Net. “ /> </form> User is sent to CAS where they provide their Cal. Net 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 service. Validate method and providing the “ticket” and “service” arguments. ¡ https: //auth-test/berkeley. edu/cas/service. Validate? 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: service. Response xmlns: cas=“http: //www. yale. edu/tp/cas”> <cas: authentication. Success> <cas: user>{Cal. Net ID}</cas: user> </cas: authentication. Success> </cas: service. Response> OR <cas: service. Response xmlns: cas=“http: //www. yale. edu/tp/cas”> <cas: authentication. Failure code=“INVALID_TICKET”> ticket 'ST-8 -qm. KXGzft. OK 12 k 4 Pa 1 dg. XPRWt. Ga. Es. Il. Gbdo. X-20' not recognized </cas: authentication. Failure> </cas: service. Response>
CAS Proxy Authentication n Applications that implement CAS can be modified to use CAS Proxy with relatively few changes. . ¡ n 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 n ¡ CAS Proxy URL and Arguments n n https: //auth-test/berkeley. edu/cas/service. Validate? ticket=“{ticket string received from CAS}”&service=“{your application's URL}”&pgt. Url=“{your proxy callback URL}” When you add the pgt. Url argument to the service. Validate method when making a request to CAS, you will receive slightly different results ¡ Not using the pgt. Url argument n ¡ <cas: service. Response xmlns: cas=“http: //www. yale. edu/tp/cas”> <cas: authentication. Success> <cas: user>{Cal. Net ID}</cas: user> </cas: authentication. Success> </cas: service. Response> Using the pgt. Url argument n n https: //auth-test/berkeley. edu/cas/service. Validate? ticket=“{ticket string received from CAS}”&service=“{your application's URL}” <cas: service. Response xmlns: cas=“http: //www. yale. edu/tp/cas”> <cas: authentication. Success> <cas: user>{Cal. Net ID}</cas: user> <cas: proxy. Granting. Ticket>{proxy granting ticket IOU}</cas: proxy. Granting. Ticket> </cas: authentication. Success> </cas: service. Response> CAS will independently contact the application specified by pgt. Url (pgt. Url is your “Proxy Callback URL”). It MUST reside on a secure server with a valid Veri. Sign or RSA Authority SSL Certificate enabled
CAS Proxy Authentication n n n 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 pgt. Iou/pgt. Id pair in an Application variable (e. g. Application(<value of pgt. Iou>) = <value of pgt. Id>) when CAS sends a request to it ¡ Application(Request. Query. String. Item("pgt. Iou")) = Request. Query. String. Item("pgt. Id") The main (Proxier) application retrieves the pgt. Id value from the Application variable stored by the pgt. Url and then makes an HTTP post or get request to CAS calling the proxy method this time passing in the target. Service and pgt arguments ¡ https: //auth-test/berkeley. edu/cas/proxy? target. Service=“{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: service. Response> <cas: proxy. Success> <cas: proxy. Ticket>PT-957 -Zuuc. Xq. TZ 1 Yc. Jw 81 T 3 dxf</cas: proxy. Ticket> </cas: proxy. Success> </cas: service. Response> 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 proxy. Ticket argument. The CAS Proxied application checks for the presence of a “proxy. Ticket” in it’s URL query string. If one exists, it makes an HTTP post or get to CAS specifying the proxy. Validate method. ¡ https: //auth-test/berkeley. edu/cas/proxy. Validate? ticket=“{the value of the proxy. Ticket in your proxy application’s URL}”&service=“{your proxy application URL}” CAS verifies the proxy. Ticket provided by the CAS proxied application and returns a success or failure status indication response in XML ¡ <cas: service. Response xmlns: cas=“http: //www. yale. edu/tp/cas”> <cas: authentication. Success> <cas: user>{Cal. Net ID}</cas: user> <cas: proxies> <cas: proxy>{the proxy callback URL}</cas: proxy> </cas: proxies> </cas: authentication. Success> </cas: service. Response>
A Visual Representation
A “real life” Example n The Hello World CAS Proxy Web Service ¡ https: //ordev. berkeley. edu/Proxy. Web. Service/Hello. Service. 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 n Documentation on integrating CAS Authentication with Forms Authentication in ASP. Net 2. 0 ¡ ¡ n CAS Proxying with Classic ASP ¡ n http: //www. jasig. org/wiki/display/CASC/CAS+Proxying+with+Classic+ASP Tom O'Brien has an online demo on CAS Proxy Authentication ¡ n https: //calnet. berkeley. edu/developers/developer. Resources/cas/ ASP. Net. CASAuth. pdf http: //www. jasig. org/wiki/display/CASC/CAS+Proxying+with+Classic+ASP https: //students. berkeley. edu/osl/hellocas/Main. App. asp Some excerpts from this presentation were taken from Tom O'Brien’s documentation ¡ http: //studentstest. berkeley. edu/documentation/CASProcess. pdf
Скачать презентацию CAS Proxying and Web Services The somewhat easy
eb01d3184c72e0b7daf17664deddba86.ppt