Skip to content

ConnectSoft Identity Platform Development Alignment

The canonical identity platform pages describe target-state architecture. This page tracks how future development should adopt that target state without weakening the normative design.

P0: Mock-First Integrated Vertical Slice

Goal: prove the end-to-end path with stable contracts.

Required:

  • Shell login through Authorization Server.
  • Identity local users and claims.
  • API Gateway token validation and one route policy.
  • One backend protected endpoint.
  • Mock social, enterprise, and LDAP providers.
  • MFA status projected into token claims.

Acceptance criteria:

  • User can register, log in, complete MFA, receive platform token, call backend through Gateway.
  • Mock external user can JIT provision and call backend through Gateway.
  • Gateway rejects ID tokens and invalid/missing access tokens.

P1: Identity Completeness

Goal: complete user identity lifecycle.

Required:

  • profile management;
  • password reset/change;
  • email/phone confirmation;
  • MFA enrollment/recovery/admin reset;
  • roles, claims, tenant memberships;
  • external account links.

Acceptance criteria:

  • Identity Self-Service and Identity Admin flows match canonical contracts.
  • Authorization Server can retrieve normalized claims and MFA state from Identity.

P2: Federation

Goal: add real provider integrations after mock contracts are stable.

Required:

  • Google and Facebook adapters;
  • Keycloak/Entra OIDC;
  • SAML/ADFS adapter where required;
  • LDAP bind/sync or federation bridge;
  • group and tenant mapping.

Acceptance criteria:

  • External identities map to internal users.
  • External tokens are not accepted by backend APIs.
  • Upstream MFA is trusted only by explicit policy.

P3: Gateway Hardening

Goal: make Gateway the reliable API edge.

Required:

  • route policy catalog;
  • anonymous allowlist;
  • MFA-aware policies;
  • tenant header overwrite/rejection;
  • correlation propagation;
  • rate limiting on auth-sensitive endpoints;
  • optional introspection/reference-token support.

Acceptance criteria:

  • Gateway policy behavior is testable and documented.
  • Sensitive routes require step-up MFA.
  • Direct tenant header spoofing fails.

P4: Backend Template Standardization

Goal: make every new backend service identity-platform-ready.

Required:

  • current user abstraction;
  • tenant context abstraction;
  • transport-specific auth guidance;
  • domain authorization examples;
  • audit/logging guidance;
  • integration tests through Gateway.

Acceptance criteria:

  • New microservice templates document and test resource-server behavior.
  • Backends do not rely on frontend or external provider authorization.

P5: Production Hardening

Goal: production-grade security and operations.

Required:

  • signing key rotation;
  • refresh token rotation/reuse detection;
  • revocation strategy;
  • audit dashboards;
  • anomaly detection;
  • secret management;
  • disaster recovery;
  • provider outage handling.

Acceptance criteria:

  • Operational runbooks exist for key rotation, provider outage, credential compromise, and revocation incidents.
  • Security telemetry supports incident review.

Known Alignment Rules

  • Implementation gaps belong here or in local repo implementation notes.
  • Blueprint, contracts, federation, MFA, and security model pages remain target-state normative docs.
  • Mock providers must follow the same contracts as real providers.