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