Skip to content

MCT Authentication Requirements

1) Overall Authentication Model

  • MCT services use CI (Cisco Identity) as the unified identity and authorization provider.
  • API calls are authenticated with OAuth 2.0 tokens via the Authorization header.
  • Authentication is enforced mainly on HTTP-facing services; async consumer services typically do not use HTTP auth.
  • Support STIG compliance with IA-09-00.
  • MCT API

Core dimensions

  • Authentication: Who is calling (token validity and identity).
  • Authorization: What caller can do (scope/privilege checks).
  • Audit: Who did what and when (logging/tracing).

2) Service-by-Service Requirements

Service Auth Status Typical Checks
mct-central-api Required Token + scope (mct_api) + privilege (+ optional org check)
mct-status-api Required Token + scope (identity_organization) + optional org check
mct-resource-management Required Similar to central-api defaults
mct-cloud-agent Caller-side required Gets/refreshes CI token, injects Authorization in outbound requests
mct-job-engine Mixed Outbound bearer token is implemented; inbound unified CI annotation enforcement not observed in repo
mct-status-consumer Not HTTP-auth driven N/A

3) Quick Validation Flow (Typical)

  1. Request enters API endpoint.
  2. @CIOauth (or equivalent aspect) determines whether auth is enabled.
  3. Check Authorization header.
  4. Validate token (existence, expiry, legitimacy).
  5. Validate required scope(s).
  6. Validate privilege (if applicable).
  7. Validate org ownership/match (if orgCheck=true).
  8. Store request user context in thread-local (if implemented).
  9. Execute business logic.
  10. Clear thread-local and return response.

4) Common Failure Outcomes

  • Missing token -> 401 Unauthorized
  • Invalid/expired token -> 403 Forbidden (token invalid/expired)
  • Scope mismatch -> 403 Forbidden
  • Insufficient privilege -> 403 Forbidden
  • Org mismatch (when org check enabled) -> 403 Forbidden