Building production-ready services

Three important qualities of the production-ready applications

• Security

• Configurability

• Observability

Security

Following are the basic aspects of security

• Authentication: Verify the identity of human or application

• Authorization: Verify if the user/app is allowed to perform the requested operation. Implemented via Role-based security or ACLs.

• Auditing: Track the operation performed by the user/app (principal).

• Secure Interprocess communication: Services communicate over TLS

Session One key component of security architecture is the session, which stores the principal’s (user or app) id and roles. A session is identified by a session token. Session-Id is generally an opaque token (cryptographically strong number).

Another key component of the security framework is security context, which stores the information about the user invoked the current request.

Security implementation in microservice Following are the options to implement authentication in microservice

• In individual services

• In API gateway

Problem with implementing security at an individual service level are

• Unauthenticated service will enter the internal system

• Each service has to manage the security component

Implementing security at API gateway is a better approach because it provides centralized API security.

Access token pattern The modern application uses access tokens (OAuth 2.0) as an authentication mechanism.

API gateway handles security as follow using the access token

Requesting access token

Pass access token to access the resource

Authorization Authorization is the identification of what permission a user has to perform.

Types of authorization

• Role-based

• ACLs

There are two options for the authorization token

Opaque token (generally UUID) It reduces the performance and availability of the application and increases the latency because the service which receives the token has to make a sync RPC API call to the user service (identity service) to validate the token and get the user information.

JSON Web Token (JWT Token)

• JWT is a standard way of representing the claims, such as identity and roles.

• It is signed with a secret that’s only known to the creator of the JWT, such as API gateway and the token receiver services.

Problem with JWT token

• JWT token is self-contained. Hence, no way to revoke an individual token in case it falls into the hands of a malicious third party.

Solution

• Keep short-lived JWT token

Problem with short-lived JWT token

• The application keeps on generating the JWT token after a short time, increase the load on the auth server.

OAuth 2.0 in microservice Fortunately, you don’t need to implement any kind of security infrastructure. You can use off-the-shelf solutions or frameworks that implement OAuth 2.0

OAuth 2.0 is an authorization protocol that was implemented to enable a user of a public cloud service, such as Google, to grant t third party application access without knowing the password.

Key concepts of the authorization server

• Authorization server: Provides API for authentication user, obtaining access token, refreshing access token.

• Access token: Token to grant access to a resource server.

• Refresh token: Long-lived yet revocable token that clients use to obtain the access token.

• Resource server: A service that uses the access token to authorize access. In microservice, architecture services are resource server.

• Client: That wants to access the resource server.

Configurability

A service is dependent on many external components. Eg. Database, Elastic search, Kafka. The connection URL and credentials of these components are stored in the configuration. These configurations are different for each environment. It is impractical to build a different service for each environment. Hence we need configurable services.

One approach to handle this is to add configuration for each environment in the source code. Eg. spring framework profile mechanism. And based on the environment name use the desired configuration. But this approach adds security vulnerability and limits where service can be deployed. Also, secure information should be stored in the vault.

Externalized configuration Externalized configuration mechanism provides the configuration property values to a service at the runtime.

Two main approaches:

• Push model: Deployment infra passes configuration to the service using env variables or configuration file.

• Pull model: Service instance reads the configuration file from the configuration server

You can build a configuration server using the Spring cloud config project.

Observability

For a production application, you may want to know-how application is performing. (Monitoring)

• Requests per second

• Resource utilization

• Errors

Once any problem occurs in the system, you might want to get alerted.

Also, should be easily able to troubleshoot in case of any issue.

Following are the design patterns to design observable service

• Health Check APIs: Expose endpoint to check the health of the service

• Log aggregation: Log service activity and writes the log to a centralized place.

• Distributed tracing: Add a request Id to each external request and trace requests as they flow in the system.

• Exception tracking: Send exceptions to the exception tracing service, which deduplicate the exception, alert the developers and track the resolution of each exception

• Application metrics: The service maintains the metrics and exposes them to the metrics server.

• Audit logging: Log user actions.

Source: medium

The Tech Platform

www.thetechplatform.com