CAS in IdP v3

[Cantor, Scott]

On 2/3/16, 4:21 PM, "users on behalf of Brian Biggs" <users-bounces at shibboleth.net on behalf of brian.biggs at sonoma.edu> wrote:



>This may not be the place to post it, but here's an example of the 
>config I'm using in jetty-rewrites.xml:

Didn't even know it had anything. When I think rewrite I assume mod_rewrite. That said, I think this might be a bug in the IdP and may be happening afterward, but I'm just speculating.

>From there, when I try to go to https://ldap-cgi2.dev.sonoma.edu/portal
>(which should just redraw the page with a new ST), I get redirected to 
>this URL:
>https://ldap-cgi2.dev.sonoma.edu/portal/index.cgi;jsessionid=1jdp54hlph8tt14mvka8xukxm1?ticket=ST-1454534211931-IckWXOAqD6JAsLdmbj5ide6mC

Obviously that's not the IdP, so are you saying that happens after the round trip back to the IdP and then back to the resource?

Because if so...if that jsessionid value is coming from the IdP's container, the only way it could get there is if the return URL on the redirect back out of the CAS flow included it. And that doesn't seem right to me.

The way Java containers attach jsessionid to URLs is awful. It may be legal, but it's preposterous. And a lot of code that ends up parsing out URL information tends to get broken when it happens (like, say, my SP a while back), and I'm just wondering if we have something in there doing that and getting broken.

I'm just hand waving, I don't know the code there. But I'm still focusing on how a jsessionid value is ending up inside a *resource* URL after a redirect. I can't see how that happens without code in the IdP putting it there.

-- Scott