Centralized Discovery Service and URL decoding

[Wessel, Keith]

Thanks for giving us another checkpoint here, Scott. I suppose I could have tried that same test.

Our DS installation is quite standard and, though parts of it go back to the original one, our test DS instance is freshly installed last week in hopes that this would fix the problem. Only some of the original branding is the same.

Can someone at InCommon confirm for us that the InCommon DS is using the Shib centralized DS software? If that's the case, I'll have to dig deeper to see how we broke things on our side. If not, I agree that we most likely have a bug, and I'll file a bug report.

Thanks again,
Keith


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

On 10/29/13, 3:58 PM, "Wessel, Keith" <kwessel at illinois.edu> wrote:

>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&returnIDPa
>ram=PartnerIdpId&return=https%3A%2F%2Fsso.services.box.net%2Fsp%2FstartSSO
>.ping%3FTargetResource%3Dhttps%253A%252F%252Fwww.box.com%252Fapi%252Foauth
>2%252Fauthorize%253Fresponse_type%253Dcode%2526client_id%253Dpbwjkgj4xxa9j
>ifscs2zv3dzq1t96ykc%2526redirect_uri%253Dhttps%25253A%25252F%25252Fgoogle.
>com%25252F

I took that URL and modified it twice:

- replaced your DS location with InCommon's
- replaced the box reference with carmenwiki.osu.edu as the SP to get past
the endpoint check

The resulting redirect back to carmenwiki was:

https://carmenwiki.osu.edu/Shibboleth.sso/Login?TargetResource=https%3A%2F%
2Fwww.box.com%2Fapi%2Foauth2%2Fauthorize%3Fresponse_type%3Dcode%26client_id
%3Dpbwjkgj4xxa9jifscs2zv3dzq1t96ykc%26redirect_uri%3Dhttps%253A%252F%252Fgo
ogle.com%252F&PartnerIdpId=urn%3Amace%3Aincommon%3Aosu.edu

I believe that's all as it should be?


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

See above, looks like that's what I get.

>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.

I traced it with Live Headers, and it's definitely your DS doing it. So
there's a bug somewhere on your side, but I thought the InCommon DS was
also the CDS code. If not, then there probably is a bug in the CDS. I
don't know that code.

-- Scott


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