Okta Provisioning
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.
-
Sign in to TheStorage and open Settings > User Provisioning.
-
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.
-
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
401until the new value is pasted in). -
In the Tenant endpoint section, click Copy next to the endpoint URL. It looks like:
https://service.thestorage.app/api/<your-tenant>/scim/v2Keep both values to hand for Step 10.
Step 2: Create the Application in Okta
-
Sign in to the Okta Admin Console with an administrator account.
-
Navigate to Applications > Applications, then click Browse App Catalog.
-
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.
-
Click Add Integration. On the General Settings page, set:
Field Value Application label TheStorage SCIM ProvisioningApplication visibility Both 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
-
On the new application's overview page, open the Provisioning tab and click Configure API Integration.
-
Tick Enable API integration, then fill in:
Field Value Base URL The endpoint URL from Step 4 API Token The bearer token from Step 3 -
Click Test API Credentials. Okta fires a
GET /Users?count=1at the endpoint and expects a200 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. -
Click Save.
Step 4: Enable Provisioning Actions
-
Still on the Provisioning tab, select To App in the left rail, then click Edit next to Provisioning to App.
-
Tick the following options and click Save:
Option Value Create Users enabled Update User Attributes enabled Deactivate Users enabled Leave "Sync Password" offTheStorage doesn't store user passwords — authentication runs through your identity provider, not TheStorage. Enabling Sync Password will fail every push with a
400on the unsupported attribute, so make sure that one is unticked before you save.
Step 5: Review Attribute Mappings
-
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 attribute SCIM attribute user.emailuserNameuser.emailemails[type eq "work"].valueuser.firstNamename.givenNameuser.lastNamename.familyNameuser.displayNamedisplayNameuser.titletitleuser.departmentdepartmentThere'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
-
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.
-
After assignment, Okta runs the first push within a minute. Open Reports > Okta System Log and filter on
Application assignmentandApplication user provisioningto track progress; each user should reach the status Successfully provisioned. -
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.
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 name | TheStorage role | What the role can do |
|---|---|---|
TheStorage_Admins | Administrator | Everything, including Settings — the only role that can change tenant configuration, integrations, and billing. |
TheStorage_Contributors | Contributor | Day-to-day inventory management: devices, categories, tags, places, vendors, campaigns, audits, users, and software — everything except Settings. |
TheStorage_Supervisors | Supervisor | Oversight access: dashboard, devices, users, audits, software, and subscription pages. Cannot modify the catalog (categories, tags, places, vendors) or run campaigns. |
TheStorage_Users | User | Employee self-service only: their personal My Devices page, audit self-verification, and the employee store. |
-
In Okta, go to Directory > Groups > Add group and create four groups named exactly as in the table above.
Group names must match exactlyThe names are matched case-insensitively, but the spelling has to be exact.
TheStorage Admins(with a space) orTheStorageAdmins(without the underscore) will not be recognised, and members of a misspelled group silently fall back to the User role. -
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.
-
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. -
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_AdminsandTheStorage_Usersgets 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.
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.
-
In the TheStorage app, open Provisioning > To App > Go to Profile Editor. If the SCIM
photosattribute isn't already listed, click Add Attribute and add it with the external namephotos[type eq "photo"].valueand type String. -
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. -
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.