IT playbook · AI Employee: Ivy

App Registration & SSO Setup

New app SSO-ready in one day

The problem

Every new SaaS app that needs SSO enrollment goes through the same setup grind: metadata exchange, attribute mapping, group assignment rules, testing with a pilot user, production rollout, documentation. Each app takes IT 2-6 hours; ~40-80 apps per year means IT loses weeks on identical setup work. Meanwhile, apps that could be on SSO don't get set up ("too much friction"), and shadow IT proliferates.

At a glance
Trigger
Form
Approvals
Security approval on scopes above baseline
What it does
Writes to your systems
Systems
Okta · Microsoft Entra ID · Azure AD · GitHub · AWS IAM
How it feels in production

An hour-by-hour walkthrough.

Product manager Kiran requests: "we're adopting Miro for the design team, need SSO." Ivy picks up the request and starts the setup: - App: Miro (SAML 2.0 + SCIM supported, standard IdP integration profile) - IdP: Okta (company standard) - Standard attribute mapping (email as NameID, first/last, groups) - Group assignment: Miro-users = design-team + product-managers-team members from Okta - Provisioning: SCIM enabled for auto-provision + deprovision Ivy configures in ~15 minutes: - Registers the Miro SAML app in Okta with pre-built connector - Sets attribute mappings per Miro's requirements - Configures the group-based assignment rules - Enables SCIM provisioning with test user - Verifies SSO with test login - Documents the setup in the app registry Ivy notifies Kiran: "Miro SSO is live. Design + product-managers auto-provision on first login. I've created the admin doc with SCIM endpoint and rotation procedure. Any users you want to explicitly grant beyond the auto-groups?" For non-standard apps (unusual auth flow, custom attribute needs, complex provisioning), Ivy prepares the config + surfaces open questions to IT ops for judgment. Configuration standardized; documentation always current; sunset flow ready for when the app is retired.
How it works

Step by step.

  1. 01

    Intake SSO request + resolve app profile

    App name + auth capability (SAML / OIDC / SCIM). Standard profile matched from known app library or fresh setup path.

    App request portal · SSO app library
  2. 02

    Configure in identity provider

    App registration, attribute mapping, group assignment rules, provisioning. Standard profiles auto-configure; custom needs prompted.

    Okta · Azure AD · Google Workspace · JumpCloud
  3. 03

    Enable provisioning (SCIM) where supported

    Auto-provision + deprovision. Reduces manual account management + closes the leaver-access gap.

    SCIM · Provisioning configuration
  4. 04

    Verify + document + notify

    Test login validation. App registry documentation. Requester notification with admin details.

    App registry · Slack · Teams · Documentation
  5. 05

    Register in Access Reviews + Compliance

    New app auto-enrolled in quarterly access reviews. Sensitive-data apps flagged for additional compliance workflows.

    Access review platform · Compliance registry
Systems and wiring

What you connect to make this run.

Okta · Azure AD · Google Workspace · JumpCloud

read+write

Primary identity provider. App registration + attribute mapping + group assignment + provisioning.

SSO app library (Okta Integration Network · SaaS catalog)

read

Pre-built connectors for common apps. Reduces setup time from hours to minutes for known apps.

SCIM provisioning endpoints

read+write

Auto-provision + deprovision. Depends on vendor's SCIM support; enabled where supported.

App registry · Compliance

read+write

App inventory with SSO status, data classification, review cadence, compliance scope.

What changes

Before and after, honestly.

Time from SSO request to production
Before
3-14 days
After
Same day (routine)
IT hours per SSO setup
Before
2-6 hours
After
15-30 minutes (routine)
% of company SaaS on SSO
Before
40-70%
After
85-95%
Deprovisioning gaps (departed users retaining access)
Before
10-25% of apps
After
Under 2%
Frequently asked

Answers about this playbook.

What about apps that don't support SAML or SCIM?

Password-vault fallback (1Password, Dashlane team feature). Not ideal but better than shared credentials. Ivy documents the exception + tracks for future improvement.

How does it handle SP-initiated vs. IdP-initiated flows?

Both supported; user preference respected. Some apps only support one; Ivy documents the actual behavior for the app.

What about legacy apps still on password auth?

Ivy inventories these + prioritises migration by data sensitivity + usage. Not every app gets SSO immediately; migration prioritized.

How does it handle custom apps (internal-built)?

OIDC or SAML integration with the internal app. Same setup flow with additional testing + custom attribute mapping.

What about multi-tenant SSO (per-workspace)?

Complex apps with per-workspace SSO handled with configuration guidance. Often needs coordination with app admin on both sides.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.