Microservices and Security -Part 1
Microservices architecture is everywhere — including throughout Medium. With increasing demand to roll out new features, microservices emerged as a viable way to structure large applications. There are already plenty of contents available on microservices. If you’re still struggling to understand the benefit of microservices, then let’s try to understand it through the example below:
Imagine you’re given the task to build a city. This is your primary application. To make your city an ideal place to live, you’ll want to include the following facilities (the different services for your main application):
- Include well-built houses with reliable water and electricity connections (maybe even Wi-Fi, who knows)
- Build infrastructure to make commutes and transportation easy and accessible.
- Construct health and education systems
Sounds like a great town, right? Now, imagine you want to add one more school or rebuild part of a road. This doesn’t mean that you should take down the entire city, change the road, and then turn the lights back on. You need to build a decoupled system, so you can modify exactly where you want without impacting the entire city. You can establish departments for individual services, and they can look after it. This is the kind of flexibility you find in software if development follows a microservices architecture.
So as we saw in the example above, running and maintaining multiple services is key to the larger mission — a high-quality application.
But — we’re not done with the city example.
We can’t forget security.
People should feel safe in their city, and there should be a proper arrangement to handle any kind of attacks on the city. This post is all about implementing security across your entire microservices architecture.
Before I dive into microservices, I should note that Martin Fowler does a great job of discussing the technical details of this architecture on his site.(Definitely check it out).
Security
As we all know, security is very important everywhere. You may be well aware of Facebook’s data leak, where users’ personal data was compromised. There have been several other, critical data breaches and hacks in the past few years as well. Taking these issues very seriously, the European Union (EU) introduced the General Data Protection Regulation (GDPR), which came into effect on 25 May, 2018.
In order to ensure security in your application, you have to know who a user is and what they are allowed to do. Identity management systems (IMS) are there to verify and authorize anyone on your servers, devices, and in your API. Identity is always at the heart of API security, enterprise security, and mobile security. This is one of the many indicators that push thinkers like David Birch to claim that “identity is the new money.”
Why is security more important in microservices?
In a microservices architecture, you’re making a lot more of your system’s functionality directly exposed to the network. That puts it in closer reach of potential attackers, or “increases the attack surface” as a security pro would say, so security becomes very important.
CIA Rule in Software Security:
Confidentiality: no one can access what belongs to you.
Integrity: nobody can change any information without your consent.
Availability: you can access data when you need it.
Details can be found here.
OAuth 2.0:
OAuth 2.0 is an open standard for access delegation.
It is commonly used when Internet users grant websites or applications access to their information on other websites or applications, without giving their password to that website or application.
What does access delegation mean?
Delegated access is basically asking an entity to perform some work or task on your behalf. You might have personally experienced delegated access in today’s digital world, where you might have granted access to your Gmail, Facebook or Twitter accounts to another application.
The most common OAuth 2.0 grant types are listed below:
OpenId:
According to the official OpenID website, OpenID is “a free and easy way to use a single digital identity across the Internet.”
Conceptually, an OpenID is a decentralized authentication protocol that can be used to verify your identity across the web. You can supply a personalized URL as OpenID, registered with an OpenID service provider as a valid credential to serve for authentication (for example at login).
The OpenID Connect, a standard specification from the OpenID Foundation, is similar to OAuth; it provides an additional token that provides information about the user. The token can be used within a JWT (i.e JSON Web Token) by getting signed by the authorization server to establish a trusted connection between the server & the client.
JWT:
A JSON Web Token (JWT) is a JSON object that is used as an exchanged mode of information between two entities (parties), which is safe and has a fixed format defined in RFC 7519.
The format for JWTs is header.payload.signature
Header
The header normally has two parts: the type of token and hashing algorithm
For example:
{
“alg”: “SHA256”,
“typ”: “JWT”
}Here,
“typ” key represents that the object is a JWT type,
“alg” key represents which hashing algorithm is being used, like HMAC SHA256 or RSA, to create the JWT signature component.
Then, this JSON forms the first part of the JWT by encoding to Base64Url.
Payload
Payload is the second part of the token, which contains all possible claims.
Claims are statements about an entity (typically, the user) and additional metadata.
You can check more about claims here.
An example format of payload :
{
“sub”: “1234321789”,
“name”: “Salvatore Incandela”,
“admin”: false
}The payload is then the Base64Url encoded to form the second part of the JSON Web Token.
Signature
To generate the signature in JWT, we have to take the encoded combination of header and payload plus a secret, the algorithm specified in the header, and sign that.
For example, the signature will look like this if you want to use the HMAC SHA256 algorithm:
HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload), secret)The signature ensures the message wasn’t changed along the way, and, in case tokens were signed with a private key, it can also verify the identity of the sender of the JWT.
The actual purpose of using JWT is to prove that the sent data was created by an authentic source. Its purpose is not to hide or obscure data. The data inside a JWT is encoded and signed, not encrypted.
Identity propagation is one of the major challenges in a microservice architecture. After the authentication, the verified identity of the user needs to pass to the next downstream microservice in a trusted way, so that the security between microservices does not break. This is challenging without JWT.
The use of the JWT is to carry user information.
You can think of bearer tokens like cash. If you find a dollar bill on the ground and present it at a shop, the merchant will happily accept it. She looks at the issuer of the bill and trusts that authority. The saleswoman doesn’t care where you found it. Bearer tokens are the same.
Conclusion
In this Blog, we have seen the importance some of the popular digital security implementations such as Oauth 2.0, OpenID and JWT. JWT plays an important role in dealing the security aspect within microservices.
As identity Propagation is an important aspect of Microservice Security.
Sometimes, it becomes difficult to implement security on our own. This is where open-source IDAM plays a very important role in application development by taking the burden of security off our shoulders (typing fingers?).
In the next blog, we will see Securing Microservices using keycloak in detail which is one of such open-source IDAM by Redhat.
Thanks!!
NB: Use of above images complies with fair use standards. More information on can be found here.
