I ran the following tests using CAS 3.5.0 running in Jetty 7.6.4 under SLES 11, where your issue was not reproduced.
I accessed the following URI at CAS
https://foo.emc.com/cas/login?TARGET=https%3a%2f%2fcassts.ginsburg.local%2fc
asauth_sts%2f%3fwa%3dwsignin1.0%26wtrealm%3dhttps%253a%252f%252fcassts.ginsb
urg.local%252fCASAuth%252f%26wctx%3drm%253d0%2526id%253dpassive%2526ru%253d%
25252fCASAuth%25252f%26wct%3d2013-02-13T18%253a25%253a5
I was forwarded to this URI:
https://cassts.ginsburg.local/casauth_sts/?wa=wsignin1.0&wtrealm=https%3a%2f
%2fcassts.ginsburg.local%2fCASAuth%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252
fCASAuth%252f&wct=2013-02-13T18%3a25%3a5&TARGET=https%3A%2F%2Fcassts.ginsbur
g.local%2Fcasauth_sts%2F%3Fwa%3Dwsignin1.0%26wtrealm%3Dhttps%253a%252f%252fc
assts.ginsburg.local%252fCASAuth%252f%26wctx%3Drm%253d0%2526id%253dpassive%2
526ru%253d%25252fCASAuth%25252f%26wct%3D2013-02-13T18%253a25%253a5&SAMLart=A
AFSsPYAkNKN6Mb0Q6Li8D8gawrtLIThDLe4F%2BOFgI%2FsE6p9Ze8y97b7
This look correct to me and it is not the same result that you got in your
test. The encoded URI is repeated in the TARGET query parameter because
that is what the SAML 1.1 Browser/Artifact profile indicates, so that is not
a bug.
I'm going to load up a CAS 3.5.1 instance and see what happens.
-----Original Message-----
From: Robert Ginsburg [mailto:rob...@ginsburg.me]
Sent: Thursday, February 14, 2013 7:09 AM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] URL encoding and CAS
Thanks,
I am using CAS 3.51, Tomcat 7.0 , JRE 1.7.0 update 11, running on Windows
2008 R2
Robert Ginsburg
rob...@ginsburg.me
(803) 467 - 3329
-----Original Message-----
From: Ohsie, David [mailto:david.oh...@emc.com]
Sent: Wednesday, February 13, 2013 11:42 PM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] URL encoding and CAS
I tried to reproduce your problem, but I got a different result than you did
(the URL's did not seem to be mangled). I'll report back tomorrow on my
results in greater detail, but in the meantime could you let me know what
version of CAS you are using? I tested using 3.5.0.
David Ohsie
Software Architect
EMC Corporation
-----Original Message-----
From: Robert Ginsburg [mailto:rob...@ginsburg.me]
Sent: Wednesday, February 13, 2013 1:40 PM
To: cas-user@lists.jasig.org
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.lo
cal%2fcasauth_sts%2f%3fwa%3dwsignin1.0%26wtrealm%3dhttps%253a%252f%252fcasst
s.ginsburg.local%252fCASAuth%252f%26wctx%3drm%253d0%2526id%253dpassive%2526r
u%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%252f
CASAuth%252f&wct=2013-02-13T18:30:44Z&TARGET=https:%2F%2Fcassts.ginsburg.loc
al%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
rob...@ginsburg.me
(803) 467 - 3329
-----Original Message-----
From: Ohsie, David [mailto:david.oh...@emc.com]
Sent: Wednesday, February 13, 2013 10:26 AM
To: cas-user@lists.jasig.org
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:rob...@ginsburg.me]
Sent: Wednesday, February 13, 2013 9:28 AM
To: cas-user@lists.jasig.org
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
rob...@ginsburg.me
(803) 467 - 3329
-----Original Message-----
From: Jeff Chapin [mailto:jeff.cha...@uni.edu]
Sent: Friday, February 08, 2013 5:39 PM
To: cas-user@lists.jasig.org
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: jeff.cha...@uni.edu
--
You are currently subscribed to cas-user@lists.jasig.org as:
rob...@ginsburg.me To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to cas-user@lists.jasig.org as:
david.oh...@emc.com To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to cas-user@lists.jasig.org as:
david.oh...@emc.com To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to cas-user@lists.jasig.org as:
david.oh...@emc.com 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
