How to Integrate Delinea with Okta for Stronger Privileged Access Management

Privileged access management depends on 2 control points working together: identity verification and privilege control.

Okta can define who the user is, how they authenticate, which groups they belong to, and what conditions apply before access is granted.

Delinea can control privileged credentials, secrets, sessions, approvals, checkouts, endpoint elevation and audit evidence.

The value of integrating Delinea with Okta is operational control. The user signs in through a central identity service. Privileged access is then governed through PAM policies, MFA, vault controls, session recording and logs that can be reviewed by security and audit teams.

According to Delinea’s Okta federation documentation, the Delinea Platform supports Okta SSO using either SAML 2.0 or OIDC. Delinea’s Okta Verify MFA documentation also confirms that Delinea can use Okta APIs directly for Okta Verify MFA push notifications across Platform login, secret checkout, privileged account access, endpoint login and endpoint elevation.

That means the integration can cover more than login. It can support the full privileged access workflow.

The target model: Okta for identity, Delinea for privileged control

The cleanest design starts with a simple operating model.

Okta manages workforce identity. Delinea manages privileged access. The integration connects the 2, so that privileged access decisions are based on verified identity, group membership, device context and policy.

A practical model usually includes:

1. Okta as the identity provider.
2. Delinea Platform as the federated PAM platform.
3. Secret Server for privileged credentials and secrets.
4. Okta groups for privileged access assignment.
5. SCIM for user and group lifecycle where supported.
6. Okta Verify MFA for privileged access checks.
7. Secret Server session recording for selected privileged sessions.
8. Syslog or CEF forwarding into the SIEM.

The first design decision is product scope: Delinea Platform, Secret Server Cloud, Secret Server On-Premises, or a hybrid model.

Delinea’s Okta IdP documentation for Secret Server states that the Okta IdP integration works with Secret Server Cloud and Secret Server On-Premises, and is not compatible with Secret Server on the Delinea Platform. For Delinea Platform deployments, use the platform federation path in Delinea’s Okta federation guide.

That distinction affects the SSO flow, SCIM model and administrative setup.

Step 1: define scope before configuration

Before opening either admin console, define the exact scope.

Start with these questions:

1. Which Delinea environment is in scope: Delinea Platform, Secret Server Cloud, Secret Server On-Premises, or a hybrid model?
2. Which users need access: PAM admins, infrastructure admins, database teams, DevOps teams, third-party administrators, auditors?
3. Which privileged actions require step-up MFA?
4. Which secrets need checkout control?
5. Which sessions need recording?
6. Which events must reach the SIEM?
7. Which Okta groups will map to Delinea access?

This step prevents broad SSO access with weak privileged group design.

For example, avoid assigning access through general IT department groups. Create purpose-specific groups such as:

1. PAM-Delinea-Admins
2. PAM-SecretServer-Auditors
3. PAM-Windows-RDP-Recorded
4. PAM-Linux-SSH-Elevation
5. PAM-DBA-Checkout
6. PAM-BreakGlass-Controlled

Each group should have an owner, approval path, review frequency and intended Delinea permission set.

Step 2: choose SAML or OIDC for Delinea Platform federation

Delinea’s Okta federation guide says you can use either SAML 2.0 or OIDC for Okta SSO, and you do not need to configure both.

For most enterprise PAM projects, SAML remains a common choice because many IAM teams already use SAML app integrations, group assertions and certificate-based IdP metadata. OIDC is also valid, especially when the organization prefers OIDC application registration and callback-based configuration.

The practical recommendation: choose the protocol your IAM team can operate cleanly over time. The quality of the implementation depends on certificate rotation, group design, app assignment, policy rules and operational ownership.

Step 3: build the Okta SAML application

For SAML-based federation, Delinea’s setup instructions define the core Okta steps:

1. In Okta, go to Applications.
2. Click Create App Integration.
3. Select SAML 2.0.
4. Give the app a clear name, such as Delinea Platform SAML.
5. Set the Single sign-on URL to: https://[HOST-NAME].delinea.app/identity-federation/saml/assertion-consumer
6. Replace [HOST-NAME] with the tenant hostname.
7. Set the Audience URI / SP Entity ID to an agreed name, such as Delinea_Federation.
8. Add the profile attribute statements required by Delinea.

Delinea’s SAML attribute guidance lists these profile attribute statements:

Then assign the app to the right users or groups. Delinea’s SAML setup process also requires downloading the active signing certificate and saving the IdP metadata XML. Delinea uses that metadata when adding the SAML provider on the platform side.

This is a good moment to document certificate ownership. PAM access should not depend on a certificate that nobody tracks.

Step 4: add Okta as a provider in Delinea

Once the Okta SAML app exists, add the provider in Delinea.

Delinea’s provider setup instructions describe the platform-side flow: go to the Federation Providers page, add a provider, select SAML, upload the Okta metadata XML, apply it, and confirm the platform has auto-filled values such as name, protocol and entity ID.

Then add the IdP certificate, login URL, logout URL and platform callback URL.

Delinea’s guide gives the platform callback URL pattern:

https://[HOST-NAME].delinea.app/identity-federation/saml/assertion-consumer

Enable the provider only after the core values are complete, then add the relevant email domain for federated users.

A controlled rollout works best. Start with 1 admin test group, validate login and claims, then expand to the next privileged user group.

Step 5: configure group mapping

Group mapping turns SSO into access control.

Delinea’s group mapping instructions show the Okta SAML configuration pattern: add a group attribute statement named groups, set the name format to Unspecified, and use a filter such as Matches regex: .*.

That broad regex sends all groups assigned to the application. Delinea’s same group mapping guidance notes that the filter can be changed to apply only to specific groups.

For production, restrict the group claim.

A cleaner pattern is to filter only groups that start with a PAM prefix, such as PAM-.*. This keeps the assertion smaller, reduces accidental exposure of group names and makes the integration easier to review.

Okta’s group attribute statement documentation shows that group attributes are configured directly on the SAML app’s Sign On tab. This is where IAM and PAM administrators should agree on naming, filtering and review rules.

Recommended governance rules:

1. Use dedicated PAM groups.
2. Keep group names readable.
3. Assign one owner per group.
4. Separate admin, auditor and operator roles.
5. Avoid nested ambiguity where possible.
6. Review privileged groups at least quarterly.
7. Test mover and leaver scenarios before production.

Step 6: decide how SCIM fits the deployment

SSO authenticates the user. SCIM manages user and group lifecycle.

Delinea’s SCIM connector documentation describes SCIM 2.0 as a protocol for automating provisioning and deprovisioning across systems, and states that the Delinea SCIM Cloud Connector supports automated provisioning, identity data synchronization, and group and role management.

For the Delinea Platform, Delinea’s Okta SCIM documentation says Okta acts as the SCIM client and Delinea Platform acts as the SCIM service provider. It also lists supported use cases: creating users, updating users, deprovisioning accounts, creating groups, updating groups, deleting groups, and adding or removing users from groups.

There is an important availability note. Delinea’s Okta SCIM Platform documentation currently states that this integration is available only to customers participating in a private preview. Check this with Delinea before making SCIM part of a committed project plan.

For Secret Server Cloud, Delinea’s Secret Server SCIM documentation states that the Okta SCIM integration works only with Secret Server Cloud and is not compatible with Secret Server on the Delinea Platform. It also states that once upgraded to the Delinea Platform, identity data moves to the platform and is no longer maintained in Secret Server.

Practical guidance: document the product model first, then choose the SCIM path.

Step 7: apply Okta app sign-in policies

Delinea controls privileged access. Okta should still treat the Delinea app as a high-risk application.

Okta’s app sign-in policy documentation says app sign-in policies are built on rules, and the rule order matters because administrators add specific rules above the catch-all rule.

Use a dedicated Okta app sign-in policy for Delinea. Then define rules based on access level.

Recommended policy structure:

1. Delinea administrators: require strong MFA and restrict access to registered or managed devices.
2. Privileged operators: require MFA and apply stricter checks for unknown networks.
3. Auditors: allow read-only access with MFA.
4. Break-glass accounts: require separate monitoring and approval procedures.
5. Catch-all: deny or require strong authentication, depending on your Okta model.

Okta’s policy rule documentation lists usable rule conditions such as group membership, specific users, device state, device management, device assurance policy, device platform and IP zone. It also warns that IP geolocation is not guaranteed, so location should not be the only deny condition.

For device posture, Okta’s device assurance documentation says device assurance can be added to app sign-in rules, with registered device state and device assurance policies as conditions. For a PAM application, this is useful when privileged access should come only from trusted or managed endpoints.

Step 8: use Okta Verify for privileged-action MFA

Application login and privileged action are separate moments.

A user may pass Okta SSO and still need MFA before checking out a secret, launching a session or elevating privileges. This is where Delinea and Okta Verify work together.

Delinea’s Okta Verify MFA documentation says the Delinea Platform can use Okta APIs directly to trigger Okta Verify push notifications. It also states that this removes the need for a RADIUS server and supports Delinea Platform login, secret checkout, privileged account access, endpoint login and endpoint elevation through PCS or Server Suite.

Start with the highest-risk actions:

1. Viewing or checking out domain admin credentials.
2. Accessing production database accounts.
3. Launching privileged RDP or SSH sessions.
4. Using break-glass secrets.
5. Elevating privileges on servers.
6. Accessing secrets tied to regulated systems.
7. Exporting or changing sensitive secrets.

This gives the security team a stronger control point at the moment privilege is used.

Step 9: require MFA for selected secrets

Delinea’s MFA for Secrets documentation states that MFA for Secrets is available through the Delinea Platform and lets administrators add security requirements for specific secrets. It also says MFA is disabled by default for secrets, and can be enabled on an individual secret, through a secret policy, or through bulk operations.

A practical rollout could start with 3 policy levels:

Level 1: standard secrets
Use standard vault access with appropriate folder permissions and audit logging.

Level 2: sensitive secrets
Require MFA before viewing, changing or checking out the secret.

Level 3: critical secrets
Require MFA, session recording where applicable, approval workflow, restricted group access and SIEM alerts.

Delinea’s MFA for Secrets documentation also notes that if a secret policy enables MFA and is applied to a folder, secrets added to that folder inherit the MFA setting. This is useful for production admin folders, break-glass folders and regulated-system credentials.

Step 10: enable session recording where evidence matters

Privileged access control should leave a clear record.

Secret checkout tells you who accessed a credential. Session recording can show what happened during the privileged session.

Delinea’s session recording documentation says session recording must be enabled on the Security tab for each secret, and Secret Server records the session when the launcher is used. The same documentation says Secret Server can create videos of launched sessions and can add metadata such as keystrokes for RDP and SSH sessions when the required options are enabled.

Use session recording for:

1. Production server access.
2. Domain controller administration.
3. Database administration.
4. Third-party administrator access.
5. Break-glass use.
6. High-risk SSH and RDP access.
7. Systems covered by audit or regulatory requirements.

Delinea’s session recording documentation notes that RDP metadata requires the advanced session recording feature and an advanced session recording agent on target servers, while SSH keystroke data relies on the Secret Server SSH Proxy. Include those dependencies in the technical plan.

Step 11: forward Delinea logs to the SIEM

The integration should feed security monitoring.

Delinea’s Syslog and CEF logging documentation says Secret Server can send important log messages to an external syslog server using UDP, TCP or Secure TCP, and states that CEF is an industry-standard format on top of syslog messages for interoperability between platforms.

Use Secure TCP where possible. Delinea’s Syslog and CEF logging documentation explicitly recommends Secure TCP because Secret Server logs contain sensitive information.

Prioritize these SIEM detections:

1. Successful Okta sign-in followed by denied Delinea access.
2. Failed Delinea access after successful Okta authentication.
3. Secret checkout outside the normal access window.
4. Break-glass secret use.
5. Secret policy change.
6. Permission changes on sensitive folders.
7. Session recording viewed.
8. Password displayed or copied to clipboard.
9. Secret export.
10. Repeated checkout attempts.
11. SCIM provisioning errors affecting deprovisioning.

Delinea’s syslog event list includes events such as secret launch, password copied to clipboard, password displayed, secret password change, secret policy change, session recording view and secret view. These are high-value events for SOC and audit reporting.

Step 12: test the full workflow before rollout

Test the integration as a workflow, not as separate configuration tasks.

Minimum test plan:

1. Assigned user SSO: user assigned to the Okta app logs into Delinea successfully.
2. Unassigned user SSO: user without app assignment cannot access Delinea.
3. Group claim: Okta sends the expected PAM group claim.
4. Delinea mapping: Delinea maps the Okta group to the expected role or group.
5. Mover scenario: user moved from one PAM group to another loses old access and receives new access.
6. Leaver scenario: deactivated user loses access through SCIM or the agreed lifecycle process.
7. Admin policy: Delinea admin access requires the expected Okta policy checks.
8. Secret MFA: protected secret checkout triggers MFA.
9. Endpoint elevation: endpoint login or elevation triggers Okta Verify where configured.
10. Session recording: selected SSH or RDP launcher sessions are recorded.
11. SIEM visibility: important Delinea events arrive in the SIEM with useful fields.
12. Audit pack: security can reconstruct who authenticated, which policy applied, which secret was accessed and whether a session was recorded.

This is the difference between a working integration and an auditable privileged access workflow.

Common mistakes

Using broad groups for privileged access

General IT groups create too much privilege ambiguity. Use dedicated PAM groups with named owners.

Sending every Okta group in the SAML assertion

Delinea’s group mapping example uses Matches regex: .*, but the same documentation notes that the filter can be changed for specific groups. Production deployments should restrict the group claim.

Treating SSO as the main control

SSO verifies identity at login. Privileged access still needs secret-level controls, MFA, checkout rules, session recording and evidence.

Skipping mover and leaver tests

A privileged access integration must prove that users lose access when they change role or leave the organization.

Forgetting certificate and token ownership

SAML certificates, OIDC secrets, SCIM service credentials and API tokens need owners, rotation schedules and change records.

Recording sessions without defining review rules

Session recording has limited value if nobody defines retention, access rights, review criteria and escalation paths.

What security leaders should expect from the integration

A well-built Delinea and Okta integration should give security leaders clearer control over privileged access.

The expected outcomes are practical:

1. Users authenticate through Okta before accessing Delinea.
2. Delinea access is assigned through controlled Okta groups.
3. Privileged users face stronger policy checks than standard users.
4. Sensitive secret access can require step-up MFA.
5. Critical sessions can be recorded.
6. Secret access and privileged activity can be sent to the SIEM.
7. Audit teams can review access evidence from Okta and Delinea together.
8. Joiner, mover and leaver processes can reduce standing privileged access.

For Cloudcomputing clients, the strongest value sits in the implementation design: defining the right groups, policies, access workflows, evidence model and operational ownership before configuration starts.

Delinea and Okta provide the technical integration points. The security gain comes from turning those points into a controlled privileged access process that identity, infrastructure, security and audit teams can operate with confidence.