CORS preflight request

[Ilkka Lindblom]

Hello

We run Shibboleth IdPs and I ran into a problem that I believe I have 
fixed, but still wanted to ask about. Maybe it will be of benefit to others.

The issue was as follows:

- User logs in to an application via our IdP, app uses SP initiated 
login flow with SAML authnrequest
- User uses the app for some time, until the application side session 
runs out
- User clicks on some link in the application, but since there is no 
longer a valid session, application responds with a 302 which directly 
contains a new authnrequest towards IdP
- On IE and Firefox authentication proceeds as normally but on Chrome 
based browsers, CORS preflight request is sent to IdP first. This is a 
HTTP OPTIONS type request.

We had CORS filter set up in the Tomcat server Shibboleth is running in, 
but still the OPTIONS request was met with a 403. After some 
investigation I notice shibboleth/edit-webapp/WEB-INF/web.xml contains 
the following:

<!-- Block commonly flagged methods by using an empty auth-constraint. -->
     <security-constraint>
         <web-resource-collection>
             <web-resource-name>Non-API Content</web-resource-name>
             <url-pattern>/*</url-pattern>
             <http-method>PUT</http-method>
             <http-method>PATCH</http-method>
             <http-method>DELETE</http-method>
             <http-method>OPTIONS</http-method>
             <http-method>TRACE</http-method>
         </web-resource-collection>
         <auth-constraint/>
     </security-constraint>
	
Now, this seems to flatly block OPTIONS requests. When I comment out the 
line and rebuild and redeploy the webapp, Tomcat starts to respond 
correctly to CORS requests, with the applicable response headers included.

Is this the right way to proceed or is some other type of configuration 
advisable? I understand that years ago OPTIONS requests might have been 
quite rarely used, but I imagine other users might be hitting this same 
problem nowadays.

Br,
Ilkka Lindblom