Hyperlinks to Shibboleth protected URLs in MS Office documents

[Philip Brusten]

On 26/11/2017 17:53, Cantor, Scott wrote:
> Isn't the underlying problem still cookies? I thought the real fix was just to switch relay state types in the SP (and it's defaulted correctly for years now).
I have re-run my tests on a default SP & default MS Windows 10 client 
with Office 2016 and this doesn't work either.

The SP uses the default relayState="ss:mem" and 
outgoingBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" (my 
previous example used urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST as 
the outgoing binding).
If you want, I can provide you with an HTTP-trace of that client using 
Fiddler.

This is what I am observing after I CTRL+click on a hyperlink in an MS 
Office document which is protected by a Shibboleth SP (entityID already 
known, so without discovery):

First you see two HEAD requests coming from the internal MS Office Word 
browser:

Request #1
HEAD https://domain.com/protected_resource HTTP/1.1
User-Agent: Microsoft Office Word 2014
X-Office-Major-Version: 16
Host: domain.com

HTTP/1.1 302 Found
Location: 
https://idp.domain.com/idp/profile/SAML2/Redirect/SSO?SAMLRequest=<SAMLRequest>&RelayState=ss%3Amem%3A1da9e1e949759fcedd0ccf9cfdc28de037da64e290cf1fecbb889290ea910e49

Request #2
HEAD 
https://idp.domain.com/idp/profile/SAML2/Redirect/SSO?SAMLRequest=<SAMLRequest>&RelayState=ss%3Amem%3A1da9e1e949759fcedd0ccf9cfdc28de037da64e290cf1fecbb889290ea910e49 
HTTP/1.1
User-Agent: Microsoft Office Word 2014
X-Office-Major-Version: 16
Host: idp.domain.com

HTTP/1.1 400 Bad Request

The requests fail, so I assume he gives up.
Next winword repeats the process using another browser, User-Agent: 
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; 
.NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 
3.5.30729; ms-office)
Not using HEAD but GET requests this time.

Request #1:
GET https://domain.com/protected_resource HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; 
Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; 
.NET CLR 3.5.30729; ms-office)
Host: domain.com

HTTP/1.1 302 Found
Location: 
https://idp.domain.com/idp/profile/SAML2/Redirect/SSO?SAMLRequest=<SAMLRequest>&RelayState=ss%3Amem%3A1943ed02da8b5204bc89ebef32a658d5cca2a4e999fcd9b25eff1b6f49d61621

Request #2:
GET 
https://idp.domain.com/idp/profile/SAML2/Redirect/SSO?SAMLRequest=<SAMLRequest>&RelayState=ss%3Amem%3A1943ed02da8b5204bc89ebef32a658d5cca2a4e999fcd9b25eff1b6f49d61621 
HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; 
Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; 
.NET CLR 3.5.30729; ms-office)
Host: idp.domain.com

HTTP/1.1 302 Found
Set-Cookie: JSESSIONID=xadrir8iaw0ed82x4l6ptv7a;Path=/idp;Secure
Location: 
https://idp.domain.com/idp/profile/SAML2/Redirect/SSO;jsessionid=xadrir8iaw0ed82x4l6ptv7a?execution=e1s1

Request #3:
GET 
https://idp.domain.com/idp/profile/SAML2/Redirect/SSO;jsessionid=xadrir8iaw0ed82x4l6ptv7a?execution=e1s1 
HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; 
Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; 
.NET CLR 3.5.30729; ms-office)
Cookie: JSESSIONID=xadrir8iaw0ed82x4l6ptv7a;

HTTP/1.1 200 OK

=> HTML page that wil load the session information from the HTML 
Localstorage

No further requests. That ms-office browser will cease its attempt 
(perhaps not able to process the javascript?).
Now the default browser is opened (Edge, since it is a default windows 
10 image) and it re-issues that last request using the default browser:

Request #1:
GET 
https://idp.domain.com/idp/profile/SAML2/Redirect/SSO;jsessionid=xadrir8iaw0ed82x4l6ptv7a?execution=e1s1 
HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299
Host: idp.domain.com

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=s5agesgo3a1i1pc8d6xe10z2r;Path=/idp;Secure

Notice the absence of the JSESSIONID-cookie in the request. The session 
is however present as request variable...
In response the browser gets a new JSESSIONID as a cookie.
And the IdP failes with a NoSuchFlowExecutionException:
Resolving exception from handler 
[[FlowHandlerMapping.DefaultFlowHandler at 3ae948b8]]: 
org.springframework.webflow.execution.repository.NoSuchFlowExecutionException: 
No flow execution could be found with key 'e1s1' -- perhaps this 
executing flow has ended or expired? This could happen if your users are 
relying on browser history (typically via the back button) that 
references ended flows. -

The IdP shows the "stale" error message to the user.

If Jetty would have used that jsessionid from the request, it might have 
worked.

Of course I know this is not a problem of the Shibboleth software, but 
any ideas to circumvent this behaviour are welcome.

Kind regards,
Philip