Neema Bahramzad is a senior Computer Engineering major at the Jeffrey S. Raikes School of Computer Science and Management at the University of Nebraska-Lincoln and was one of our 2012 summer interns. He is also co-founder, along with Caitlin Bales, of Locabal – of a new company whose mission is to connect producers of handcrafted items with buyers locally and globally. Here he shares his experience with Amazon’s Elastic Beanstalk solution.

The other week I had the privilege of setting up staging and release servers for Locabal’s website. For ease of scalability, we decided it would be best to deploy our ASP.NET website on Amazon’s Elastic Beanstalk, which is their Platform as a Service solution that manages server instances and load balancers, and their respective configurations. We just drop our project into the Elastic Beanstalk container, and it manages the provisioning of the servers to run our application. It will even monitor the health of your application and send you emails and/or spin up more server instances based on the health rules you specify. That stuff is great, but the way in which Elastic Beanstalk handles SSL encryption took us by surprise. So let’s take a look at what we learned about how SSL encryption is handled using these tools.

Having SSL connections terminated at the load balancer is the preferred method of encryption when using Amazon’s Elastic Load Balancer (which is a component of the Elastic Beanstalk solution). This means all of the traffic to our website, both port 80 and port 443, makes it to the load balancer. From there the load balancer communicates with the servers exclusively over port 80. Setting up your SSL certificate is fairly straightforward with the Elastic Load Balancer, but the problem occurs when your application needs to check if the client is connected to the site with a secure connection.

Amazon’s Elastic Load Balancer

Using the [RequireHttps] attribute introduced in ASP.NET MVC2 does not work when using Elastic Beanstalk because the connection between the load balancer and application server is not secure. However, you don’t need to be concerned with the security of the connection between the load balancer and the server but you do need to be concerned about the connection between the client and the load balancer. To do this, Amazon provides a clever feature with their load balancer.

At the load balancer, an extra header is added to the original request made by the client. The header key is “X-Forwarded-Proto” and it will have a value of either “http” or “https”. By checking this header, your application can determine if the client is using a secure connection.

At the load balancer, an extra header is added to the original request made by the client.

There are several ways of accomplishing the redirect, but unfortunately I didn’t get much help from Amazon’s documentation so I set out on my own. The best solution I could come up was to write a custom attribute to replace the [RequireHttps] attribute that people expect to use in MVC. Below is the code for our attribute, which borrowed heavily from Stack Overflow user Alex’s answer. I just modified his code to work with Elastic Load Balancer.

public class RequireSSLforEBSAttribute : FilterAttribute, IAuthorizationFilter
 {
 public virtual void OnAuthorization(AuthorizationContext filterContext)
 {
 if (filterContext == null)
 {
 throw new ArgumentNullException("filterContext");
 }
if (!String.Equals(filterContext.HttpContext.Request.Headers["X-Forwarded-Proto"], "https",
 StringComparison.OrdinalIgnoreCase))
 {
 HandleNonHttpsRequest(filterContext);
 }
 }
protected virtual void HandleNonHttpsRequest(AuthorizationContext filterContext)
 {
 if (filterContext.HttpContext.Request.Url.Host.Contains("localhost")) return;
string url = "https://" + filterContext.HttpContext.Request.Url.Host +
 filterContext.HttpContext.Request.RawUrl;
 filterContext.Result = new RedirectResult(url);
 }
 }

Despite Amazon’s documentation being so voluminous that is was difficult to find a solution to the redirect problem, I was able to leverage other sources to get everything implemented. Overall, we are very happy with how quickly we were able to set up our staging and release servers in the Amazon ecosystem. The increasing availability of services like this makes it much easier for start-ups to compete in the marketplace by providing an affordable alternative to opening our own data center.

Share This