Skip to main content
Connect Thales SafeNet Trusted Access (STA) to Oleria to see who has access through your STA tenant: its users, the groups they belong to, the operators who administer STA, and the SSO applications each group can sign in to. Oleria reads identity and access data through an STA API key, so you can see where access is over-provisioned and take action directly from Oleria.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your STA tenant:
  • Accounts - every STA user, with name, email address, user name, and whether the user is enabled. Oleria also shows when each user was created and last modified, and the user principal name when it differs from the email address. Users with an active FIDO authenticator are shown with multi-factor authentication required, and their last successful FIDO sign-in counts as activity. Sign-ins in the activity log also count toward each user’s last activity. Users synchronized from an external directory are marked as synchronized. The user the API key is mapped to is shown with API access.
  • Operators - users who signed in to the STA console in the last 30 days are marked as administrators and hold the STA Operator role. See Known limitations for operators who haven’t signed in recently.
  • User groups - every group, its direct members, and the groups nested inside it. Groups synchronized from an external directory are marked as synced groups.
  • Applications - every application in STA, with the SAML entity ID or OIDC client ID of SAML and OIDC applications, and the groups assigned to it. When an application is assigned to everyone, Oleria shows the assignment through an Everyone (STA) group that contains every STA user.
  • Application access per user - the applications each user can sign in to, as STA reports them. This includes applications assigned to parent groups of nested groups the user belongs to.
  • Authenticators - each user’s FIDO authenticators, shown as enrollments in a FIDO authenticator that is linked to the user’s account. Authenticators STA reports with no creation or use date aren’t shown.
  • Activity - events from the STA access and audit log:
    • Access requests to applications: granted, failed, and denied.
    • Token authentications: successes and failures.
    • Sign-ins to the STA console: successes and failures.
    • Administrative changes: objects created, updated, deactivated, and deleted, credited to the operator who made them. The name of the changed object is kept with the event.
    Oleria keeps every other log event too, under its STA event name. It leaves out its own log reads. Events are credited to the STA user who triggered them. Events from a user created in roughly the last 10 minutes can be imported without being credited to that user, and they stay that way. Later events are credited once Oleria refreshes its user list. When two user names differ only by letter case, an event is credited only when its user name matches one of them exactly.
Oleria refreshes users, groups, and applications on its regular sync schedule. Activity syncs separately. It usually trails real time by about 5 minutes, and can take longer on busy tenants and during the first import of history, because STA limits how fast its log can be read.

​
Prerequisites

  • An STA operator account with the operator role, which STA assigns to every user promoted on the Operators tab and which grants unrestricted rights, to generate an API key under Settings > API Keys. Thales doesn’t document a narrower role for API keys. If you use a custom role instead, it needs access to Settings > API Keys.
  • A dedicated STA user to map the API key to, rather than a named person’s account, so the integration doesn’t depend on one person’s account. Oleria acts as this user.
  • Admin access to the Oleria workspace.
STA has no read-only API key. Every STA API key has full access to the STA API, and Oleria uses that access for discovery and for remediation actions.
Oleria connects only to these STA API hosts, over HTTPS on port 443:
  • api.safenetid.com
  • api.us.safenetid.com
  • api.eu.safenetid.com

​
Create an API key in STA

1

Open API Keys

In the STA Access Management console, go to Settings > API Keys.
2

Generate the API key

Select Generate API Key, enter a name, select the dedicated service account for Oleria in the Service Account field, and select Next. Each API key maps to one service account, and the service account decides which tenants the key can reach. Keys expire: note the expiry date and renew the key in STA before it lapses.
3

Copy the details

Copy the API key. STA shows it only once. On the same page, copy the Endpoint URL and note the user name the key is mapped to.
The exact location of these settings can change over time. If the steps above don’t match what you see, refer to the STA API key documentation.

​
Connect Thales SafeNet Trusted Access to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations -> select Thales SafeNet Trusted Access.
2

Complete the connection form

Select Continue and provide the following:
3

Confirm the connection

Select Authenticate. Before it saves anything, Oleria checks that the API key reaches your tenant, that the user you entered exists, and that the key can read the STA log. Find the newly connected tenant on the Connected tab of your Oleria Integrations page.

​
Verify the integration

Confirm the STA tenant appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, check that users, groups, and applications appear in your Oleria workspace. Log events appear later, as described in What Oleria discovers.
When you edit the integration, you can replace the API key, for example after STA expires it, or change the API key user name if you map the key to a different user. Oleria then protects the new user from its own actions. Leave API key blank to keep the stored key, and select Update. You can’t change the Endpoint URL of an existing integration. To connect another STA tenant, add a new integration.

​
Remediation actions

Oleria can take these actions in STA. Before it offers an action, Oleria checks that the API key still reaches your tenant:
  • Disable a user and enable a user. Both can be reverted.
  • Add a user to a group and remove a user from a group. These actions change direct group membership. Both can be reverted.
  • Assign an application to a group and remove an application from a group. Both can be reverted. If STA accepts the change but doesn’t show it afterwards, the action fails and nothing is recorded, so it can’t be reverted. The change may still apply: check the application in the STA console. Assigning an application to a nested group fails when the application has no groups assigned yet or its assignment lists groups by name. Removing it from a nested group fails when the assignment lists groups by name. STA doesn’t list nested groups, so Oleria can’t confirm the group’s name. Change these assignments in the STA console.
  • Create a user and create a group. Reverting deletes only the user or group the action created: the user only if it still has the same ID and user name, and the group only while it has no members and isn’t assigned to any application. A new user is created disabled unless the action asks for it to be activated; run Enable a user afterwards if it didn’t. Creating a user can’t set a password, because STA users enroll an authenticator instead, so Oleria ignores password settings and notes this on the action. It can’t add the user to groups either: a create request that lists groups fails. Create the user first, then run Add a user to a group.
  • Delete a user. This can’t be reverted: STA schedules the user’s removal after 24 hours, and a deleted user can’t be restored.
  • Revoke a user’s sessions. Oleria ends the user’s STA sessions, so the user must sign in to STA again. Sessions that applications keep on their own aren’t ended. To stop access to those, also disable the user. This action can’t be reverted, because ended sessions can’t be restored. Session termination depends on your STA plan: before it offers this action, Oleria also checks that the API key can read user sessions.
Keep these limits in mind when you use these actions:
  • Oleria reads the user, group, or application before it changes anything. If it’s already in the requested state, Oleria makes no change. If it no longer exists, the action fails, including Delete a user on a user that’s already gone. Revoking sessions always asks STA to end the user’s sessions, even when none are listed.
  • Except for application assignments, an action that STA accepts but doesn’t show yet succeeds and is marked unconfirmed. Oleria can’t revert an unconfirmed Create a user or Create a group, because it can’t tell which user or group it created. Delete it in STA if needed. If STA returns an error but the target ends up in the requested state anyway, the action succeeds, but reverting it changes nothing. If the user signs in again right after you revoke their sessions, the revocation is also marked unconfirmed.
  • Reverting an action undoes only the change that action made. If the target no longer exists, Oleria reports that nothing was reverted.
  • Oleria won’t disable, delete, remove from a group, or revoke the sessions of the user the API key is mapped to, and won’t delete it when reverting a create, because that could disconnect the integration.
  • Oleria doesn’t add users to or remove users from groups synchronized from an external directory. Change their membership in the directory instead. Oleria can’t tell whether a nested group is synchronized, because STA lists nested groups only as members of their parent group. For a nested group, Oleria makes the change and notes that the group’s sync state is unknown.
  • Users synchronized from an external directory can be disabled, enabled, or deleted, but the next directory sync may undo the change or recreate the user. Oleria notes this on the action.
  • Removing a user from a group removes only the direct membership. If the user belongs to the group only through a nested group, the removal fails. To remove that access, remove the user from the nested group. If the user is both a direct member and a member through a nested group, Oleria removes the direct membership and notes that the user is still a member through the nested group.
  • When an application is assigned to everyone, Oleria won’t assign it to a group, because that would remove everyone else’s access. Removing a group from it fails, because the group keeps access through everyone. Change these assignments in the STA console. The Everyone (STA) group itself can’t be targeted.
  • Creating a user or group with a name that’s already in use fails.

​
Known limitations

  • Multi-factor authentication only from FIDO authenticators. STA’s API reports FIDO authenticators only. MobilePASS+, OTP, SMS, and GrIDsure tokens aren’t visible, so a user who has only those shows multi-factor authentication as unavailable rather than not required. FIDO authenticators also depend on your STA plan: if the API key can’t read them, multi-factor authentication shows as unavailable for every user.
  • No single sign-on posture. STA’s API doesn’t report whether a user signs in through an external identity provider, so single sign-on shows as unavailable.
  • No password change date. STA’s API doesn’t report when a user last changed their password.
  • Operators are detected from console sign-ins. STA’s API doesn’t list operators or their roles, so an operator who hasn’t signed in to the STA console in the last 30 days shows as a regular user. All operators share the single STA Operator role, whatever their role in STA. Oleria remembers the operators it has seen, and an operator drops off once 30 days pass without a console sign-in. Oleria may need several syncs to read the full 30 days the first time. Until then, operators it hasn’t seen yet show as regular users, and those accounts are marked as having incomplete operator detection. The same applies to any later sync that can’t read the whole log. Operators Oleria already knows stay marked. If Oleria can’t read the STA log, the user sync fails rather than showing users without operators.
  • API keys aren’t inventoried. STA manages API keys only in its console and has no API to list them, so Oleria doesn’t discover them as non-human identities or tell which users they’re mapped to, apart from this integration’s own. The user an API key is mapped to is an ordinary STA user, so it appears as an account.
  • Synchronized users and groups are managed by their directory. See Remediation actions for what Oleria can change on them.
  • Created and last-modified dates come from STA’s SCIM API. If the API key can’t read STA’s SCIM user list, the sync still succeeds, but users show no created or last-modified date.
  • Per-user application access depends on your API key. If the API key can’t read users’ applications, users show no per-user application access, and the sync still succeeds. Group assignments of applications still appear. If Oleria can’t read the application list itself, the user sync fails.
  • Applications are assigned to groups only. STA assigns applications to groups or to everyone, never to individual users. Assignments of authentication agent applications aren’t shown.
  • Access policies aren’t imported. STA manages access policies only in its console. Each access request event shows the name of the policy that applied.
  • Activity history depends on STA’s retention. STA doesn’t document how long it keeps log events. Oleria imports up to 90 days of history, as far back as your tenant keeps. Oleria reads at most 5,000 log pages for each day. On a day with more events than that, the rest of that day isn’t imported, and the sync continues. Token Management actions in the STA console don’t appear in the STA log, so Oleria can’t import them.
  • One tenant per integration. Oleria syncs only the tenant in the Endpoint URL. To cover child or delegated accounts, add an integration for each tenant code.

​
Contact us

For questions about this integration, contact us at support@oleria.com.