"To authenticate with https://cms/ they need to have setup their account at a different site, so they get redirected there with a return url pointing back to the original site, so https://account/?ret=https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource";
I think this redirect might be a problem. That literally UrlDecodes to " https://account/?ret=https://cms/login?ret=secure%2fresource"; which is invalid. Functionally, think of the redirect URL as AccountUrl(CmsUrl(OriginUrl)). OriginUrl should be double-encoded and CmsUrl should be encoded once. The redirect to your account site should look like this: https://account/?ret=https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource Notice that secure/resource (OriginUrl) became secure%2fresource (%2f being the encoded '/' character) when CmsUrl was created and then became secure%252fresource (%25 being the '%' character'). https://account/?ret=https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource UrlDecode(https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource) = https://cms/login?ret=secure%2fresource UrlDecode(secure%2fresource) = secure/resource Regarding your EnhancedUriBuilder concerns, I just checked in some code to the url-encoding-bugfix branch that should fix some encoding/decoding issues in EnhancedUriBuilder. I don't have access to VS for a little while, so I couldn't verify this locally. Can you give this branch a shot and see if it + the double-encoding fix above addresses your problems? Thanks, Scott On Tue, Dec 16, 2014 at 1:32 PM, Lapanja, Bob@POST <bob.lapa...@post.ca.gov> wrote: > I have an ugly use case where the url redirections get a little deep. If > a user is not logged in and accesses a secured resource at > https://cms/secure/resource, they get redirected to > https://cms/login?ret=secure%2fresource. To authenticate with > https://cms/ they need to have setup their account at a different site, > so they get redirected there with a return url pointing back to the > original site, so > https://account/?ret=https%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource > . > > https://account/ uses the dotnetcasclient 1.0.2 httpmodule (I've also > reproduced the problem with the master branch source code). Since the user > is not authenticated with https://account/, they get redirected to my CAS > site with: > > > https://cas/login?service=https%3a%2f%2faccount%2f%3fret%3dhttps%3a%2f%2fcms%2flogin%3fret%3dsecure%252fresource > > The service querystring parameter then decodes to: > https://account/?ret=https://cms/login?ret=secure%2fresource. > > This causes me to get service ticket validation errors > ERROR org.jasig.cas.CentralAuthenticationServiceImpl - ServiceTicket > [ST-blah] with service [ > https://account/?ret=https://cms/login?ret=secure%2fresource] does not > match supplied service [ > https://account/?ret=https://cms/login?ret=secure/resource] > > I believe the problem is in UrlUtil in CostructServiceUrl on line 101 (and > probably in CostructProxyCallbackUrl on line 188) on the master branch and > the 1.0.2 branch. The code says ub.QueryItems.Add(request.QueryString). > According to the documentation ( > http://msdn.microsoft.com/en-us/library/system.web.httprequest.querystring(v=vs.110).aspx > ) HttpRequest.QueryString values are automatically decoded. Debugging > seems to verify this. They seem to lose their encoding when going from > request.QueryString to ub.QueryItems. I replaced this line of code with: > foreach (var qs in request.QueryString.AllKeys) > ub.QueryItems.Add(qs, > HttpUtility.UrlEncode(request.QueryString[qs])); > > This appeared to fix the problems I was having, and doesn't seem to cause > any other issues. Before I deploy this change to production I wanted to > verify if this seems correct. I would hate to naively make a change to the > source code thinking I was fixing a bug and wind up introducing a security > vulnerability because things were done the way they were done for a reason > and I just lacked foresight. > > Thanks. > > Also, I manually edited some of these urls in the interest of brevity, so > if it seems like a character is missing in the urls it's probably my fault. > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scottt...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
