I hope to post more in more detail about this later, but we made a modification to the CAS client to send back a 401 (with WWW-Authenticate: X-EMC-CAS) instead of a 302 when the client is a non-browser client and authentication is needed. Then our non-browser clients can make rest calls, and when they encounter the 401, they go the the CAS REST endpoint to get the TGT and ST and use the ST to access the CAS protected service. You still have to deal with cookies unless you want to get an ST for every call.
david -----Original Message----- From: sol myr [mailto:[email protected]] Sent: Sunday, February 17, 2013 3:34 AM To: [email protected] Subject: [cas-user] Non-browser client Hi, We have a legacy non-browser client application (Swing), which does most of the work locally on the client machine, but occasionally contacts the server using HttpClient (e.g. REST api to "upload work to server"). The server is a Java web-application on Tomcat. Is there an easy way to add CAS protection to this? I saw the REST documentation: https://wiki.jasig.org/display/CASUM/RESTful+API But wasn't sure how the complete flow should be... I could start with a Swing login form, and use the credentials to obtain a TicketGrantingTicket via RESTful API. But once I obtained a TicketGrantingTicket... what next? I know the flow for *Browser* applications, so one solution could be imitating browser behavior, in term of redirects and cookies (follow the CAS redirect that adds "ticket" parameter representing ServiceTicket; then follow the ValidationFilter redirect that removes this "ticket" parameter; and finally get a JSESSIONID cookie which should be sent in subsequent requests). But is there any easier API for non-browser applications? One that involves less 'redirects' and less cookies? Thanks -- 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
smime.p7s
Description: S/MIME cryptographic signature
