Skip to main content

Centralized SSO

Context​

Microservices are used or are being adopted. There is no microservice-overarching authentication and authorization concepts for users. Each microservice handles authentication and authorization by itself.

Problem​

  • Users have to sign-in in every microservice individually.
  • Duplication of auth functionality to every microservice.
  • Inconsistencies of how auth is handled across microservices.

Solution​

Introduce a dedicated auth component that is responsible for managing authentication and authorization in a single-sign-on way (SSO). This component has two main goals:

  1. Ensure the authenticity of a user centrally
  2. Provide the security context of a user to other microservices

The concrete implementation could be

  • a dedicated microservice,
  • an infrastructure component,
  • a bought-in 3rd party service,
  • or a part of the deployment platform.

The API facade can be integrated with this auth component to ensure authenticity of the user at a central point. The defacto standard to implement SSO is via token-based authentication.

The API facade can provide the security context information and add it to the header of the forwarded requests or decode the security context information within the token.

Authorization, determining whether access to certain functionality is accessible or not depending on the user's context, can be either implemented in the API facade globally or within each microservice individually. The general guidance to put no domain logic into infrastructure suggests to handle authorization in each microservice individually since access control is grounded in the understanding of the domain. Locating authorization logic in the API facade might be considered when the microservice does not own the context information to make authorization decisions.

The auth component should also allow for security monitoring, reporting, and auditing if required.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L28:

  • Context: example project ACME Air
  • authentication service performs user authentication and manages web sessions

L34:

  • Example for microservices vs SOA vs SCS
    • original user management component partially dissolves into the SSO module for authentication

L37:

  • Context: architecture of an IoT framework
  • Security Microservice
    • user/group/role management, authentication, authorization, access control, single-sign-on and federation, identity governance and administration
    • security monitoring, reporting and auditing
    • user credentials required for accessing the REST services
    • writes on entities: access control policies of user are stored to indicate which action can be performed by the user.

L43:

  • Context: Microservice reference architecture sketch
  • Infrastructural services: authentication service

L53:

  • Context: microservice patterns for IoT
  • identity management and authentication service might leverage existing system that manage accounts (SSO or OAuth)
    • each client (user / machine client / microservices) has to present its identity
  • API gateway can provide flexible and fine-grained location for enforcing access control policies
    • makes sense if access based on context not "owned" by the microservice itself

L55:

  • Context: microservice-based middleware for digital factory
  • User Account and Authentication (UAA) service
    • authentication and authorization
    • check user credentials (human operator, CPSs or microservices) => verify identity
    • issues time-limited Oauth2 token
    • token authorizes subset of possible actions depending on their role

LM47:

  • Context: SLR with tactics to achieve quality attributes
  • Federated identity extends host-authenticated TLS
    • in-band authentication options
    • allows to use identity management system to store identity of users for auth
    • usually adopt trusted third party
      • issues tokens, eg JWT
      • implemented as separate service or SSO framework
      • examples: OpenID Connect, SAML, OAuth2, Shibboleth

Interview B:

  • Questions
    • what do I want to secure?
    • how and where to secure?
  • Do I need a security concept in every service?
    • often API gateway to do Single-Sin-On => no sign-on on every service
    • in practice: not so consequent and have multiple ways into the system, e.g. for batch jobs, inhouse applications
  • Usual approach
    • not classical login mechanism, but tokens
    • issued by security or auth provider
    • pass on token => ensure security, propagate security context
  • System secured to outside, communicate internally openly
    • Gateway as point of decryption
    • Centralization in gateway => prevent brute-force attacks
      • API keys
      • limit requests per second/minute
      • enforce SLAs

Interview C:

  • need to think first where to do security
    • facade?
    • particular services?
    • central token service issuing tokens valid for a time span?
      • used to access backend services