See discussions, stats, and author profiles for this publication at: [Link]
net/publication/323770504
Microservices API Security
Article in International Journal of Engineering and Technical Research · January 2018
DOI: 10.17577/IJERTV7IS010137
CITATIONS READS
2 1,685
1 author:
Jyothi Salibindla
Karsun Solutions LLC
2 PUBLICATIONS 4 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Microservices API Security View project
All content following this page was uploaded by Jyothi Salibindla on 15 March 2018.
The user has requested enhancement of the downloaded file.
Published by : International Journal of Engineering Research & Technology (IJERT)
[Link] ISSN: 2278-0181
Vol. 7 Issue 01, January-2018
Microservices API Security
Jyothi Salibindla
Karsun Solutions LLC
Herndon, VA USA
Abstract—Microservices have become the hot term since In order to manage complexity, and to achieve the required
2014. This particular programming methodology involves an engineering quality factors such as robustness, adaptability,
architectural approach that emphasizes the decomposition of maintainability, and reusability, the problem (software system)
applications into single purpose, with implementation via the should be decomposed into modules such that each module has
Rest API. A new software development style that has grown from one concern. A concern is an identifiable requirement which
recent trends in software development/management practices, would evolve/change independently. Separation of Concerns is
Microservices are composable, fine-grained modules which can a guiding principal in software development centered on the
be independently deployable and scaled both vertically and
idea that programs should have distinct sections, with each
horizontally. This empowers the development, manageability and
section being responsible for its own concern.
speed to the changing market by adapting to Agile methods,
DevOps culture, cloud, Linux containers, and Continuous
Integration/ Continuous Development methods. This paper will
focus on the necessity for this methodology as well as it’s III. IMPLEMENTATION
corresponding API security options needed for securing all of the
A. Solution Space
back-end Microservices
In Object-oriented methods, the
Keywords— Microservices, API, Cross Cutting Concerns, OOB; separated concerns are modeled as
AOP; SoC;Token;Json Web Token objects and classes, which are
I. INTRODUCTION generally derived from the entities in
Problems in software manifest themselves in several ways the requirement specification and use
including budget overflows and project delays. Previous cases. In structural methods, concerns
methodologies in software development have been very are represented as procedures. Is it
inefficient, inferior in quality (bugs), and often do not meet the possible to get 1:1 mapping between
requirements of its client. Projects were unmanageable and the problems (concerns) and solutions
programming code has been difficult to maintain due to various (code modules)? Unfortunately, the
reasons. However, this situation has been changed by the answer is “No”. The key unit of
improvements in computing power, so much so that it has modularity in OOPs is the class. Most
outpaced the ability of programmers to effectively utilize those of the times, one class is not enough to provide the Module
capabilities. Various processes and methodologies have been functionality. Even though Object Oriented Programming
developed over the past few decades to improve software (OOP) is easy to understand and provides decent decoupling
quality management such as procedural programming and between the objects, it is not enough to address the common
object-oriented programming. Despite the improvement of concerns that are applicable throughout the application as it
development methodologies, software projects that are large, affects the entire solution. Implemented Patterns will be
complicated, poorly specified, and involve unfamiliar aspects, scattered/ tangled throughout system in the OOP.
are still vulnerable to large, unanticipated problems.
B. Cross-cutting Concerns
II. HISTORY
Depending upon the implementation language and the
Since the 1960s, several advances in programming theory corresponding abstractions provided by the language, some
have occurred. The discipline of programming has progressed concerns cannot be easily separated, and thus, are forced to
through several phases, with each new advance being touted as
map such concerns over many modules. Certain instances in
the next "better" way of programming. From structured
which this situation can be applied to are security, thread
programming, functional decomposition, object-oriented
programming, aspect programming. As per the Barbara Liskov, safety, transaction management, logging and tracing, profiling,
“The connections between modules are the assumptions which caching, pooling, persistence, etc.
the modules make about each other.” Modern software
systems are complex, and therefore are vital to implement a
new strategy with modular approach, built on the idea of
Separation of Concerns (SoC). SoC is traditionally achieved
through modularity and encapsulation, with the help of
information hiding. Layered designs in information systems are
based on Separation of Concerns (e.g., presentation layer,
business logic layer, data access layer, database layer).
IJERTV7IS010137 [Link] 277
(This work is licensed under a Creative Commons Attribution 4.0 International License.)
Published by : International Journal of Engineering Research & Technology (IJERT)
[Link] ISSN: 2278-0181
Vol. 7 Issue 01, January-2018
loosely coupled services. In Microservices architecture,
services should be fine-grained and the protocols should be
lightweight. The modular architectural style has been shown to
be particularly well suited to cloud-based environments and its
popularity has been exponentially rising.
Fig. 1. Module – Concern Mapping
Cross-cutting concerns are modularized using a new
abstraction called Aspect. It allows the developers to
concentrate on the functional capabilities rather than focusing
on individual cross-cutting concerns. Fig. 3. Example e-commerce application
C. Aspect Orientation Benefits of the Microservices Architecture:
Aspect Orientation is way to modularize cross-cutting • Each Microservice is relatively small
concerns. This model helps with identifying the system • Easier for a developer to understand
modules that could be factored out into separate modules (Fig.
2: A3, A5). These separated components/modules would then • The IDE is faster making developers more productive
be included in the system so that they could be used by
• The application starts faster, which makes developers
various other modules. more productive, and speeds up deployments
• Each service can be deployed independently of other
services which makes it easier to deploy new versions
of services frequently
• Easier to scale development. It enables the ability to
organize the development effort around multiple teams
• Improved fault isolation. For example, if there is a
memory leak in one service then only that particular
service will be affected.
Fig. 2. Aspect Oriented Model • Eliminates any long-term commitment to a technology
stack
D. Composition Drawbacks of the Microservices Architecture:
In order to divide the problem into composable units that
perform one identifiable task, it is pivotal to keep all of the • Developers must deal with the additional complexity of
operations in a unit at the same level of abstraction. This will creating a distributed system.
naturally result in systems with many small units, which in turn • Developer tools/IDEs are oriented on building
are far easier to test. Names become documentation, and this monolithic applications and don’t provide explicit
process will make previously-hidden reusable assets support for developing distributed applications.
discoverable.
• Testing across services can be more difficult, compared
E. Single Responsibility Principle to monolithic applications
This principle states that every module should have a single • Developers must implement the inter-service
responsibility, with which all its services should be narrowly communication mechanism.
aligned with that responsibility.
• Implementing use cases which span multiple services
IV. MICROSERVICE ARCHITECTURE without using distributed transactions can be arduous
Microservices are a variant of the service-oriented architecture • Implementing use cases which span multiple services
(SOA) style which structures an application as a collection of also requires careful coordination between the teams
IJERTV7IS010137 [Link] 278
(This work is licensed under a Creative Commons Attribution 4.0 International License.)
Published by : International Journal of Engineering Research & Technology (IJERT)
[Link] ISSN: 2278-0181
Vol. 7 Issue 01, January-2018
• Deployment complexity Authorization: Basic dm9yZGVsOnZvcmRlbA==
• Increased resource consumption
V. SCALING BY FUNCTIONAL DECOMPOSITION
One of the major driving forces behind any kind of
architectural solution is scalability.
The horizontal application scaling (which has been possible
even with monolithic architecture), and the Z axis represents
the scaling of the application by splitting similar things. The Z
axis idea can be better understood by using the sharding
concept, where data is partitioned and the application redirects
requests to corresponding shards based on user input. Fig. 4. Basic Authentication
The Y axis, however, is crucial in understanding the scope
of decomposition. This axis represents functional A majority of the Application Architectures will not secure
decomposition. In this kind of strategy, various functions can the backend services. As a common approach, the client will be
be seen as independent services. Instead of deploying the entire authenticated one time and allow the access to the HTTP
application only once the entire development is done, resources which will then internally call other resources and
developers can deploy their respective services independently return the results to the client. A major concern of this process
without waiting for the other development teams to finish their is that there is no authentication and authorization implemented
modules. This not only improves developer time management, on the client calls on the backend.
but also offers them much more flexibility to change and B. IP Whitelisting
redeploy their modules without needing to worry about the rest
of the application’s components. There are a couple of different Access to the APIs (Microservices) can be restricted by
ways of decomposing the application into services. One setting up a whitelist of IP addresses, however the problem
approach is to use verb-based decomposition and define with IP Whitelisting in the cloud environment is the elasticity;
services that implement a single use case such as “checkout”. the servers IP Address will change and come with new IP
The other option is to decompose the application by noun and Address after every maintenance window in the cloud.
create services responsible for all operations related to a C. OAuth2.0 Authentication
particular entity such as “customer management”. An
application might also use a combination of verb-based and OAuth 2.0 is the industry-standard protocol for
noun-based decomposition. authorization. The OAuth 2.0 authorization framework
Using Z-axis scaling each server runs an identical copy of enables a third-party application to obtain limited access to an
the code. In this respect, it’s similar to X-axis scaling. The big HTTP service. This can be done either on behalf of a resource
difference however, is that with the Z-axis circumstance, each owner by orchestrating an approval interaction between the
server is responsible for only a subset of the data. Z-axis splits resource owner and the HTTP service, or by allowing the
are commonly used to scale databases. Data is partitioned third-party application to obtain access on its own behalf.
(a.k.a. sharded) across a set of servers based on an attribute of An OAuth authentication flow defines a series of steps
each record. used to coordinate the authentication process between the
VI. API SECURITY application and HTTP service. Supported OAuth flows
One of the challenges to building any RESTful API is include:
having a well thought out authentication and authorization 1. Username-password flow: where the application has
strategy. Cross-cutting concerns like authentication, security,
direct access to user credentials.
and logging are always challenging and involve many
2. Web server flow: where the server can securely
stakeholders.
protect the consumer secret.
3. User-agent flow: used by applications that cannot
A. Basic Authentication securely store the consumer secret.
A client can authenticate to the API Gateway with a
username and password combination using HTTP Basic
Authentication. Basic Authentication is not considered to be a
secure method of user authentication (unless used in
conjunction with some external secure system such as SSL), as
the user name and password are passed over the network as
cleartext. With HTTP Basic Authentication, the client's
username and password are concatenated, base64-encoded, and
passed in the Authorization HTTP header as follows:
Fig. 5. OAuth2.0 Authentication
IJERTV7IS010137 [Link] 279
(This work is licensed under a Creative Commons Attribution 4.0 International License.)
Published by : International Journal of Engineering Research & Technology (IJERT)
[Link] ISSN: 2278-0181
Vol. 7 Issue 01, January-2018
In the OAuth2.0 Authentication, the user will still need to A JWT Token Consists of three parts: header, claims, and
send the username and password in the request body similar to signature. All of these three parts are base64-encoded,
basic authentication but also introduce tokens. Tokens will be combined into one String and included in the Authorization
stored and maintained in the Token store on the server side. Header.
The same token can be used to call the service any number of
times until it is expired. When the access token is expired, the Authorization:Bearer
user can use the refreshToken to get the new accesstoken. The eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0
glaring problem with the OAuth2.0 specification is that it NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRyd
constantly introduces more tokens. These tokens are essentially WV9.TJVA95OrM7E2cb30RMHrHDcEfxjoYZgeFONFh7HgQ
equivalent to passwords, and therefore, the server needs to Header
maintain the state of each token. In addition to all the new
tokens, all of the invalid token requests will increase the load The header simply declares that this is a JSON Web Token
on the token store, allocating a higher overall server load and the algorithm used to generate the signature. Below block
dedicated just to the tokens. shows the JWT header sample
{
D. JSON Web Token (JWT) Authentication "alg" : "AES256",
A JWT token is actually a full JSON Object that has been
base64 encoded and then signed with either a symmetric shared "typ" : "JWT"
key or using a public/private key pair. The JWT can contain }
such information including the subject or user ID, when the
token was issued, and when it expires. By signing with a secret, Claims
the JWT ensures that only the defined user can generate a This is the heart of the token. Claims are meant as details
unique token, which cannot be open for tampering (such as about the user which are meant to transfer between parties.
modifying the user ID or when it expires). While the JWT is Whether the user wants to authenticate on one server and
signed however, the JWTs are usually not automatically access protected resources from another server, or the API
encrypted (JWT Encryption is an optional feature). This means issues the token and then stores the token on a client-side app,
that any data which is in the token can be read by anyone who the token can be generated to facilitate a variety of different
has access to the token. circumstances.
One of the benefits of JWTs is they can be used without a Signature
backing store. All the information required to authenticate the
user is contained within the token itself. In a distributed It is possible to decode the token using base64 algorithm;
microservice world, it makes it easy to not rely on centralized however the signature would then be rendered invalid. The
authentication servers and databases. The individual signature is generated using a private key to hash the Header
microservice only needs some middleware to handle verifying and Claims. This way only the original token will match the
the token (JWT libs are openly available for everything from signature.
Express to JVM MVC Frameworks) in addition to the secret This raises an important implementation detail. Only
key needed to verify. Verifying consists of checking the applications that have a private key, i.e. server-side apps, can
signature and a few other parameters such as the claims and trust the claims of the token. It is not advised to place a private
when the token expires. JWTs are usually medium life tokens key in a browser side application.
with an expiration date that may be set anywhere from a few
weeks to significantly longer, customizable to the client’s One of the downsides with JWTs is that banning users or
[Link] that a token is correctly signed only takes adding/removing roles is more complex if the action is required
CPU Cycles and requires no IO or network access and is immediately. The JWT has a predefined expiration date which
therefore easy to scale on modern web server may be set a defined date into the future. Since the token is
hardware. stored client side, there is no way to directly invalidate the
token even if the user is marked as disabled in the database,
and must wait for the token to expire. This can influence the
architecture, especially if designing a public API that could be
starved by one power user or an e-commerce app where
fraudulent users need to be banned. There are workarounds, for
example, if all that is needed is banning compromised tokens
or users, the user can create a blacklist of tokens or user IDs;
however this may reintroduce a database back into the
authentication framework. A recommended way to blacklist is
to ensure each token has a jti claim (or a JWT Id which can be
stored in the Db). Assuming that the number of tokens the user
would like to invalidate is notably smaller than the number of
users in the application, this process should then scale fairly
easy. The user may even locally cache it in the same process as
Fig. 6. OAuth2.0+ JWT Authentication the API code, removing some dependency on a database
server.
IJERTV7IS010137 [Link] 280
(This work is licensed under a Creative Commons Attribution 4.0 International License.)
Published by : International Journal of Engineering Research & Technology (IJERT)
[Link] ISSN: 2278-0181
Vol. 7 Issue 01, January-2018
On the other hand, if the user has an enterprise app with
many roles such as admin, project owner, service account
manager and they want the token responsibility to have
immediate effect, then development can be more complicated.
For example, in the instance where an admin is modifying
someone else’s authorized roles such as his/her immediate
reports, the modified user wouldn’t even know their roles have
changed without refreshing the JWT.
Another downside is the token can grow as more fields are
added. In stateless apps, the token is sent for virtually every Fig. 7. HTTP Messages Authentication
request, and therefore can be an impact on data traffic size. For
example, the enterprise app may have many roles, which may REFERENCES
add bloat and complications for what to store in a token. In
[1] [Link]
mobile apps where smartphone owners are concerned for architecture/
client-side latency and data usage, JWTs may add too much [2] [Link]
payload to each request.
[3] I.S. Jacobs and C.P. Bean, “Fine particles, thin films and exchange
anisotropy,” in Magnetism, vol. III, G.T. Rado and H. Suhl, Eds. New
E. HTTP Signatures York: Academic, 1963, pp. 271-350.
In the JWT, only the Authorization header is base64- [4] K. Elissa, “Title of paper if known,” unpublished.
encoded and signed, so if anyone were to get the JWT token [5] R. Nicole, “Title of paper with only first word capitalized,” J. Name
and request, they can then update the HTTP Request body. To Stand. Abbrev., in press.
avoid this kind of data manipulation issues, HTTP Signatures [6] Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, “Electron spectroscopy
studies on magneto-optical media and plastic substrate interface,” IEEE
allow the client the sign the entire HTTP Message, so that Transl. J. Magn. Japan, vol. 2, pp. 740-741, August 1987 [Digests 9th
others can touch the request on the network. HTTP Signatures Annual Conf. Magnetics Japan, p. 301, 1982].
have been introduced by Amazon, Facebook and Google. Later [7] M. Young, The Technical Writer’s Handbook. Mill Valley, CA:
in 2016, a new Work in Progress specification called Signing University Science, 1989.
HTTP Messages came into practice. As per this specification, [8] A Design Methodology for Reliable Software Systems. FJCC,
the benefit of signing the HTTP message for the purposes of Dec.1972,
end-to-end message integrity is so that the client can be [9] [Link]
authenticated using the same mechanism without the need for [10] [Link]
multiple loops.
IJERTV7IS010137 [Link] 281
(This work is licensed under a Creative Commons Attribution 4.0 International License.)
View publication stats