Shibboleth Idp does not persist URL hash fragments across a login redirect.

Wed Jan 24 04:15:07 EST 2018

Although I advocated this issue using the same arguments in the past, I 
came accross a possible solution to this problem.

In the SAP SAML implementation they use their bindingTemplate to extract 
the part after the fragment using javascript and they store it in a 
cookie. Afterwards the SAMLRequest is POST'd.

<body onload="javascript:var 
url=window.location.hash;if(url&&(0!==url.length)){document.cookie="oucsexzueusozeqboredyoyqyzosfvzawycyqqz_anchor="+escape(url)+"; 
path=/"}document.forms[0].submit()">

Later, when the user returns with his SAML2 response, he is redirected 
to the relaystate  + the value of that cookie. That way the URL-fragment 
is preserved when using the HTTP-POST binding to send the SAML request. 
Obviously this does not work for the HTTP-redirect binding.

What are your thoughts on this approach?

Regards,

Philip

On 18/04/2016 14:11, Peter Schober wrote:
> * abdul waheed <abdulwaheed18 at gmail.com> [2016-04-18 13:39]:
>> Hi, Is it possible to add template attribute in SSO tag, Will it work? e.g:
> To achieve what, specifically? As we've now said multiple times and
> explained in multiple ways the fragment identifier that's part of the
> originally requested resource *cannot* be preserved by the sever side
> since the web browser does not sent it to the web server.
>
> Furthermore, whatever you put into the Shibboleth SP software here
> (template) will only influence the SAML2 authentication request sent
> to the IDP. But RelayState (see above) is not part of the
> Authentication Request itself, so using a template to create different
> authn requests has nothing to do with the problem at hand.
>
> Finally, if you were able to hard-code RelayState (the URL to return
> to after SSO finishes successfully) in the template file (and the
> template file were the right place for that, which it is not) -- i.e.,
> if RelayState was always the same for everyone using your application
> -- you could also just set ApplicationDefaults/@homeURL in your
> shibboleth2.xml:
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApplication#NativeSPApplication-Attributes
>
> So *either* the URL to end up at is always the same for everyone
> (which doesn't match your description of the problem), in which case
> you could just set homeURL.
> *Or* you will need to initialize (and check, and possibly terminate)
> sessions yourself, using the Shibboleth SP's handlers and using only
> lazy sessions (i.e., no session enforcement) on the server side.
> I've already sent an example URL on how to initialize sessions in a
> way that preserves the fragment identifer, using Testshib.
>
> The server-side cannot help you unless you (i.e., your client side
> code) provides the relevant URL to the SP's handler dynamically.
> -peter