Centralized Discovery Service and URL decoding

[Wessel, Keith]

Thanks, Scott. This was all as I suspected.

The Box engineer clarified for me that they aren't doubly-encoding, but rather encoding the parameter then encoding the entire return URL afterwards. That sounds like what I thought they should be doing and also what they were suggesting.

They sent me this sample:

Step 1
Box OAuth2 Redirect URL: https://google.com/
Box OAuth2 Redirect URL (Encoded): https%3A%2F%2Fgoogle.com%2F

Step 2
Box OAuth2 URL: https://www.box.com/api/oauth2/authorize?response_type=code&client_id=pbwjkgj4xxa9jifscs2zv3dzq1t96ykc&redirect_uri=https%3A%2F%2Fgoogle.com%2F
Box OAuth2 URL (Encoded): https%3A%2F%2Fwww.box.com%2Fapi%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Dpbwjkgj4xxa9jifscs2zv3dzq1t96ykc%26redirect_uri%3Dhttps%253A%252F%252Fgoogle.com%252F

Step 3
Box SSO URL: https://sso.services.box.net/sp/startSSO.ping?TargetResource=https%3A%2F%2Fwww.box.com%2Fapi%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Dpbwjkgj4xxa9jifscs2zv3dzq1t96ykc%26redirect_uri%3Dhttps%253A%252F%252Fgoogle.com%252F
Box SSO URL (Encoded): https%3A%2F%2Fsso.services.box.net%2Fsp%2FstartSSO.ping%3FTargetResource%3Dhttps%253A%252F%252Fwww.box.com%252Fapi%252Foauth2%252Fauthorize%253Fresponse_type%253Dcode%2526client_id%253Dpbwjkgj4xxa9jifscs2zv3dzq1t96ykc%2526redirect_uri%253Dhttps%25253A%25252F%25252Fgoogle.com%25252F

When we go to this University of Illinois URL we expect to be returned back the to URL specified in the return parameter (this parameter needs to be decoded 1x).

University of Illinois URL: https://shibboleth.illinois.edu/illinois-ds/DS?entityID=box.net&returnIDParam=PartnerIdpId&return=https%3A%2F%2Fsso.services.box.net%2Fsp%2FstartSSO.ping%3FTargetResource%3Dhttps%253A%252F%252Fwww.box.com%252Fapi%252Foauth2%252Fauthorize%253Fresponse_type%253Dcode%2526client_id%253Dpbwjkgj4xxa9jifscs2zv3dzq1t96ykc%2526redirect_uri%253Dhttps%25253A%25252F%25252Fgoogle.com%25252F

Expected Redirect on Successful Login: https://sso.services.box.net/sp/startSSO.ping?TargetResource=https%3A%2F%2Fwww.box.com%2Fapi%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id%3Dpbwjkgj4xxa9jifscs2zv3dzq1t96ykc%26redirect_uri%3Dhttps%253A%252F%252Fgoogle.com%252F

Instead of arriving at the URL above, we get redirected to this URL.

Redirect on Successful Login: https://sso.services.box.net/sp/startSSO.ping?TargetResource=https://www.box.com/api/oauth2/authorize?response_type=code&client_id=pbwjkgj4xxa9jifscs2zv3dzq1t96ykc&redirect_uri=https%3A%2F%2Fgoogle.com%2F&PartnerIdpId=urn:mace:incommon:uiuc.edu

As you can see, the Target Resource parameter has been URL decoded too. This is not expected.

They seem to suspect the discovery service is responsible for this, but I kind of wonder if it's something else like Ping Federate on their side, though they say it appears it's being decoded before it gets back to them.

Any further thoughts?

Keith

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, October 25, 2013 9:35 PM
To: Shib Users
Subject: Re: Centralized Discovery Service and URL decoding

On 10/25/13, 9:51 PM, "Wessel, Keith" <kwessel at illinois.edu> wrote:

>We¹re having a problem with the Shib Centralized DS and doubly-encoded
>URLs. A string that we¹re encoding twice because it¹s supposed to still
>be URL-encoded when it gets back to the SP seems to be decoded.

When you invoke a DS, there should never be anything doubly encoded unless
there's a parameter attached to a URL that is itself a DS parameter.

The return location is NOT doubly encoded, it's encoded once. If it
contains a parameter itself, then that gets encoded first before it's ever
attached to the URL that is itself eventually encoded as a parameter to
the DS.

You never doubly-encode a particular parameter. You only encode parameters
in a nested fashion, inside out. Part of a parameter may be doubly encoded
by the end but never twice by itself.

> 
>Box, in the beta of their new sync service, has the need to include a
>parameter as part of the return URL that is, itself, another URL. They
>want that parameter value to remain URL-encoded when it gets back to them.

That's fine but they should be the ones sending the parameter in the first
place, so if it's wrong, they must have failed to encode it properly to
start with when they included it. They basically attached an unencoded
parameter to the return parameter itself, and that ends up decoded for use
as a redirect back and then fails. That's a standard "failure to encode a
parameter" bug.

> 
>Of course, the DS also expects the return URL to be URL-encoded.

Yes, and whatever state it's in, it gets decoded (once) and then used as
the location to redirect back to (with additional parameters attached to
signal back the IdP).

> So, the smart folks at Box decided they¹d just encode the parameter,
>then encode the whole return URL string. End result: the parameter is now
>doubly encoded.

I don't think that's what they did, but you didn't post a complete trace.

> 
>Funny thing is that, by the time the return URL gets back to Box, even
>the parameter seems to be completely decodedŠ as if the DS id decoding
>twice.

I don't think that's possible.

>Is the DS doing some logic after it decodes the return URL to see if it
>still seems to have further decoding in it and, if it does, looping
>through again? Or do we need to look beyond the DS to find the source of
>this craziness?

I think they probably failed to encode the URL they included as a
parameter to their own, nothing very unusual.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net