seeking elp with properly specifying a "redirect URL"

[Pottinger, Hardy J.]

Hi, thanks, Scott, for the nudge in (what I think to be) the right direction. I looked more closely at the application code, and figured out how it's storing the previously-visited URL. It's using the servlet's session to keep track of this information, which lead me to believe that perhaps we're losing the session in the roundtrip to the Shibboleth IdP. I conducted a little experiment to see if I could find some evidence of this. On our staging server, on a restricted page that throws a "please login" error, I can see I have the following JSESSIONID cookie:

JSESSIONID=419CD504F7779CBB3BBA81331D0D901E
Host: irsandbox.obsfucated.edu
Path: /xmlui/
Expires: At browser exit (session)
Attributes: None

I then continue on to the Shibboleth login now

And after the IdP returns me to IRsandbox, these are the cookies:

_shibsession_64656661756c7468747470733a2f2f697273616e64626f782e6c736f2e756d73797374656d2e6564752f73686962626f6c657468=_d9b6917dc9872d7739e371f3403508e5
Host: irsandbox.obsfucated.edu
Path: /
Expires: At browser exit (session)
Attributes: None
Edit Remove
JSESSIONID=7CAC9D1A072ED68B368703645E7A2554
Host: irsandbox.obsfucated.edu
Path: /xmlui/
Expires: At browser exit (session)
Attributes: None

Yep, totally new JSESSIONID, that's so not right. I think this might be due to Tomcat discarding the original JSESSIONID (possibly due to an aggressive anti-session-hacking routine). I will investigate ways to deal with this.

I'm also curious if anyone else on this list might develop Java servlets, and maybe they've had to wrangle a similar issue? Any help would be much appreciated. Thanks!

--Hardy
________________________________________
From: users [users-bounces at shibboleth.net] on behalf of Cantor, Scott [cantor.2 at osu.edu]
Sent: Monday, August 31, 2015 6:40 PM
To: Shib Users
Subject: Re: seeking elp with properly specifying a "redirect URL"

On 8/31/15, 6:27 PM, "users on behalf of Pottinger, Hardy J." <users-bounces at shibboleth.net on behalf of PottingerHJ at missouri.edu> wrote:



>Hi, I'm a committer for DSpace [1], I'm trying to find a resolution for an issue [2] which involves properly specifying a redirect URL for sending a user after they successfully login on our Shibboleth IdP.

A Shibboleth IdP doesn't use any special parameters for that in a standard SP-initiated flow, the RelayState attribute is propagated in accordance with the standard and what the SP does with the result is up to the SP. Any SAML IdP that is compliant will do that, and SAML SPs work in different ways when it comes to handling application integration and deep linking.

> In the past, I've used the "target" parameter to do this,

The only place the IdP uses that parameter is in a legacy SAML 1.x request or an IdP-initiated flow, and neither should really be involved in any integration in 2015.

> however, it seems like DSpace uses "target" for handling *all* successful logins, and the login type I am especially interested in right now is the one that results from an interrupted session (insufficient privileges). I'm wondering if there might be a resource somewhere to help me understand how the target parameter is supposed to work?

I'm not yet understanding which piece of software you're talking about. The Shibboleth IdP I speak to above, and DSpace I can't really speak to when you say that it "uses" the parameter. If it's doing something with a parameter by that name, it wouldn't have anything to do with Shibboleth (but obviously could conflict in certain cases I guess).

> I've found the wiki page on Session Creation Parameters [3] but I'm still not clear on how exactly the target parameter is supposed to work, or what options are available.

That's for the Shibboleth *SP*. So again, I don't know what software you're actually asking about or in what scenario.

In the SP, you can request a session by passing control to a SessionInitiator, and that can include query parameters (target along them), which is what that page is referring to. That's normally set to the application resource to return to after the login happens.

-- Scott

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