Keep the identity source of truth
Choose the existing identity provider as the source of user lifecycle and group membership. Establish SAML or OIDC federation with the appropriate signing keys, audience, issuer, redirect destinations, and session policy. Use provisioning for lifecycle synchronization; authentication alone does not keep departed users or obsolete groups synchronized.
| Integration | Who owns it | What to validate |
|---|---|---|
| Identity federation | Identity team. | Issuer, audience, signing rotation, MFA, and logout behavior. |
| Provisioning | Identity governance team. | Create, update, disable, and group removal. |
| Device signals | Endpoint team. | Enrollment identity, freshness, and unavailable-state behavior. |
| Private origin | Application team. | DNS, ports, dependencies, and application authentication. |
| Evidence export | SOC team. | Tenant, session, policy version, timestamps, and retention. |
Place the connector near the application
Deploy a redundant connector pair into an application-adjacent network with explicit outbound access to the service endpoints defined in your deployment manifest. Allow connector-to-origin traffic only for approved destinations and ports. Preserve application TLS and application authentication; reaching an origin through a connector does not replace its own security controls.
- 01Register
Associate connector identity with the tenant.
- 02Reach
Validate origin DNS and approved ports.
- 03Publish
Map a named resource to its origin route.
- 04Authorize
Bind the resource to a pilot identity cohort.
# Run from an authorized connector-adjacent test host.
nslookup erp.internal.example
curl --head --connect-timeout 5 \
--cacert enterprise-roots.pem \
https://erp.internal.example/The HTTP response may require application authentication. Interpret transport reachability separately from application authorization. Use your approved internal CA bundle; do not bypass certificate verification to make a pilot appear healthy.
Pilot with observable boundaries
- Choose one application with a named owner and representative users.
- Capture DNS, authentication redirects, and background dependencies before defining the access scope.
- Test managed access, unmanaged access, expired posture, and removed group membership.
- Compare application success and support tickets against the existing route.
- Keep the previous route available for the agreed rollback window, with an owner and explicit retirement date.
A useful pilot finishes with dependency evidence and an accepted access policy, not merely a connected client. Expand by application group so each change retains a clear owner and a bounded failure domain.