Skip to content
Product · Identity Sync

Your IdP is the source of truth — PortEden's policies follow it in seconds.

PortEden pulls users, groups, and attributes from Microsoft Entra ID, Okta, Google Workspace, and JumpCloud over SCIM 2.0 and OIDC, then binds them to AI access policy. When your IdP says someone is gone or their role changed, every AI request from Claude, ChatGPT, Copilot, Gemini, or any MCP server reflects that change in seconds — not at the next audit cycle.

See pricing

Free tier · No credit card · SCIM 2.0 + OIDC + SAML 2.0

Mapped to the frameworks your auditor reads
SOC 2 CC6.2 / CC6.3HIPAA §164.308NIST 800-53 IA-2 / IA-4ISO 27001 A.5.16 / A.5.18GDPR Art. 32CCPA / CPRACMMC 2.0
The problem

Your IdP is current. Your AI access policy isn't.

Identity changes in Entra ID, Okta, or Google Workspace dozens of times a day — joins, departures, role changes, group edits. If the AI access layer doesn't hear about every one of them in real time, the gap between "what your IdP says" and "what AI clients can do" becomes the largest unmanaged risk in your stack.

Stale identity = stale policy = unauthorized AI access

When someone leaves and your IdP deprovisions them, the AI client they were using yesterday still has their token cached. The model keeps answering questions on data they no longer have any right to.

Two systems for identity, two answers

Your IdP says someone moved from Sales to Legal. PortEden still has them on Sales policies for hours or days. The two systems disagree and the audit log can't tell you which one was authoritative when the request fired.

Group changes don't propagate

Security adds "High Risk Project" as a group in Okta. The AI policy that should restrict everyone in it keeps letting them through, because the policy engine never heard about the new group. Auditors find out at evidence collection time.

The identity layer in action

Your IdP feeds it. Every PortEden control consumes it.

Identity flows in from your IdPs over SCIM 2.0, OIDC, and SAML 2.0. PortEden's identity layer normalizes it once, then every downstream control — access, policy, audit, redaction — reads from the same source.

Identity providers
Microsoft Entra ID
Okta
Google Workspace
JumpCloud
Center
PortEden Identity Layer
UsersGroupsAttributes
Downstream controls
Access Control
Policy Groups
Audit Trail
Redaction
Real-time SCIM events plus periodic reconciliation backstop.
One identity source feeds every PortEden control uniformly.
Coverage

Identity sync coverage, end to end.

Six dimensions of coverage — providers, protocols, attributes, group types, lifecycle events, and mappings. The same coverage applies uniformly across every integration and every AI client downstream.

Identity providers

Which IdPs are supported?

First-class SCIM 2.0 + OIDC + SAML 2.0 connectors for the directories enterprises actually run.

  • Microsoft Entra ID (Azure AD)
  • Okta
  • Google Workspace
  • JumpCloud
  • Ping Identity
  • OneLogin
  • Any SCIM 2.0 + OIDC compliant IdP

Protocols

Which standards does PortEden speak?

SCIM 2.0 for provisioning. OIDC for auth. SAML 2.0 for SSO. OAuth 2.1 for delegated authorization.

  • SCIM 2.0 for user and group provisioning
  • OIDC (OpenID Connect) for authentication
  • SAML 2.0 for SSO and federation
  • OAuth 2.1 for delegated authorization
  • JWT-bound session tokens
  • mTLS for SCIM endpoint hardening

User attributes synced

What identity data flows through?

Standard SCIM attributes plus IdP extensions and OIDC custom claims surfaced as PBAC variables.

  • Email and display name
  • Department and cost center
  • Manager and reporting chain
  • Employment status (active, suspended, terminated)
  • Title, role, clearance level
  • Custom attributes via SCIM extensions
  • OIDC custom claims for partner-org context

Group types

Which group structures map cleanly?

Whatever your IdP already maintains — security, distribution, dynamic, nested — maps without translation.

  • Security groups
  • Distribution lists
  • Dynamic groups (attribute-computed)
  • Nested groups with full expansion
  • Role-mapped groups
  • Cross-tenant federated groups

Lifecycle events

Which IdP events drive policy changes?

Every SCIM lifecycle event triggers policy recomputation in real time, with reconciliation as a backstop.

  • Create — new user provisioned
  • Update — attribute or profile change
  • Deactivate — soft removal with grace period
  • Reactivate — restore prior policy bindings
  • Delete — hard removal with audit retention
  • Group-membership change (add, remove, move)
  • Periodic reconciliation deltas

Mapping & transforms

How does identity become policy?

Group → role bundle. Attribute → policy variable. Claim filter → PBAC predicate. Multi-IdP merge for partners.

  • Group → role bundle mapping
  • Attribute → PBAC policy variable
  • Custom OIDC claim filters
  • Multi-IdP merge rules for partner orgs
  • Conditional bindings (env, tenant, time)
  • Versioned, change-controlled mapping edits
How it works

Connect. Sync. Bind. Enforce.

1. Connect

One-time SCIM connector and OIDC client setup in your IdP admin console. Certificate exchange. PortEden registers as a downstream app the same way any SaaS does — no agent, no elevated directory privileges.

2. Sync

Real-time push from your IdP for create, update, and deactivate events. A periodic reconciliation backstop pulls the full directory on a schedule so drift can't accumulate silently between events.

3. Bind

Map IdP groups to PortEden role bundles and policy groups. Map IdP attributes — department, clearance, manager, custom claims — to PBAC policy variables. Mappings are versioned and audited like any other policy edit.

4. Enforce

Policy decisions use the latest identity state at request time, not yesterday's snapshot. A deprovisioning that just happened is honored on the very next AI request. Every decision records the identity revision it ran against.

See it in action

A group change in Entra ID, enforced in three seconds.

Here's a real lifecycle event. Sam moves from Sales to Legal in your IdP at 14:02:17. By 14:02:20, the next AI request from Sam evaluates under Legal policies. Every step is recorded.

Event from Microsoft Entra ID
14:02:17
Usersam@yourcompany.com
Event typeGroup membership change
Removed fromSales
Added toLegal
14:02:18
SCIM PATCH received

Entra ID pushes the group-membership change to PortEden's SCIM endpoint. Payload signed, source verified, queued for evaluation.

14:02:19
Role mapping recomputed

Sales role bundle removed. Legal role bundle added. PBAC variables (department, ethical-wall side) refreshed to the new values.

14:02:20
Next request evaluated under Legal policies

Sam's next AI request runs under the new bundle. Sales-only data sources return denied or filtered. Audit trail records both the IdP event and the policy recomputation.

Total propagation
3 seconds from IdP event to enforced policy

Every SCIM event is recorded in the audit trail with the policy version that was live before and after. An auditor asking "what could Sam see at 14:02:19?" can replay the decision against the exact policy state.

With and without identity sync

Same IdP event, two very different outcomes.

Offboarding an employee on their last day
Without
IdP deprovisions the user. The AI client they were using still has a cached token. They keep getting answers on company data for hours until the next manual sync — or until someone notices.
With
SCIM DEACTIVATE arrives in seconds. The next AI request is denied at the policy layer. Cached tokens invalidated. Audit trail records the deprovisioning and every subsequent denied request.
Promoting someone from Sales to Legal
Without
Their old Sales group bundle still applies in the AI policy engine. They can still ask Claude about pipeline data they shouldn't see anymore. The promotion in your IdP didn't reach the AI layer.
With
SCIM PATCH arrives. Sales bundle removed. Legal bundle applied. The very next AI request runs under the new role. The audit trail captures both the IdP event and the policy recomputation.
Contractor hits their planned end date
Without
Nobody remembers to revoke AI access. The contractor's session keeps working past the contract end. You discover it during the quarterly access review three months later.
With
IdP-defined expiry triggers a SCIM DEACTIVATE on the dot. PortEden honors it instantly. Auto-revoke is configurable with grace periods, escalation, and a notification trail.
Adding a high-risk project group in Okta
Without
Security adds the new group. The AI policy engine doesn't know it exists yet, so the policy that should restrict members keeps letting them through. The mismatch surfaces during audit, not during the breach.
With
Group creation event flows through SCIM. Mapping rules apply automatically (or block until a human reviews, depending on policy). Members of the group hit the right policy bundle on their next request.
Partner-org user joins via federation
Without
Their identity lives in the partner's IdP, not yours. Your AI policy engine has no record of them. They get whatever default access the OAuth scope grants — which is usually too much.
With
Federation context (home tenant, partner identity, group claims) is read at sign-in. Multi-IdP merge rules bind the right policy bundle. Partner users are first-class identities with explicit scopes.
Periodic identity reconciliation against the IdP
Without
There is none. The two systems drift apart between manual exports. By month-end, nobody is sure which version of the identity tree is authoritative.
With
Scheduled full reconciliation pulls the IdP directory, computes a delta against PortEden's state, applies missed events, and produces an auditor-readable drift report. Drift can't accumulate silently.
Auditor-readable

Citations, not vague reassurances.

Identity sync maps directly to the access-management clauses your auditor checks. Evidence is exportable from the audit trail in formats your auditor accepts.

Framework
Citation
PortEden control
SOC 2
CC6.2 — Registration and authorization
Prior to issuing system credentials and granting access, registers and authorizes new internal and external users. SCIM-driven provisioning records every credential issuance against an explicit IdP authorization event.
SOC 2
CC6.3 — Removal of access
Authorizes, modifies, or removes access based on roles and changes. Real-time SCIM DEACTIVATE plus periodic reconciliation backstop produces per-user, per-integration removal records within seconds.
HIPAA
§164.308(a)(3)(ii)(C) Termination procedures
Procedures for terminating access to ePHI when employment ends or workforce-clearance changes. SCIM deprovisioning propagates to AI-mediated PHI access in real time, with audit retention.
HIPAA
§164.308(a)(4)(ii)(B) Access authorization
Policies and procedures for granting access to ePHI through workstations, transactions, programs, or processes. Group-bound role bundles enforce authorization at the AI request boundary.
NIST 800-53
IA-2 Identification and authentication
Uniquely identifies and authenticates organizational users. OIDC-bound sessions tie every AI request to a verified IdP identity with full session-level audit.
NIST 800-53
IA-4 Identifier management
Manages identifiers by receiving authorization, selecting an identifier, assigning it, and disabling it after a defined period of inactivity. SCIM lifecycle events drive identifier management end to end.
ISO 27001
A.5.16 Identity management
Full lifecycle of identities is managed. SCIM provisioning, attribute sync, and lifecycle events provide the management evidence assessors review, with continuous reconciliation.
ISO 27001
A.5.18 Access rights
Access rights are provisioned, reviewed, modified, and removed in accordance with the access control policy. Group-to-bundle mappings enforce this directly; periodic reviews are evidence-ready.
Where identity sync runs

Every IdP your workforce uses. Every source the AI reaches.

Entra ID
Entra ID
Google Workspace
Google Workspace
Gmail
Gmail
Outlook
Outlook
Google Calendar
Google Calendar
Google Drive
Google Drive
Slack
Slack
Microsoft Teams
Microsoft Teams
Jira
Jira
Confluence
Confluence
Notion
Notion
Linear
Linear
See all integrations
Use cases

One identity layer, six regulated workflows.

Architecture

Read the IdP, don't replace it.

PortEden does not store identity, run a parallel directory, or compete with your IdP for ownership of users. It reads from the system you already trust and binds policy to it — so deprovisioning happens upstream and we honor it instantly.

IdP-native, not a parallel directory

PortEden doesn't store identity; it reads it. Deprovisioning happens upstream in your IdP and we honor it instantly. There's no second source of truth to keep in sync, no second admin role to manage.

Group-aware, attribute-rich

PortEden uses the same groups your IdP already manages — security groups, dynamic groups, nested groups, distribution lists. No new directory to maintain, no parallel role taxonomy. Just bind policy to what already exists.

Real-time + reconciled

SCIM events drive instant changes. A periodic full reconciliation acts as a backstop so drift can't accumulate silently. If the IdP fails to send an event, the next reconciliation catches it and writes a recovery record.

Available in: Pro, Business, Enterprise tiers · See pricing

Pairs well with

Identity sync questions

What is identity sync and why do I need it for AI access?
Identity sync is the connection between your identity provider — Microsoft Entra ID, Okta, Google Workspace, JumpCloud — and the policy engine that decides what AI clients can do. Without it, every AI access policy depends on a manual list of users and groups that drifts out of date the moment someone joins, leaves, or moves teams. PortEden reads identity directly from your IdP via SCIM 2.0 and OIDC, so when your IdP says someone is gone or their role changed, every AI access decision reflects that within seconds — not at the next audit cycle.
Which identity providers are supported?
Microsoft Entra ID (Azure AD), Okta, Google Workspace, JumpCloud, Ping Identity, and OneLogin are supported as first-class connectors. Any IdP that speaks SCIM 2.0 for provisioning and OIDC or SAML 2.0 for authentication can be wired in. PortEden does not require you to migrate identity or stand up a parallel directory — it reads the IdP you already operate. Multi-IdP environments (acquired companies, federated partners, separate workforce vs customer directories) are supported through merge rules that resolve the same human across multiple identity sources.
How fast does a deprovisioning propagate?
When your IdP fires a SCIM DELETE or DEACTIVATE event, PortEden processes it in real time — typically under three seconds end to end. The next AI request from that user, from any AI client (Claude, ChatGPT, Copilot, Gemini, MCP servers), is denied at the policy layer. Cached tokens are invalidated. Active sessions are terminated on the next request boundary. There is no overnight sync window; there is no "we'll see them gone tomorrow." The audit trail records the deprovisioning event and every subsequent denied request that referenced the dead identity.
Do I need to install an agent in my IdP?
No. PortEden uses standard SCIM 2.0 for provisioning and OIDC for authentication — both are native protocols supported out of the box by every major IdP. Setup is a one-time SCIM connector and OIDC client registration in your IdP admin console, plus a certificate exchange. There is no on-prem agent, no service account with elevated directory privileges, and no daemon process running inside your tenant. The integration is the same shape your IdP uses to talk to other SaaS applications.
What happens if my IdP is unreachable?
PortEden caches the last known identity state and continues to enforce policy against it. New logins via OIDC fail closed if the IdP is genuinely down — that's the safe behavior. Existing sessions continue under the most recent identity snapshot until they expire. When the IdP comes back, a periodic reconciliation pulls the full directory, replays any missed lifecycle events, and writes a recovery record into the audit trail. Drift cannot accumulate silently because reconciliation is mandatory and on a schedule, not opportunistic.
Can PortEden read custom attributes from my IdP?
Yes. Standard SCIM attributes (email, display name, department, manager, employment status, title) are mapped automatically. Custom attributes — clearance level, cost center, employee type, region, project codes, ethical-wall side — are pulled through SCIM extensions or OIDC custom claims and surfaced as policy variables in PortEden's PBAC layer. So you can write a policy like "deny if requester.clearance < resource.clearance" or "deny if requester.ethicalWall != resource.ethicalWall" and it evaluates against the live attribute value at request time.
How are nested groups handled?
PortEden expands nested group membership at sync time and re-expands on every group change event. If "Senior Engineers" is nested inside "Engineering" which is nested inside "R&D," a member of Senior Engineers receives policy bundles attached to all three groups. Dynamic groups (membership computed from attributes by your IdP) are also supported — PortEden re-evaluates membership when the underlying attributes change, not just on explicit group-edit events. This matches what your IdP already does, so the AI access layer agrees with the rest of your access stack instead of running its own parallel logic.
What about partner orgs and federated identity?
Partner organizations and contractor firms typically authenticate via SAML 2.0 federation — their IdP issues an assertion to your IdP, which then issues a session into PortEden. PortEden reads the federation context (home tenant, partner identity, group claims) and binds policy to it just like any internal user. Multi-IdP merge rules let you treat "sam@partnerco.com via Okta federation" and "sam.contract@yourcompany.com in our Entra ID" as the same human if appropriate, or as distinct identities with distinct policies if not.
Are sync events themselves audited?
Yes, in detail. Every SCIM event PortEden receives is recorded with its source, payload, the role-bundle and policy-group recomputation it triggered, and the resulting access change. Every periodic reconciliation produces a delta report — what changed since the last full sync, what was missed by the real-time stream, what was repaired. Auditors asking "who had access to PHI on March 14 and why?" can reconstruct the answer from the identity-event timeline alone. SIEM export covers SCIM events, OIDC sessions, and reconciliation deltas under a single schema.
Does this support break-glass and emergency access?
Yes. Break-glass identities are first-class — they're configured as a distinct identity class in your IdP (a dedicated emergency-access group), and PortEden treats activation of that group as a high-priority, audited event. When break-glass is invoked, the audit trail captures who activated it, when, against which integration, and the policy snapshot under which the activation was evaluated. Time-boxed activations are supported (auto-revoke after N minutes), and a separate notification stream alerts security and compliance leads in real time so the activation is reviewed, not silent.
What evidence does this produce for SOC 2 CC6.2 and CC6.3 auditors?
CC6.2 directs entities to register and authorize new credentials before issue. PortEden's SCIM-driven provisioning records the IdP authorization event and the policy bundle it produced, so every credential is mapped to an explicit registration record. CC6.3 covers removal of access. Real-time SCIM DEACTIVATE handling produces a per-user, per-integration removal record within seconds, and the periodic reconciliation backstop catches any IdP that fails to send an event. Both controls export evidence directly from the audit trail in formats your auditor accepts (signed CSV, JSON, SIEM streams). Compliance with SOC 2 remains your responsibility — PortEden provides the technical control, you operate the program around it.
What pricing tier includes identity sync?
SCIM 2.0 provisioning and OIDC sign-in are included on the Business tier. Custom attributes, multi-IdP merge, federation, break-glass, SSO/SAML, SCIM, and SIEM export of identity events are on the Enterprise tier. See pricing for the full breakdown.

Ready to make your IdP the source of truth for AI access?

Wire up SCIM and OIDC in under 15 minutes. Enterprise adds SAML 2.0 federation, multi-IdP merge, break-glass workflows, and SIEM export of identity events.

Talk to sales