CAS in IdP v3

[Brian Biggs]

Hopefully relevant debug logs from jetty:

GET 
https://auth.dev.sonoma.edu/cas-server/login?service=https://ldap-cgi2.dev.s
onoma.edu/portal/index.cgi
Host: auth.dev.sonoma.edu
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:43.0) 
Gecko/20100101 Fire
fox/43.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: 
shib_idp_session=9c50ce4019803bb7e75d14b99f0458ff33ec00d5f761f091059d3be
28faaa9dc; _ga=GA1.2.146321109.1454522035
Connection: keep-alive


13:29:42.783 - DEBUG 
[org.eclipse.jetty.rewrite.handler.RuleContainer:166] - app
lied 
org.eclipse.jetty.rewrite.handler.RewritePatternRule[ht][/cas-server/login]
[/idp/profile/cas/login]

13:29:42.783 - DEBUG 
[org.eclipse.jetty.rewrite.handler.RuleContainer:167] - rew
rote /cas-server/login to /idp/profile/cas/login

13:29:43.097 - DEBUG [org.eclipse.jetty.server.Server:520] - RESPONSE 
for /cas-s
erver/login h=true
302 null
Set-Cookie: JSESSIONID=qq7wly12bjqbw1rg6ogoltdn;Path=/idp;Secure
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-store
Location: 
https://ldap-cgi2.dev.sonoma.edu/portal/index.cgi;jsessionid=qq7wly12b
jqbw1rg6ogoltdn?ticket=ST-1454534983074-PNvIpJ7iyd0KrHFy9drsCnoZV


I'll turn up the debugging on the idp and see what I can pull out of the 
process log.

-Brian

On 02/03/2016 01:27 PM, Cantor, Scott wrote:
> 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
>

-- 

Brian Biggs
Sonoma State University