Azure - Single Instance SLA is here!!

Although Microsoft hasn't announced this yet officially but it has been communicated in one of their events. 

Being the first ever cloud vendor to do so, Microsoft Azure will now be offering SLA on services hosted on single instance!

Single instance in Azure will now be covered under 99.9% SLA whereas double instance in Availability Set will have 99.95%. Although it comes with a restriction of how you set it up but at least an official commitment is there.

In order to get an SLA on single instance in Azure, the storage used for the VM Operating System and Data disks must be using Premium Storage. Premium Storage offers a much higher level of availability and performance with 5,000 IOPS per disk, versus 500 IOPS per disk with Standard Storage. The way Premium storage offers this is by utilizing SSD storage drives within the data center that are located on the same server hardware where the VM is running. Premium storage also offers a much higher throughput rate per disk of 2 Gbps.

Having announced that it is still recommended to host services on more than 1 instance configured under Availability Set to get higher SLA and availability & reliability.

For more details around virtual machines SLA on Azure, read here.

SSL Offloading

SSL offloading is delegating the process of encrypting/decrypting data sent over HTTPS or Secure Socket Layer (SSL) protocol from your web server to a separate device. This separate device is specially designed to perform SSL acceleration & termination.

Since this CPU intensive task of encrypting/decrypting data is moved onto a separate device, this allows the web server to dedicate important CPU resources to other application processing tasks, which can really boost performance of your application. This optimization of CPU consumption can help in saving costs by maximizing the utilization of servers and eliminating the need to buy additional hardware.

Below is a pictorial representation of how SSL offloading looks like.  (Image taken from internet)

Some benefits of SSL offloading:-

• Improved performance – The biggest performance hit when doing SSL decryption is the initial handshake. To improve performance, the server doing the decryption caches SSL session IDs and manages TLS session tickets. If this is done at the proxy, all requests from the same client can use the cached values. If it’s done on the backend servers, then each time the client’s requests go to a different server the client has to re-authenticate. The use of TLS tickets can help mitigate this issue, but they are not supported by all clients and can be difficult to configure and manage.
• Better utilization of the backend servers – SSL/TLS processing is very CPU intensive, and is becoming more intensive as key sizes increase. Removing this work from the backend servers allows them to focus on what they are most efficient at, delivering content.
• Intelligent routing – By decrypting the traffic, the proxy has access to the request content, such as headers, URI, and so on, and can use this data to route requests.
• Certificate management – Certificates only need to be purchased and installed on the proxy servers and not all backend servers. This saves both time and money.
• Security patches – If vulnerabilities arise in the SSL/TLS stack, the appropriate patches need be applied only to the proxy servers.

Now, SSL offloading can be implemented in two different ways depending upon what level of security you need. Every stage has its own pros & cons.

Option 1:

SSL offload on a separate device like load balancer in front of your web servers and then let them communicate over HTTP. This is shown in the picture above.

Pros, better performance & no overhead of installing and maintaining the certificates on web servers. 

Cons, the traffic between LB & Web servers is over HTTP making it vulnerable to packet sniffing sort of attacks. Secure cookies option doesn’t work. I will come back to this again.

Option 2:

SSL offload on your load balancer but re-encrypt the data with a different certificate between LB & Web servers. This makes your communication end to end secure still benefiting the intelligent routing as the data is decrypted once on LB.

Here how it looks like:-

Now, this would look like more of an overhead as we are doing encryption/decryption twice plus maintaining more certificates but no, this approach has better performance then not doing SSL offloading at all. Here is how.

1. Use a different certificate between LB & Web servers due two reasons. First, this certificate could be self signed with a long expiry time. This will reduce the overhead of maintaining certificates. Secondly, use a low length private key certificate for this may be 1024 or 2048 bit. A low length key reduces the tasks of encryption/decryption compared to more advanced keys used publicly which are comparatively much large.
2. Another thing you can configure here is the right value of Keep-Alive attribute. Please be careful with this setting as Keep-Alive has implications both ways.

And finally, coming back to Secure cookies I mentioned in Option 1. Marking cookies Secure means you are restricting the transmission of cookies over non-SSL traffic. Obviously this is a problem in option 1 as the communication between your LB & web servers is over HTTP hence this doesn't work there. Although that is not end of the world and you can still implement some hacks to get Secure cookies working but worth comparing both options if you require those.

Hence always perform SSL offloading as with the increase in size of certificate keys, the encryption/decryption process is getting more and more CPU intensive and can seriously hit the performance of your web servers.

Database Scaling Jargons

If you are in IT then no matter what you do (develop, deploy or maintain applications), you would have seen database issues. And wherever I see database issues, there comes a jargon of database scaling terms which are thrown on them. Most of them mean the same thing others are nowhere near the problem they are trying to address.

Let’s understand few terms listed below:-

1. Scale Up vs Scale Out
2. Horizontal vs Vertical Scaling
3. Horizontal vs Vertical Partitioning
4. Sharding

Database Scaling is like a bouncer in a bar. Either you need one strong one or multiple to handle the rowdy crowd. Not sure where I got this analogy from but I like it so I am keeping it :) Below is the explanation.

So with this in mind, let's understand few terms which are not so different to each other like Scale Up vs Horizontal Scaling and Scale out vs Vertical scaling. 

Scale Up or Vertical Scaling means buying bigger boxes for your database with more memory and processing power. While this works, you might pay four to five times what you paid for your previous solution, and you’ll only get twice the performance. 

Pros:-

• Less power consumption than running multiple servers
• Cooling costs are less than scaling horizontally
• Generally less challenging to implement
• Less licensing costs
• (sometimes) uses less network hardware than scaling horizontally (this is a whole different topic that we can discuss later)

Cons:-

• PRICE, PRICE, PRICE
• Greater risk of hardware failure causing bigger outages
• generally severe vendor lock-in and limited upgradeability in the future 

On the other hand Scale Out or Horizontal Scaling means adding more servers with less processors and RAM. This is usually cheaper overall and can theoretically scale infinitely. 

Pros:-

• Much cheaper than scaling vertically
• Easier to run fault-tolerance
• Easy to upgrade

Cons:-

• More licensing fees
• Bigger footprint in the Data Center
• Higher utility cost (Electricity and cooling)
• Possible need for more networking equipment (switches/routers)

Horizontal Vs Vertical Partitioning

There are two different methodologies to deal with same issues but requires change in database schema. Below is what we do in these:-

Horizontal Partitioning

Horizontal partitioning divides a table into multiple tables. Each table then contains the same number of columns, but fewer rows. For example, a table that contains 1 billion rows could be partitioned horizontally into 12 tables, with each smaller table representing one month of data for a specific year. Any queries requiring data for a specific month only reference the appropriate table.

This is also called Sharding.  There are some arguments that Horizontal partitioning is not exactly Sharding but underlying idea is same but just when you use a reference of keys to identify which partition will hold the data. That is Sharding. Below picture explains what I am trying to say.

Vertical Partitioning

Vertical partitioning divides a table into multiple tables that contain fewer columns. The two types of vertical partitioning are normalization and row splitting:

• Normalization is the standard database process of removing redundant columns from a table and putting them in secondary tables that are linked to the primary table by primary key and foreign key relationships.
• Row splitting divides the original table vertically into tables with fewer columns. Each logical row in a split table matches the same logical row in the other tables as identified by a UNIQUE KEY column that is identical in all of the partitioned tables. For example, joining the row with ID 712 from each split table re-creates the original row.

Like horizontal partitioning, vertical partitioning lets queries scan less data. This increases query performance. For example, a table that contains seven columns of which only the first four are generally referenced may benefit from splitting the last three columns into a separate table. Below picture explain vertical portioning.

Database scaling could be fun to solve but before you ever get into resolving the issue, you should first understand the underlying problem with your database. Lot of database performance issues can really be dealt with by fixing your schema and fine tuning your queries. 

 Once you get this right and you still have issues, then you further need to perform in depth analysis of why your performance is getting a hit. Do you need a more writes than read. Is your queries processor intensive or high in numbers? All these answers will help you to choose the right scaling option for your database.

Hope you would have found this interesting. I surely enjoyed writing this :)

Simple OpenAM Post Authentication Plugin

Background: OpenAM Post authentication plugin is a java program you can write which gets executed every time a user is authenticated against OpenAM. You can read more about it here

Requirement: We have three applications which need to perform SSO. If user login on one and navigate to other, it should accept the authenticated user and setup the context.  Nothing special here, all three belong to same realm in OpenAM where two secured via OpenAM Policy Agent and one doing REST authentication. 

Post authentication plugin is opted to fulfill a special need here. Some users are being migrated to OpenDJ without email address and we wanted to make sure that whenever they login first time, they are forced to update the email address. This check is performed by our PAP. If user profile doesn’t have an email address then user is navigated to update email screen.

So let’s start with our PAP and we can discuss the details as we go.

Pre-requisites for PAP:-

Eclipse
OpenAM Client SDK

The easiest way to start this is to download the SamplePAP from ForgeRock website and modify it as per your needs.

Below is the code for PAP:-

public void onLoginSuccess(Map requestParamsMap, HttpServletRequest request, HttpServletResponse response,

SSOToken token) throws AuthenticationException {

try {

AMIdentity id = IdUtils.getIdentity(AccessController.doPrivileged(AdminTokenAction.getInstance()),

token.getProperty(Constants.UNIVERSAL_IDENTIFIER));

Set<String> userEmails = id.getAttribute(MailAttributeName);

String uid = id.getName();

if (userEmails.isEmpty()) {

//PG: User doesn't have an email associated. Setting TokenID in request and redirecting

String tokenId = token.getTokenID().toString();

logger.error("Provider PAP: Email not found for user - " + uid

+ ". Redirecting for update email with token - " + tokenId);

request.setAttribute("bupaProviderPapId", token.getTokenID());

request.getRequestDispatcher("/UpdateEmail.jsp").forward(request, response);

} else {

logger.message("Provider PAP: User - " + uid + " has a valid email address associated");

}

} catch (Exception e) {

logger.error("EXCEPTION occured in Provider PAP: Error message - " + e.getMessage());

logger.message("EXCEPTION details: " + e.getStackTrace());

}

}

Couple of things to note in above code:-

Getting the attributes of the logged in user from AMIdentity class and when not available forwarding the token as a request attribute to UpdateEmail handler.

In order to /UpdateEmail.Jsp page to open in OpenAM context, you would have to create a Servlet which UpdateEmail.Jsp will be part of and a servlet handler. This than can be hooked into your OpenAM by copying the servlet handler, JSP at correct locations and updating web.xml file inside WEB-INF.

If the location in web.xml is correct, the servlet handler will pick the request and update the email.

A downside, since you are altering the usual execution of OpenAM’s post authentication classes, user is not yet logged in and the cookie is not there yet. User will have to login again post updating the email address.

Word of advise: In OpenAM, you can configure post authentication plugin class at two different places. One under Access Control -> Realm -> Authentication -> Authentication Chaining -> Name of Chain -> Post Authentication Processing Class

Second, under Access Control -> Realm -> Authentication -> All Core Settings -> Post Authentication Processing -> Authentication Post Processing Classes

Do not configure at later if you only want this class to be processed for users trying to log in. Apart from user, there are lot of other things which tries to authenticate itself against OpenAM like Policy Agent Groups and profile etc. If you configured your PAP at core Authentication settings as well then it will be executed for everything including users and other ForgeRock components. You might want this or may not need it so choose accordingly.

Also, just for information. We didn’t only rely on our PAP to handle/catch users who doesn’t have email address associated with them. We added an LDAP filter in policy settings of Policy agent to block users who doesn’t have email address associated with them.

Hope this would have helped and happy PAP writing.

Cookies vs HTML 5 Web Storage – Choose wisely

Cookies are something which everyone in web development must have heard off and would have used although I am bit surprised to know the awareness of HTML5 Web Storage among people.

It wouldn’t be fair to say that it’s a new concept as it’s been a while since Web Storage is around and yesterday post encountering another blank face to Web Storage, I thought of writing and sharing this on my blog. So let’s get on to it.

HTTP Cookies

I am not going to explain much about HTTP Cookies. In short, Cookies are small piece of information sent from web server to web browser and stored on client’s machine in text files.

HTML 5 Web Storage

With web storage, web applications can store data locally within the user's browser. Web Storage comes in two flavors, local storage and session storage (the difference between the 2 will be explained later)

Enlightenment

You must be thinking, looks like both does the same thing and what’s the difference. Well this is where it gets interesting.

There are three major difference between how Cookies and Web storage works.

1. Web storage provides far more storage capacity than cookies. Where cookies are limited to 4 KB, the benchmark capacity for Web Storage is 5 MB and even this limit varies with browsers. Some browsers provide even higher storage.
2. Second and the most significant difference is, Cookies are sent with each HTTP request once they are set but web storage data is not. This can improve the performance of your site.
3. Web Storage is more secure than Cookies as it is designed to operate at domain & protocol level.

Web storage is definitely the future of Cookies and even in HTML 5, you have local storage based Cookies available. Although I personally like Web Storage but it would be unfair with Cookies to not mention the two downsides of Web Storage.

1. Web Storage also been around from a while now but is only supported on browsers supporting HTML 5. Hence if you need to provide support for legacy browsers then this could be an issue for you.
2. Web Storage is completely client based hence it cannot be accessed or modified from server side.

OK…now since we understood the difference between Web Storage and Cookies, Let’s discuss Web Storage in more details.

As I mentioned earlier, Web storage comes in two forms. Local Storage and Session Storage. The difference is really simple and straight forward as explained below.

Local Storage

Local Storage, stores data permanently in the browser it won’t be deleted or erased automatically. You would have to manually delete those items if we don’t want. The behavior is similar to persistent cookies without any expiration date.

This is how you can set/get local storage from JavaScript as below:-

// Set

localStorage.setItem("fullName", "Piyush Gupta");

// Get

var name = localStorage.getItem("fullName");

Or below is also valid

// Set

localStorage.fullName = "Piyush Gupta";

// Get

var name = localStorage.fullName;

Session Storage

Session Storage is equal to the local Storage, except that it stores the data for only one session. The data is deleted when the user closes the specific browser tab. 

Please note, the data can survive page load or redirects but is bound to one specific tab. Any new tab or window cannot access session data set by previous tab.

You can set/get session storage from JavaScript as below:-

// Set

sessionStorage.setItem("fullName", "Piyush Gupta");

// Get

var name = sessionStorage.getItem("fullName");

Or below is also valid

// Set

sessionStorage.fullName = "Piyush Gupta";

// Get

var name = sessionStorage.fullName;

Word of advice:-

As I mentioned already, although Web Storage is now supported by almost all browsers but please don’t blindly assume this and always perform a check whether web storage is supported by user's browser or not before using it. You can do this by below:-

if(typeof(Storage) !== "undefined") {

    // Code for localStorage/sessionStorage.

} else {

    // Sorry! No Web Storage support..

}

You can check the list of supported browsers here.

That’s all I had to share with you. Choose wisely when deciding how you want to keep you data on client side. Cookies are good and still widely used but Web Storage does provide some benefits over it.