Configuring SameSite for FileHold

It is possible to embed document viewing, the add document wizard and search results into other applications. This is typically done by adding an iframe to the other application to hold the simplified FileHold page. Up until 2020, this has not required any special configuration or consideration for most browsers, but on going browser security updates have added new requirements for such an integration.

The changes described in this article assume the reader is familiar with the HTTP protocol, HTTP headers, the Internet Information Services (IIS) URL Rewrite module and regular expressions. Contact the FileHold professional services team if you need assistance to make these changes.

The SameSite attribute was added to cookies in 2016 and revised in 2018 to address security concerns related to third party cookies. Starting in 2020, browsers became more aggressive in their handling of cases where the SameSite attribute is not explicitly provided. 

The SameSite attribute is intended to allow a browser to determine if a cookie can be used across multiple domains and can have one of three values: Strict, Lax and None. Strict and Lax are similar in that they both prevent cookie use across domains, but Lax does provide some exceptions. The only option to allow cross site cookie use is None. Until 2020, leaving out an explicit SameSite attribute was the same as using SameSite=None. In 2020 this changed for Google Chrome and most browsers to default to Lax; do not allow cross site cookies for most cases. You can return the default behavior in the browser to pre-2020, but that will affect every web site and should only be considered a temporary measure.

The whole question for cross site cookies becomes important if you embed parts of the FileHold application into another application through an iframe or similar method. For example, if MyOwnApplication includes an iframe that displays the FileHold Add Document Wizard in locked mode, you have a cross site situation. Since FileHold relies on a cookie called FHLSID to maintain a user's authenticated session and, if cross site cookies are prevented, the authenticated session is lost and the user spends all their time on the log in page.

Adding the SameSite attribute to the FileHold session cookie

The most effective method to introduce the SameSite cookie to FileHold version 16.3 or earlier, is to use the IIS URL Rewrite module.

  1. Install the URL Rewrite module in your IIS system. This is available at no cost from Microsoft.
  2. Create a new blank outbound rewrite rule and call it "AddSameSiteAttribute" or something similar.

The location where you place the rewrite rule is an open question and depends on how you intend to use it. For example, if you are applying the Strict value to the attribute, it might make sense to apply it at the highest level. If you are applying the None value, then it may only be useful for the WebClient. Of course, you can apply rules at a lower level in the site to override a higher level rule.

  1. In the Match section, change the matching scope to Server Variable.
  2. Change the variable name to RESPONSE_Set-Cookie as we will be modifying the HTTP response header "Set-Cookie".
  3. Add the regular expression ^.*FHLSID=.*$to the pattern field.

You can test that you added the regular expression correctly using the following input data to test FHLSID=c2108317-6c1f-455d-84b0-3fb9c1b66122; path=/;. If you have a valid regular expression the test results will be green and you will see a list of back references. In our example, there should be exactly one, {R:0}, which contains the entire input data.

  1. In the Action section, change the value of the action properties to {R:0};SameSite=None.or similar. This will append the SameSite attribute to the end of the current cookie configuration. By default it will replace the existing server variable, which is what we want. By appending the attribute in this way, we preserve other attributes such as Secure or HttpOnly that may have been set elsewhere.

This example could be used for the case described in the opening when you would like the FileHold session id cookie to be available in the context of the iframe for another site, but you could also add it to include the Strict value to maximize the SameSite security feature where you are not needing cross site cookies.