The Secure Sockets Layer (SSL) offloading feature of the Azure Toolkit for Eclipse allows you to easily enable Hypertext Transfer Protocol Secure (HTTPS) support in your Java deployment on Azure, without requiring you to configure SSL in your Java application server.
This not only helps offload the SSL processing effort from your application server to a separate mechanism, it greatly simplifies the configuration needed to achieve SSL functionality in your deployment. This feature is intended to work with any type of Java application server.
The Azure Toolkit for Eclipse achieves the SSL offloading functionality by relying on special software automatically installed and configured in each instance of a role where you have enabled it.
The job of the SSL offloading mechanism is to receive web requests on the public port configured for HTTPS, before your Java application server receives them. The SSL offloading mechanism performs the necessary process of decrypting the requests and then forwards them to your application server as regular HTTP requests on your server’s HTTP-handling private port (e.g. 8080), not as HTTPS requests.
This way, your application server remains unaware that requests it is receiving were originally HTTPS, and is only receiving and processing them as HTTP. Your application server therefore requires no additional configuration unique to achieving SSL support.
Also, because the SSL decryption and forwarding is taking place within the boundaries of the same cloud service deployment, the security intended by using HTTPS is preserved.
SSL offloading enables common scenarios where session affinity (also known as sticky sessions) is used in conjunction with HTTPS.
The mechanism behind SSL offloading relies on an Internet Information Services (IIS) module called Application Request Routing (ARR), and an agent that dynamically configures ARR at runtime. This is the same mechanism that enables the session affinity feature, and the code behind this mechanism allows SSL offloading and session affinity to be enabled on the same role at the same time (although you can use either feature without also using the other).
Because of that shared logic, however, SSL offloading imposes an important restriction on how it can be used with session affinity: both must use the same endpoint if both are enabled on the same role. The toolkit allows SSL offloading to be enabled on only one endpoint per role. Similarly, it enables session affinity to be configured on only one endpoint per role. This effectively means, for example, that you cannot enable HTTP traffic on port 80 with sticky sessions enabled, and HTTPS traffic on port 443 with SSL offloading enabled, on the same role. The Eclipse toolkit enforces the restrictions entailed by the coexistence of SSL offloading and sticky sessions in each feature’s respective configuration user interface (UI).
You may however enable HTTP and HTTPS on two different roles within the same cloud service. One role could be configured to handle HTTP (port 80) traffic with sticky sessions enabled and without SSL offloading enabled, while the other role could be configured to handle HTTPS (port 443) traffic with SSL offloading enabled, with or without session affinity enabled.
As long as SSL offloading is enabled on a different role than sticky sessions, the two features do not (and cannot) share the same input endpoint, thereby allowing you to handle both HTTP and HTTPS requests and use sticky sessions for each at the same time. Note that sessions are not preserved across roles, so if you establish a session in an HTTP-handling role instance, that session will not be preserved if subsequent web requests are sent using HTTPS and thereby received by the HTTPS-handling role.
Note that beginning with the April 2014 release, in cases where your cloud service contains only HTTPS role(s), if the user request specifies HTTP, it will automatically redirect to HTTPS. There is no need to create a separate role to handle the HTTP requests.
If your application needs to determine whether the request it received was originally received via HTTPS or HTTP, it can check the
X-FORWARDED-PROTO request attribute. If the
X-FORWARDED-PROTO request attribute does not exist, that means the original request was received via HTTP.
A common requirement of many application scenarios is user authentication with secure communication between the authenticated user and your application. The Azure Toolkit for Eclipse makes that possible and simpler with the combined use of:
Access Control Services (ACS) Filter, to simplify user authentication.
Session affinity, to maintain the session information about the authenticated user.
SSL offloading, to maximize the security of the user’s communication with your application.
Commonly, one of the first steps in the user’s interaction with your Java application is authentication. If you use the ACS Filter for that, the web request returned from ACS after a successful user login contains information about the user that your application will then use for authorization.
Once your application has completed a successful authorization process on the basis of the user’s identity, your application will then likely have a need to cache some information about the user in the current session. To preserve the session state in this scenario, you would enable session affinity.
Finally, to maximize the security of your authenticated user’s subsequent interaction with your application, you would enable SSL offloading. These three features thus complement each other to enable this common scenario.
SSL offloading does not work in the Compute Emulator.
The same certificate used for Remote Access cannot be used for SSL offloading. The same certificate used for the ACS Filter, however, may be used for SSL offloading.
If the SSL certificate has already been uploaded into Azure by the user manually (not via the toolkit), there is no way of determining whether the certificate in the cloud is a Personal Information Exchange (PFX) certificate or public key (CER) certificate. Azure allows both PFX and CER certificates to be uploaded, but offers no way to distinguish between the two certificate types programmatically. SSL requires PFX though, so if a CER was uploaded into Azure instead of a PFX, the Eclipse toolkit will not be able to catch the issue and the deployment will fail. An informative error message will be provided in the Azure Activity Log within Eclipse if this is encountered.