MATIH Platform is in active MVP development. Documentation reflects current implementation status.
6. Identity & Access Management
Overview
Part II: Control Plane Services

Chapter 6: Identity and Access Management

The IAM service is the security foundation of the MATIH Enterprise Platform. It governs authentication, authorization, multi-factor authentication, API key management, session tracking, OAuth2 flows, and user impersonation across the entire platform.

Learning Objectives

  • Understand the IAM service architecture, domain model, and integration points
  • Implement authentication flows including login, registration, MFA, and OAuth2
  • Configure RBAC with roles, permissions, and OPA policy evaluation
  • Manage API keys with scoped permissions, rotation, and IP whitelisting
  • Administer sessions, devices, and user impersonation for support workflows

Details

Estimated Read Time: 90 minutes
Prerequisites:
  • JWT token structure and validation
  • OAuth2 grant types
  • Spring Security filter chain
  • Multi-factor authentication fundamentals
Related Chapters:
  • Ch. 7: Tenant Lifecycle
  • Ch. 8: Platform Services
Production - Since v1.0 - 16 controllers, 23 services, 25 repositories

The Identity and Access Management (IAM) service is the security foundation of the MATIH Enterprise Platform. Every API request across both the control plane and data plane passes through IAM-issued JWT tokens for authentication and authorization. The service manages the complete identity lifecycle from user registration through session termination.


What You Will Learn

By the end of this chapter, you will understand:

  • The IAM architecture including the service boundary, domain model, integration points, and the relationship between the IAM service and the shared commons-java JWT library
  • Authentication flows covering credential-based login, OAuth2 authorization code and client credentials grants, SSO via Keycloak, and the adaptive risk assessment engine
  • Multi-factor authentication enrollment, verification, and recovery for TOTP, SMS, and email channels with backup code management and per-tenant MFA policies
  • User management including CRUD operations, role assignment, account lockout, password policies, and self-service access requests
  • RBAC model with hierarchical roles, fine-grained permissions using resource:action patterns, permission caching, and OPA integration
  • API key management with scoped permissions, automatic and manual rotation, IP whitelisting, and rate limiting
  • Session management covering active session tracking, device fingerprinting, trusted device management, and administrative session revocation
  • OAuth2 implementation including client registration, authorization code flow with PKCE, token issuance, introspection, and revocation
  • User impersonation for admin troubleshooting with full audit trail and compliance controls
  • The complete API surface with endpoint specifications, request and response schemas, error codes, and rate limiting behavior

Chapter Structure

SectionDescriptionAudience
IAM ArchitectureService internals, domain model, security layers, and integration topologyArchitects, backend engineers
AuthenticationLogin, registration, email verification, password reset, tokens, and logoutBackend engineers, security engineers
Multi-Factor AuthenticationTOTP, SMS, email MFA enrollment, verification, policies, and recoveryBackend engineers, security engineers
User ManagementUser CRUD, role assignment, enable/disable, lockout, password policies, access requestsBackend engineers, platform operators
Roles and PermissionsRBAC model, role management, permission model, custom roles, caching, OPA integrationArchitects, security engineers
API KeysKey creation, rotation, scopes, rate limits, IP whitelistingBackend engineers, API consumers
Session ManagementSession lifecycle, device management, trusted devicesBackend engineers, security engineers
OAuth2Client management, authorization code flow, token managementBackend engineers, integration engineers
ImpersonationStarting/ending sessions, audit trail, compliancePlatform operators, security engineers
API ReferenceComplete endpoint catalog with request/response schemasAll developers

Service at a Glance

PropertyValue
Service Nameiam-service
TechnologySpring Boot 3.2, Java 21
Port8081
DatabasePostgreSQL (control plane database)
CacheRedis (session and permission caching)
JWT LibraryJJWT 0.12.3 with HS256 signing
MFA ProvidersTOTP (RFC 6238), SMS (Twilio), Email
SSO IntegrationKeycloak (OIDC/SAML), OAuth2 providers
Policy EngineOpen Policy Agent (OPA)
API DocumentationOpenAPI 3.0 via SpringDoc
Controllers16 REST controllers
Services23 business services
Repositories25 JPA repositories

Component Overview

REST API Layer
AuthControllerUserControllerRoleControllerMfaControllerMfaPolicyControllerMfaRecoveryControllerApiKeyControllerSessionControllerDeviceControllerOAuth2AuthorizationControllerOAuth2ClientControllerOAuth2TokenControllerImpersonationControllerAccessRequestControllerPermissionCacheControllerHealthController
Business Logic Layer
AuthenticationServiceUserServiceRoleServiceMfaServiceSmsMfaServiceEmailMfaServiceMfaPolicyServiceMfaRecoveryServiceApiKeyServiceApiKeyRotationServiceSessionServiceDeviceFingerprintServiceOAuth2ServiceImpersonationServiceAccessRequestServicePasswordServicePasswordPolicyServicePasswordExpirationServiceAccountLockoutServicePermissionCacheServiceOpaAuthorizationServiceAuditLogServiceAccessReviewService
Security Layer
JwtTokenProviderJwtAuthenticationFilterSecurityConfigSecurityPropertiesPasswordEncoder
Data Access Layer
UserRepositoryRoleRepositoryPermissionRepositoryApiKeyRepositoryRefreshTokenRepositoryUserSessionRepositoryUserDeviceRepositoryUserMfaCredentialRepositoryUserBackupCodeRepositoryMfaChallengeRepositoryMfaPolicyRepositoryOAuth2ClientRepositoryOAuth2AuthorizationCodeRepositoryOAuth2AccessTokenRepositoryImpersonationSessionRepositoryAccessRequestRepositoryEmailVerificationTokenRepositoryLoginHistoryRepositoryPasswordHistoryRepositoryPasswordPolicyRepository

Key Design Principles

Tenant isolation from day one. Every JWT token carries a tenant_id claim. Every database query is scoped by tenant. There is no code path where a user in one tenant can access resources belonging to another.

Defense in depth. Authentication is not a single gate but a series of layered checks: credential validation, MFA challenge, device fingerprinting, geo-location anomaly detection, and rate limiting. Each layer operates independently and can block a request.

Zero-trust security posture. Sessions are continuously evaluated for risk. A session that was valid at login can be elevated to require re-authentication if the risk profile changes (new IP, new device, unusual access pattern).

Standards compliance. The OAuth2 implementation follows RFC 6749 and RFC 7636 (PKCE). JWT tokens follow RFC 7519. TOTP follows RFC 6238. The permission model follows the resource:action pattern for fine-grained access control.


How This Chapter Connects

The IAM service is consumed by every other service in the platform. The API Gateway validates JWT tokens on every inbound request and extracts tenant context. The Tenant Service calls back to IAM during provisioning to create the initial admin user and configure tenant-specific authentication policies. The data plane services rely on the commons-java JwtTokenProvider to validate tokens forwarded through the gateway.

Understanding the token claims structure documented in Authentication is a prerequisite for working with any authenticated API endpoint across the platform.


Prerequisites

To get the most from this chapter, you should be familiar with:

  • JWT token structure and validation concepts
  • OAuth2 grant types (authorization code, client credentials, refresh token)
  • Multi-factor authentication fundamentals
  • Spring Security filter chain architecture
  • RESTful API design patterns

Begin with the IAM Architecture to understand the service internals before diving into individual authentication flows.