Overview

 

When you access a web application in HTTPS all communications between your web-browser and the web server are secure and only visible by you and the destination. However, if you begin navigating in a web application in HTTP and then switch to HTTPS you are susceptible of re-using some information in your secure session that others may have had access to earlier.

 

One such piece of information is your session cookie. When you first access a web site using HTTP all the communications are in plain text – and an attacker might easily gain access to a specific piece of information – your session cookie. If that happens that attacker might be able to present himself to the system as if it were you by simply reusing your session cookie.

 

If you do not know what a cookie is you can read all about it here: https://en.wikipedia.org/wiki/HTTP_cookie. 

 

Secure cookies

 

To avoid these problems there is the notion of secure cookies. Secure cookies are normal cookies that the web-browser receives but which it only sends back to the server if the connection used is HTTPS. This security enhancement also dictates on how the web applications should work: a secure cookies should only be sent by the web server on a HTTPS connection.

 

Secure cookies can be easily enabled in the Agile Platform to achieve this extra security milestone. When you do so, the following occurs:

 

All of this means that, to pursue a secure cookies strategy for your session cookie you must ensure your application only has links using HTTPS. If you are only using links to public screens in your applications you have the problem solved by the Agile Platform. If not, you need to ensure you only use relative links – or that you hardcode the HTTPS on all links you produce manually.

 

How to set up secure cookies

 

Since Agile Platform applications are actually standard .NET web apps deployed in IIS, the simplest way to activate secure session cookies is to do it at the .NET Framework level. This can be done in two ways:
 

Note however that segmenting this for individual eSpaces requires that users access them in separate domains – which we can discuss later if some asks for it.

 

Setting up secure cookies is done using the requireSSL property of the httpCookies element in .NET (documentation from microsoft).

 

Set secure cookies for all applications in one or all front-ends

 

To set the secure cookies at front-end level you can just apply the setting in the global web.config file of the front-end you wish to configure. The file is located at %WINDIR%\Microsoft.NET\Framework64\v2.0.50727\Config\web.config, inside the configuration/system.web section. Simply add the following XML:

 

            <httpCookies requireSSL="true" />

 

The final result will be similar to what you see in the below image:

 

      

 

 

After saving the file this will apply to everything running in IIS for that front-end – including Service Center and LifeTime. 

 

 

Set secure cookies for one or more individual eSpaces (in all the front-ends)

 

To set secure cookies at the espace level  you need to use the Service Center Factory Configuration component available in the Forge. This will be used to add the same XML setting above, but it will be added to the web.config file of the eSpaces you choose instead of in the global one. This is made through a shared configuration. You can find the XSD template of the shared configuration used and below you can see a screenshot with the configuration settings:

     

 

After creating the shared configuration you need to apply it to the eSpaces that require secure cookies. Finally you will need to republish the eSpaces to make the change effective.

 

Final notes

 

Secure cookies can be easily implemented in the Agile Platform for .NET, either globally in a front-end or for individual eSpaces using the above instructions.

Finally I would like to thank Miguel João for the initial draft of this document.

 

If you have any questions or would like to further extend the information in this post feel free to reply.

 

Cheers,

 

Acácio Porta Nova