Propagate Security Context via Headers

Context

Microservices are used or are being adopted. A centralized SSO component was introduced.

Problem

• The security context is not present in the microservices.
  • The individual microservices cannot differentiate different access privileges for authorization.

Solution

When verifying the authenticity of a user, e.g. in the API facade, encode the security context into the headers of each forwarded request.

This approach poses an alternative to using the token to propagate the security context, especially if no token-based authentication between microservices is used.

However, since the security context is propagated with a proprietary mechanism instead of using a standard, problems might arise when reusing the microservices in other contexts that don't adopt this proprietary solution.

Microservices might still need additional information for authorization. We suggest to store this required information within the microservice itself so that no further calls to other microservices are required to authorize the user. This can be implemented by design or data replication mechanisms.

Maturity

More data required (only 1 source).

Sources of Evidence

Interview B:

• BEST PRACTICE: use tokens
  • issued by an authentication provider => JWT token
  • token includes information
    • am I allowed to get in? yes or no
    • who am I? => user information: claims
  • claims can be used to propagate information about user
    • instead of specifying in API every time which user, email, address,....
    • is a BEST PRACTICE to use claims!
  • token has shorter life time than session
    • refresh token to generate token in background
    • transparent for user
• BEST PRACTICE: propagate security context via tokens - standard information - which role! - trade-off how much information - standardized claims - additional claims, e.g. in micro-profile (Java enterprise) - proprietary claims (e.g. address) => only if working within own service world