We have similar problem with CAS authenticating with our PeopleSoft implementation when we want the client to go directly to a page within PeopleSoft.
We weren't able to get CAS to come back with the service URL or TARGET URL when the url contained a parameter that was another URL with its own set of parameters. I am not sure how web applications are supposed to interpret a url like this, but it seems that it could be hard to determine which url a particular parameter belongs after the url has been decoded. Our solution was to use our own encoding scheme for the embedded url so that CAS or any other web app would interpret it as just a string value associated with a url parameter. When CAS redirects back to PS, we decode the embedded url and then redirect back to ourselves with the decoded URL. Somewhat of a hack, but couldn't find another way around it. Storing the value in a cookie wouldn't have worked for us in this case. -John -----Original Message----- From: Robert Ginsburg [mailto:[email protected]] Sent: Wednesday, February 13, 2013 12:40 PM To: [email protected] Subject: RE: [cas-user] URL encoding and CAS As it's a fairly simple protocol, so the CAS client is my own code base. I am building a WSFederation bridge for ADFS that uses CAS for authentication. the "long urls" are basically federation passive redirects from other ADFS servers. For example I want to retain this query string and path wa=wsignin1.0&wtrealm=https%3a%2f%2fcassts.ginsburg.local%2fCASAuth%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fCASAuth%252f&wct=2013-02-13T17%3a27%3a32Z So you would think I would simply append that to the query string parameter which would result in this (my cas server is cas.ginsburg.local and my federation proxy is cassts.ginburg.local) https://cas.ginsburg.local/cas/login?TARGET=https%3a%2f%2fcassts.ginsburg.local%2fcasauth_sts%2f%3fwa%3dwsignin1.0%26wtrealm%3dhttps%253a%252f%252fcassts.ginsburg.local%252fCASAuth%252f%26wctx%3drm%253d0%2526id%253dpassive%2526ru%253d%25252fCASAuth%25252f%26wct%3d2013-02-13T18%253a25%253a5 If I do that, then the CAS redirect sends me back with this , to the right place but with a mangled URL, notice that parts of the query string are repeated. "https://cassts.ginsburg.local/casauth_sts/?wa=wsignin1.0&wtrealm=https:%2f%2fcassts.ginsburg.local%2fCASAuth%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fCASAuth%252f&wct=2013-02-13T18:30:44Z&TARGET=https:%2F%2Fcassts.ginsburg.local%2Fcasauth_sts%2F%3Fwa%3Dwsignin1.0%26wtrealm%3Dhttps%253a%252f%252fcassts.ginsburg.local%252fCASAuth%252f%26wctx%3Drm%253d0%2526id%253dpassive%2526ru%253d%25252fCASAuth%25252f%26 This example only repeats once, I have seen it repeat up to 4 times (with different federation urls). For the moment what I have done is move the URL to a cookie before sending the request to CAS. That works fine but of course I have to refresh the URL after it comes back so it causes another round trip on my server. Robert Ginsburg [email protected] (803) 467 - 3329 -----Original Message----- From: Ohsie, David [mailto:[email protected]] Sent: Wednesday, February 13, 2013 10:26 AM To: [email protected] Subject: RE: [cas-user] URL encoding and CAS Can you report which CAS client you are using and also post the URL that is in your browser address bar at the CAS login page or a log of the web server requests. "Long" or "complex" URL's should be working without a problem. david -----Original Message----- From: Robert Ginsburg [mailto:[email protected]] Sent: Wednesday, February 13, 2013 9:28 AM To: [email protected] Subject: RE: [cas-user] URL encoding and CAS I must admit to both being a CAS newbie but I have had a similar problem with CAS 3.51. I was unable to reliably get CAS to return complex URL's . By that I mean URLs that had fairly long accompanying URL encoded query strings. I ended up pushing the original URL in a client side cookie and restoring it on return. It does mean an extra redirect but the CAS service url is short and of course works fine. Robert Ginsburg [email protected] (803) 467 - 3329 -----Original Message----- From: Jeff Chapin [mailto:[email protected]] Sent: Friday, February 08, 2013 5:39 PM To: [email protected] Subject: [cas-user] URL encoding and CAS All, We have an enterprise reporting tool we have operating behind CAS. This service has URLs that have 'special' characters in it -- ampersands, slashes, question marks, spaces, etc. This service handles some URL encoding just fine -- it does not mind replacing ' ' with %20, for instance. When this application is placed behind CAS, however, CAS is modifying the URL -- it is URL encoding strangely. For instance, if I wanted to hit: https://example.com/analytics/saw.dll?dashboard&PortalPath=%2Fshared%2Deans% 2C%20Directors%2C%20Department%20Heads%2F_portal%2FAdmissions%20for%20DDDH CAS is properly authing the user, and then releasing them to: https://example.com/analytics/saw.dll?dashboard%26PortalPath%3d%252Fshared%2 52FDeans%252C%2520Directors%252C%2520Department%2520Heads%252F_portal%252FAd missions%2520for%2520DDDH If you look, it appears that CAS took the already URL encoded service URL, and encoded it again -- %20 becomes %2520 -- the encoding for '%' followed by the '20'. For some reason, CAS is smart enough to encode, but not decode on the way back out. Due to the nature of the service, it *has* spaces in the URLs generated, as well as question marks, ampersands, and slashes -- and who knows what else? It appears that the application is smart enough to decode %20 when it comes in, but not %2520, so these links break, and anytime you are prompted to log in through CAS, you get a 404 error. Subsequent connections (with an existing CAS session) work just fine, with no re-writing of the URLs. Does anyone know of a work around, a setting we can change, or even a section of code to look into in order to fix this behavior? Due to the nature of these reports, and their user base (Deans, Directors, and Department Heads) I am under a decent amount of added incentive to find a fix to this issue... Thanks, Jeff -- Jeff Chapin, Assistant Systems/Applications Administrator ITS-IS, University of Northern Iowa Phone: 319-273-3162 Email: [email protected] -- 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
