Skip to main content

Okta Provisioning

Beta

Okta provisioning is in beta. The SCIM 2.0 endpoint accepts the same payloads Okta sends to any compliant target, but the integration hasn't been certified through the Okta Integration Network or hardened against every Okta tenant configuration we'd want to support at GA. Roll it out to a pilot group first, and let support know if you hit anything unexpected — that feedback is what moves the integration to general availability.

Once Okta Universal Directory is connected to TheStorage, your directory drives the user list. New hires appear in TheStorage minutes after you assign them to the app, profile changes flow through on the next push, and users who are unassigned or deactivated in Okta are deactivated in TheStorage without anyone clicking a button.

The integration runs over SCIM 2.0 through Okta's generic SCIM 2.0 application template, so no Okta Integration Network (OIN) listing is required. Beyond user accounts, Okta's Push Groups feature can also manage TheStorage roles: membership in four pre-defined groups maps directly onto roles (see Step 7).

Requirements

  • An Okta administrator role with the right to add applications and configure provisioning — typically Super Administrator or Application Administrator.
  • A TheStorage user with the Administrator role (needed to enable SCIM and copy the bearer token).
  • An Okta edition that includes Lifecycle Management — the Provisioning tab is only available on plans that bundle Okta Lifecycle Management.

Step 1: Generate the SCIM Credentials in TheStorage

There's no on/off switch for SCIM — the tenant endpoint is always reachable, and what actually controls inbound provisioning is whether a bearer token is configured. Until you generate one, the panel shows Not configured and every inbound call is rejected.

  1. Sign in to TheStorage and open Settings > User Provisioning.

  2. In the Authentication section, click Generate token. The new bearer token appears in a masked field — click the eye icon to reveal it, or Copy to grab it directly.

  3. Stash the token somewhere safe — a password manager, or paste it straight into Step 10 below. TheStorage only keeps a hash, so once you navigate away the raw value is gone for good. The only way to see a token again is Regenerate token, which immediately invalidates the current one (Okta gets 401 until the new value is pasted in).

  4. In the Tenant endpoint section, click Copy next to the endpoint URL. It looks like:

    https://service.thestorage.app/api/<your-tenant>/scim/v2

    Keep both values to hand for Step 10.

Step 2: Create the Application in Okta

  1. Sign in to the Okta Admin Console with an administrator account.

  2. Navigate to Applications > Applications, then click Browse App Catalog.

  3. Search for SCIM 2.0 Test App (Header Auth) and open it. Don't be put off by the word "Test" — this is Okta's official generic SCIM 2.0 template, and it's intended for production use against any SCIM endpoint that authenticates with a static bearer token.

  4. Click Add Integration. On the General Settings page, set:

    FieldValue
    Application labelTheStorage SCIM Provisioning
    Application visibilityBoth checkboxes unchecked (TheStorage has no Okta-based SSO chiclet)

    Click Next, skip the Sign-On Options page with the defaults, and click Done.

Step 3: Configure the SCIM Connection

  1. On the new application's overview page, open the Provisioning tab and click Configure API Integration.

  2. Tick Enable API integration, then fill in:

    FieldValue
    Base URLThe endpoint URL from Step 4
    API TokenThe bearer token from Step 3
  3. Click Test API Credentials. Okta fires a GET /Users?count=1 at the endpoint and expects a 200 OK; a green The API credentials were verified successfully banner confirms the connection. If the test fails, the usual suspects are a trailing slash on the endpoint URL, the wrong tenant slug, or a stale token — re-paste a fresh copy and try again.

  4. Click Save.

Step 4: Enable Provisioning Actions

  1. Still on the Provisioning tab, select To App in the left rail, then click Edit next to Provisioning to App.

  2. Tick the following options and click Save:

    OptionValue
    Create Usersenabled
    Update User Attributesenabled
    Deactivate Usersenabled
    Leave "Sync Password" off

    TheStorage doesn't store user passwords — authentication runs through your identity provider, not TheStorage. Enabling Sync Password will fail every push with a 400 on the unsupported attribute, so make sure that one is unticked before you save.

Step 5: Review Attribute Mappings

  1. Scroll down to the Attribute Mappings section. Okta pre-fills sensible defaults for the standard SCIM attributes. Confirm at least the following map onto TheStorage's expected fields:

    Okta attributeSCIM attribute
    user.emailuserName
    user.emailemails[type eq "work"].value
    user.firstNamename.givenName
    user.lastNamename.familyName
    user.displayNamedisplayName
    user.titletitle
    user.departmentdepartment

    There's nothing to map for groups here — role assignment runs through Okta's separate Push Groups feature, covered in Step 7.

Step 6: Assign Users

  1. Open the Assignments tab and click Assign > Assign to People — or Assign to Groups to push everyone in an Okta group at once. Pick the users or groups that should be synchronised to TheStorage.

    Only assigned principals are provisioned, so start with a small pilot group and widen the scope once the first push succeeds.

  2. After assignment, Okta runs the first push within a minute. Open Reports > Okta System Log and filter on Application assignment and Application user provisioning to track progress; each user should reach the status Successfully provisioned.

  3. Open TheStorage's Users page and confirm the assigned users now appear with the Okta badge on each row.

From here on, Okta is fully event-driven: profile changes in Universal Directory and assignment changes are pushed within seconds, with no scheduled full-sync cycle to wait for.

Step 7: Manage Roles with Okta Groups

Rather than setting each person's permissions inside TheStorage, you can drive them from Okta using Push Groups. TheStorage recognises four pre-defined group names; push a user into one of them from Okta, and their TheStorage role follows automatically.

Turn on group-based roles first

Group membership drives roles only while your tenant's Role management setting is set to Identity provider groups. Open Settings > User Provisioning, find the Role management section ("Manage roles from"), and confirm it's set to Identity provider groups — the default and recommended choice for Okta. If it's set to In-app instead, pushed groups no longer assign roles; you'd manage roles by hand on the Users & Roles page. You can switch between the two modes at any time.

Okta group nameTheStorage roleWhat the role can do
TheStorage_AdminsAdministratorEverything, including Settings — the only role that can change tenant configuration, integrations, and billing.
TheStorage_ContributorsContributorDay-to-day inventory management: devices, categories, tags, places, vendors, campaigns, audits, users, and software — everything except Settings.
TheStorage_SupervisorsSupervisorOversight access: dashboard, devices, users, audits, software, and subscription pages. Cannot modify the catalog (categories, tags, places, vendors) or run campaigns.
TheStorage_UsersUserEmployee self-service only: their personal My Devices page, audit self-verification, and the employee store.
  1. In Okta, go to Directory > Groups > Add group and create four groups named exactly as in the table above.

    Group names must match exactly

    The names are matched case-insensitively, but the spelling has to be exact. TheStorage Admins (with a space) or TheStorageAdmins (without the underscore) will not be recognised, and members of a misspelled group silently fall back to the User role.

  2. Add each user to the group that matches the access they need. Anyone not in one of these groups gets the User role by default, so you only need to populate the higher tiers.

  3. Open the TheStorage app, go to the Push Groups tab, and click Push Groups > Find groups by name. Add each of the four TheStorage_* groups. Okta creates them on the TheStorage endpoint and keeps their membership in sync from then on.

  4. Trigger a sync (or wait a moment — Push Groups is event-driven), then open TheStorage's Users page and spot-check a few accounts: each should show the role matching their group membership.

How role assignment behaves

  • Highest role wins. A user in both TheStorage_Admins and TheStorage_Users gets Administrator — the most powerful membership always takes precedence.
  • No group means User. Removing someone from all four groups demotes them to the User role on the next push; it does not deactivate their account.
  • The tenant owner is protected. A group sync can never demote the tenant owner (the person who originally created the tenant), even if they're removed from every group — this prevents a directory mistake from locking everyone out of Settings.
  • Only these four groups exist. Pushing any other group name has no effect on roles — TheStorage only maps these four. The group objects themselves aren't stored; only the role each one implies.
  • The in-app role control is read-only. While Role management is set to Identity provider groups, the Edit role control on the Users & Roles page is read-only — group membership is authoritative and re-applied on every push. To change someone's access, move them between the groups above, or switch Role management to In-app if you'd rather assign roles in TheStorage. (The tenant owner is always editable in-app as a break-glass exception.)

Step 8 (Optional): Profile Photos

TheStorage accepts a profile photo from any SCIM provider through the standard photos attribute — it downloads the image from the URL you send and re-hosts it on TheStorage's CDN. Okta can supply that URL through a custom attribute mapping.

Prerequisite: a reachable photo URL

Unlike Google Workspace, Okta doesn't expose a ready-made profile photo URL for every user. This step only works if your Okta profile already holds a publicly reachable photo URL — typically sourced from an HR system or profile master — that you can map. TheStorage fetches the URL unauthenticated (only Microsoft Graph URLs get a token, which is Entra-specific), so a login-gated URL will not work.

  1. In the TheStorage app, open Provisioning > To App > Go to Profile Editor. If the SCIM photos attribute isn't already listed, click Add Attribute and add it with the external name photos[type eq "photo"].value and type String.

  2. Back on Provisioning > To App, map your Okta photo-URL attribute (for example user.profilePhotoUrl) to that SCIM attribute, set it to apply on create and update, and save.

  3. Trigger a push for a test user who has a photo URL set. TheStorage downloads the image and shows it on that user's profile within one push.

If a user has no photo URL, nothing changes — any avatar they uploaded manually in TheStorage is preserved.

Known limitations

  • The Okta badge doesn't imply SSO. Users provisioned through this integration get an Okta badge on their TheStorage profile to mark where the account originated, but sign-in still runs through TheStorage's standard identity flow — not Okta SAML or OIDC.