Cadres Portal

Enterprise-grade identity and IGA without legacy sprawl.

Portal is the Cadres identity layer for workforce access, federation, provisioning, identity profiles, governed collaboration, access governance, JML lifecycle automation, and migration. Each tenant membership carries a full identity profile with 28 employment fields, extensible custom attributes, and per-attribute provenance tracking. The access graph shows every access edge with provenance and trust classification. Nine downstream connector plugins covering major workforce systems. Designed for teams that want enterprise-grade identity administration without scattering policy, approvals, and audit history across separate tools.

Federation SCIM Identity profiles Access graph Guest access IGA JML Migration tooling

Portal Scope

Built for the identity work teams actually own.

Auth with real assurance controls

Passkeys are a first-factor path, not just a second factor. Password fallback, MFA via TOTP or passkey, and upstream SAML or OIDC federation are all tenant-configurable. Auth policy ships with a preview-before-save step that surfaces readiness blockers, fallback paths that would stop working, and assurance gaps before anything takes effect. Emergency break-glass identities are dedicated non-personal accounts — they require a mandatory reason, log every use, and share the same lockout semantics as normal sign-in. Mobile device trust provides hardware-bound device credentials for high-assurance governance workflows.

Provisioning and identity profiles

SCIM 2.0 provisioning accepts users and groups from Entra ID, Okta, or OneLogin with enterprise extension support — employee number, department, division, cost center, and job title all write to the tenant identity profile. Each membership carries an identity profile with 28 built-in employment fields, multi-valued typed email addresses, custom attributes with per-field type validation and mutability policies, and per-attribute provenance records across SCIM, HR connector, directory import, federation, and manual sources. When sources disagree — or when a manager reference fails to resolve — the resolution issues queue surfaces the conflict for operator review without silently overwriting the existing value.

Governance that executes downstream

IGA runs request → approval → grant → execution against Portal-native targets (roles, groups, app assignments) directly. For downstream systems, nine connector plugins cover Microsoft 365, Google Workspace, ServiceNow, Salesforce, GitHub Enterprise, Atlassian Cloud, Slack Enterprise, AWS IAM Identity Center, and Zoho Mail. Every execution path creates an immutable provisioning plan before dispatch — callback completion, partial failure, and retry append evidence without changing the plan. JML templates (joiner, mover, leaver) trigger from manual kickoff, imported HR events, or scheduled effective-date. Access reviews enforce separation of duties: a reviewer cannot certify their own access. The access graph shows every access edge — direct roles, group-derived access, IGA grants, guest access, support access — with provenance and trust classification, across person-centric, target-centric, system-centric, and bundle-centric views.

Migration without overclaiming

Migration tooling ships two modes: first_run_adoption (clean cutover from Okta or Entra) and merge_into_existing (overlay into a running Portal estate). Inventory collection snapshots applications, identity providers, routing rules, policies, groups, and assignments from the source. Compatibility assessment classifies each item: native_import, import_with_approximation, visibility_only, manual_rebuild_required, or blocked — with bounded OCM impact rows for unavoidable user-facing changes requiring operator acknowledgement. Cutover plans require a preview token and apply only what the classifier can prove importable. Okta TOTP factors can be transferred rather than forcing re-enrollment when a merge decision confirms the transfer. Post-cutover evidence persists rollback notes, communications completion, and a handoff checklist against the plan record.

Why Teams Start Here

Portal answers the executive question and the operator question at the same time.

01

Who has access and why?

The access graph shows every access edge — direct roles, group-derived access, IGA grants, guest access, support access — with provenance and trust classification. Person-centric, target-centric, system-centric, and bundle-centric views give operators and auditors a consistent answer without cross-referencing four different tools.

02

How does someone get access when they need it?

The request catalog surfaces access bundles scoped to what the user can actually request. Approvals run through durable sequential stages — each stage can have a different policy and quorum. Granted access materializes into Portal-native roles and groups directly, or executes against downstream systems through nine connector plugins. JML templates handle joiners, movers, and leavers from HR events, manual kickoff, or scheduled effective-date.

03

How do we move off the incumbent?

Migration tooling takes an inventory snapshot from Okta or Entra, runs a compatibility assessment that classifies every item into one of five categories, and builds a cutover plan limited to what the classifier can prove importable. Okta TOTP factors can be transferred rather than forcing re-enrollment. Post-cutover evidence captures rollback notes, communications completion, and a handoff checklist against the plan record — so there is an auditable record of how the migration closed.

Evaluation

Evaluate Portal when identity and IGA need to be the same system, not two separate purchases.

Portal is included as the identity layer for the other Cadres products. Broader workforce IdP or IGA rollout is where Portal becomes its own dedicated evaluation — particularly when identity profiles, access governance, and downstream execution need to stay aligned in a single platform rather than scattered across separate tools.