Connect Okta

Elba connects to Okta in one of two ways:

• Okta as your Elba identity provider: two Okta application configurations, one for administrator sign-in and one service integration for directory synchronization and application assignments.
• Okta for Third-Party Apps only, when your Elba identity provider is Google Workspace or Microsoft 365: one Okta API Services application that reads application assignments and sign-ins. See Connect Okta with an API Services application.

What this connection covers

The directory connection synchronizes active users assigned to the Elba SSO application, Okta groups, and memberships for users synchronized into Elba. It does not import every user merely because they exist in your Okta directory.

The service integration also reads which Okta applications each person synchronized into Elba is assigned, directly or through an Okta group, and each application's sign-on type: federated SSO (SAML, OpenID Connect, or WS-Federation), password vault (SWA), or bookmark. In Third-Party Apps:

• each assignment appears as Assigned in Okta access for that person and application. It counts as access but never opens an issue, receives a tag, or changes the application's usage policy;
• when an application federated in Okta is assigned to a person, their login method shows SSO through Okta instead of a password inferred from email;
• the Managed in Okta and Not managed in Okta filters separate applications assigned in Okta from applications at least 5 people use outside Okta, without an Okta assignment;
• once Elba reads Okta sign-ins, each Okta assignment shows the person's last sign-in through Okta, and the Assigned, no Okta sign-in in 90 days view lists applications with someone assigned more than 90 days ago who has not signed in through Okta since: candidates to unassign.

Only Okta applications that Elba can match with confidence to its application catalog appear; others are skipped. Elba reads assignments after each Okta directory synchronization. See Applications managed in Okta.

Sign-in dates need one more read scope: see Okta sign-ins. The administrator role check at sign-in authorizes access to Elba; it is not a role inventory.

Elba never writes to Okta: it does not change assignments, deactivate users, or change roles. Manage accounts, groups, and assignments in the Okta Admin Console.

Required Okta roles

Complete setup with an active Super Administrator or Application Administrator account.

To show application assignments, the service integration itself must hold an administrator role that can read every application: Super Administrator, Organization Administrator, Read-only Administrator, or an Application Administrator role that is not limited to specific applications. Without one of these roles, Elba skips the assignment synchronization and changes nothing: no assignment is added or removed. Directory synchronization is not affected. An API Services application needs the same role, and Read-only Administrator is enough.

Information to prepare

The Elba setup flow asks for:

• your Okta domain;
• the administrator email address;
• the client ID and client secret for the SSO application;
• the client ID and client secret for the service integration.

The service integration must be allowed to read:

okta.apps.read
okta.users.read
okta.roles.read
okta.groups.read

The SSO application requests okta.users.read.self for the signed-in administrator.

Application assignments use okta.apps.read and okta.roles.read from this list, so they need no additional scope or consent. Sign-ins need okta.logs.read, which is optional: see Okta sign-ins.

Connect Okta

1. Open the Okta setup flow provided by Elba.
2. Enter your Okta domain and administrator email.
3. Create or select the SSO and service applications using the in-product instructions for your environment.
4. Grant the four read scopes above to the service integration and, to show application assignments, one of the administrator roles listed above.
5. Copy the client IDs and secrets into the matching Elba fields.
6. Submit the configuration and sign in through Okta when prompted.
7. Configure your Elba workspace and allow the initial directory synchronization to finish.

If the Okta console labels or application types differ from the instructions shown in your Elba workspace, stop and contact Elba support before creating a second production application.

Okta sign-ins

To show when each person last signed in to their assigned applications, grant okta.logs.read to the service integration:

1. In the Okta Admin Console, open Applications > Applications and select the Elba service integration.
2. On the Okta API Scopes tab, grant okta.logs.read.

Elba asks for this scope on a token of its own, so application assignments keep working without it. Until Elba has read a sign-in in the past week, it checks for the scope once a week, on Mondays, so sign-ins appear within a week of granting it. While the scope is not granted, the Okta System Log can show Elba's refused token request each Monday.

What Elba reads:

• successful single sign-on events (user.authentication.sso) from the Okta System Log: first over the last 89 days, within the 90 days Okta keeps, then every day, plus the 89-day history of an application when Elba starts recording people as assigned to it;
• of those events, Elba keeps only the latest sign-in date of each person to each application it records as an Okta assignment, and nothing else;
• in bursts separated by pauses, which leave most of the System Log rate limit to your other tools, such as your SIEM.

Bookmark applications have no sign-in to read, so they never appear as unused. Sign-in dates show while Elba keeps reading them: if it has read none in the past week, for example because the scope was revoked, the sign-in view and dates are hidden.

Connect Okta with an API Services application

This connection is for organizations whose Elba identity provider is Google Workspace or Microsoft 365. Okta is listed under Third-Party Apps > Sources.

It reads the same application assignments and sign-ins as the identity-provider connection, through an Okta API Services application that you create. Elba matches each Okta user to the Elba user with the same email: their Okta login when it is an email address, otherwise their profile email.

1. In the Okta Admin Console, open Applications > Applications, select Create App Integration, and choose API Services.
2. Under Client Credentials, set Client authentication to Public key / Private key and add a key: generate a new key in Okta and copy the private key in JWK format, or register the public key of an RSA key pair you generated.
3. Clear Require Demonstrating Proof of Possession (DPoP) header in token requests: the connection does not support DPoP.
4. On the Okta API Scopes tab, grant okta.apps.read, okta.users.read, okta.roles.read, and okta.logs.read.
5. On the Admin roles tab, assign the Read-only Administrator role. Without an administrator role, Okta answers with empty lists instead of an error, so Elba would find no application.
6. In Elba, open Third-Party Apps > Sources and select Connect next to Okta. Enter your Okta domain without https:// or -admin (for example, acme.okta.com), the application's client ID, and its private key in JWK format.

Before reading anything, Elba checks the connection:

• Only admin accounts are supported on Okta means the application has no administrator role that can see every Okta application: see step 5;
• Integration was not authorized to connect with Okta means Okta refused the application's requests: check the scopes of step 4.

Once the connection passes, assignments and sign-ins synchronize every day.

Safari Browser Security sign-in

Safari uses the same Okta SSO application and client credentials as the other elba sign-in flows. Before deploying Browser Security on Safari, open that existing OIDC application in Okta and confirm both entries under Sign-in redirect URIs:

• https://login.eu.elba.security/auth-verify/okta
• https://login.eu.elba.security/api/oauth/extension/callback

Keep the first URI and add the second; do not replace the existing application or secret. Then complete one Safari sign-in with a pilot user. The Safari callback is also displayed in the Browser Security Deployment Center.