# IAM

### Why connect your IdP

Your IdP is the source of truth for **who has access to what**. Connecting it to Siit means:

* **A directory aligned with access.** Users, groups, and application assignments sync into Siit, so every request carries the full picture of the requester's access.
* **One-click actions from any request.** Provision, revoke, add to group, reset password, reset MFA, and more — directly from the request side panel, without switching tabs.
* **Workflow-driven provisioning.** Use IdP actions in any workflow: approvals, Day-1 onboarding, access requests, offboarding, SLA escalations.
* **AI Agent automation.** Let the IT Agent run sandboxed IdP actions inside playbooks, gated by approvals when needed.
* **Audit and traceability.** Every IdP action triggered from Siit is recorded on the request timeline.

### What Siit syncs from your IdP

By default, Siit imports:

* **Users** — identity, work email, status (active / suspended / deprovisioned)
* **Groups** — membership, so workflow conditions can match on group
* **Applications** — per-user app assignments and ownership
* **Lifecycle events** — user created, user suspended, group membership change

Work email is the canonical identifier used to match users across your IdP, HRIS, and other connected tools.

### Supported IAM platforms

Siit integrates natively with the four most common IdPs. Each one has its own setup guide:

* [Google Workspace](/integrations/iam/google-workspace.md)
* [Microsoft Entra ID](/integrations/iam/microsoft-entra-id.md)
* [Okta](/integrations/iam/okta.md)
* [JumpCloud](/integrations/iam/jumpcloud.md)

Using a different IdP? Reach out via in-app chat — we also support SAML SSO for sign-in from most providers (see SAML - SSO).

### Actions available per IdP

The specific actions Siit exposes vary by IdP. Here's what's available today:

| Action                         | Google Workspace | Entra ID | Okta | JumpCloud |
| ------------------------------ | ---------------- | -------- | ---- | --------- |
| Directory sync (users, groups) | ✓                | ✓        | ✓    | ✓         |
| Add / remove from group        | ✓                | ✓        | ✓    | ✓         |
| suspend / Unsuspend user       | ✓                | —        | ✓    | ✓         |
| Reset password                 | ✓                | —        | ✓    | ✓         |
| Reset MFA                      | —                | —        | ✓    | ✓         |
| Add / remove application       | —                | —        | ✓    | —         |
| Clear User sessions            | ✓                | —        | ✓    | —         |

> **Note** — actions are available from the request side panel, in workflows, and in IT Agent playbooks. Sensitive actions can be gated behind approvals (see Branching & approvals).

### How the sync works

* **Initial import** — all users, groups, and app assignments are imported the first time you connect.
* **Continuous sync** — Siit refreshes the directory automatically (typically every few hours).
* **Real-time actions** — actions triggered from Siit (provision, revoke, reset, etc.) execute immediately and are reflected in the IdP.
* **Source of truth rules** — for each People field, pick which system wins if you're also connected to an HRIS. Configure this in **Settings → People → Fields**.

### HRIS + IdP: the best combination

Most customers connect **both** an HRIS and an IdP. Here's how they complement each other:

|                  | IdP                                       | HRIS                                            |
| ---------------- | ----------------------------------------- | ----------------------------------------------- |
| Source for       | Accounts, app access, authentication      | Employment data, org structure, lifecycle dates |
| Triggers in Siit | User created, group membership change     | Start / end dates, probation, anniversaries     |
| Typical actions  | Provisioning, SSO, group / app assignment | Pre-boarding sequences before accounts exist    |

Connecting both means a full **Day-1 onboarding workflow** can fire on the HRIS start date, then use the IdP to create the account and assign the right apps and groups — and a matching **offboarding** flow can cleanly revoke everything on the HRIS end date.

### Common use cases

* **Day-1 provisioning** — Trigger: HRIS Start date. Actions: IdP create user → add to baseline groups → assign app bundle by department.
* **Self-service access request** — Service: "Request access to app". Actions: manager approval → IdP Add application to user → notify requester.
* **Group membership request** — Trigger: Request submitted (App access form). Actions: approval → IdP Add to group → confirmation DM.
* **Password / MFA reset** — Service: "Reset my password" or "Reset MFA". Action: verify identity → IdP reset — gated by approval where required.
* **Offboarding on end date** — Trigger: HRIS End date. Actions: IdP revoke sessions → remove app access → suspend account → equipment pickup request.
* **Side-panel one-click actions** — From any request, agents can run IdP actions directly on the requester without leaving Siit.

### SSO is separate

This section covers IdP as a **directory and action source** (people sync + provisioning). If you're only looking to let users sign in to Siit with Google, Microsoft, Okta, or JumpCloud, see SAML - SSO.

Most customers do both: connect the IdP here to unlock actions, and enable SSO in Settings → Security → SSO for authentication.

### Getting started

1. Go to **Settings → Integrations** and pick your IdP in the library.
2. Authorize the connection (each IdP has its own flow — see the per-platform guides).
3. Review imported users, groups, and apps. Adjust mapping in **Settings → People → Fields** if needed.
4. Set the source of truth per field if you're also connected to an HRIS.
5. Try your first action from a request side panel, or build a workflow in **Workflows → New**.

Pick your IdP above to see the exact setup steps.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.siit.io/integrations/iam.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.