Federation & Access Delivery
Single sign-on, upstream federation, application access, and external identity handoffs.
Audience: Identity and application access teamsFocus: Sign-in path and access deliveryStatus: Public manual
What this area covers
This part of Portal governs how people sign in, how identity is federated, and how application access is delivered without turning every access change into a separate coordination exercise.
Operational areas in scope
| Area | What operators need from it | Why it matters |
|---|---|---|
| Upstream federation | A clear sign-in path from existing identity sources into Portal | Federation complexity becomes an operational liability if the path is not explicit |
| Application access | Consistent assignment and access delivery into Cadres and external applications | Application access should follow policy and group design rather than ticket-by-ticket changes |
| Provisioning | Lifecycle-aware provisioning that supports real join, move, and leave events | Access drift grows quickly when provisioning and access delivery separate |
| Guest and external access | Controlled collaboration for non-workforce identities | Collaboration is often where policy breaks first if it is treated as an exception path |
| Migration and cutover | A truthful way to inventory, assess, and transition away from an incumbent | Teams need to know what the migration boundary actually is before they commit to it |
| Downstream notifications | A way to keep dependent systems informed when access state changes | Identity-driven products are easier to operate when downstream changes are visible quickly |
What operators are actually managing
- Define which identity sources are authoritative for the business.
- Establish the sign-in path users will actually follow in day-to-day work.
- Deliver application access in a way that stays consistent with policy as more teams and products are added.
- Decide which applications should be directly governed in Portal and which should stay bounded outside it.
- Plan migrations and cutovers in a way that keeps identity truth, application access, and operator visibility aligned.
What this public manual area includes
- Federation operations for workforce and application access.
- Provisioning and lifecycle-aware access delivery.
- Guest collaboration and external identity handling.
- Migration support and downstream change notification.
What to review before rollout
- Whether the federation model is simple enough to support supportable operations.
- Whether application access follows group and role design rather than ticket-by-ticket exceptions.
- Whether external or partner access can be governed without weakening internal identity policy.
- Whether migration expectations are bounded enough that teams can understand what Portal will and will not absorb.
Ongoing operating expectations
- Access changes should follow role and membership policy rather than ad hoc intervention.
- Sign-in exceptions should be diagnosable without rebuilding identity context by hand.
- Expansion into additional Cadres products should reuse the same identity model instead of creating parallel access logic.
Signals the model is holding up
- Application access changes remain understandable after team growth, not just during initial rollout.
- External collaboration stays controlled without forcing a second identity system into place.
- Migration work produces a clearer operating model rather than a temporary compatibility maze.