Client Credentials Management service (CCM) is intended for authentication of clients.
- Client authentication by username/password combination.
CCM provides REST APIs to manage client credentials and their states. CCM maintains a credentials state machine summarized in the following diagram.
Credentials can be in one of the following states:
- Inactive is the initial state for newly provisioned credentials that has not been used to authenticate a client.
- Active is the state credentials automatically move to after they were first used for client authentication. Credentials can be suspended or revoked from the active state.
- Suspended state is for temporarily disabled credentials. CCM service will reject authentication requests with suspended credentials. Suspended credentials can be re-activated.
- Revoked state is the terminal state for credentials that are no longer valid.
CCM persists all credentials-related data to PostgreSQL.
CCM never stores passwords. Irreversible salted hash is stored for credentials verification instead. CCM uses Provos and Mazières’s bcrypt adaptive hashing algorithm for this purpose.
CCM supports a number of interfaces to perform its functional role. The key supported interfaces are summarized in the following diagram.
CCM provides a REST-based interface for:
- provisioning new credentials
- transitioning credentials state
- retrieving credentials information
Client authentication protocol
CCM exposes a NATS-based protocol for client authentication using basic credentials (username and password). The protocol design is available from 22/CAP.
Kaa Tenant Manager integration
CCM supports multi-tenancy with each tenant using a separate OAuth 2.0 issuer for authentication, authorization, and resource management. The list of the existing tenants is managed by [the Kaa Tenant Manager][Tenant Manager], which provides REST API for retrieving tenant security configs.
See the security configuration for more details on how to enable multi-tenancy in CCM.
CCM exposes an HTTP-based management interface with the following endpoints:
GET /healthreturns 200 OK if the service is up and running properly, and 500 Internal Server Error otherwise. In case of errors, the response payload contains their human-redable descriptions. This endpoint can be used by Kubernetes for liveness and readiness probing.
GET /metricsprovides service metrics in Prometheus text-based format.