An Introduction to Managing SaaS Shared (Service) Accounts in OPA

Late in 2024 Okta released a new feature for Okta Privileged Access – the ability to manage SaaS shared accounts using the same approach to managing access to other privileged resources like servers. This article provides an introduction to this new feature.

This article assumes the reader is familiar with Okta Privileged Access. If not, we refer you to the OPA articles on this site and the OPA product documentation. Further references are listed at the bottom of this article.

Introduction

Management of shared accounts in SaaS applications, particularly where those credentials have elevated privileges, is a concern for all. Ideally federated users with dynamically allocated elevated privileges should be used for all administrative access. But this is not practical for every SaaS app, with many still relying on non-federated accounts for administrative privileges.

Introducing SaaS Service Accounts in Okta Privileged Access

To address this, a new feature called SaaS Service Accounts, has been added to Okta Privileged Access (OPA). Whilst it says “service” accounts, it refers to any non-federated shared accounts in a SaaS application or service.

This feature extends the list of resource types managed by OPA to include the privileged accounts in SaaS applications, as shown in the following diagram.

Whilst the generic secrets resource type can be used to store application credentials, this new feature is designed specifically for app credentials, storing username and password in the OPA Vault.

There are two patterns for SaaS accounts, shown by (6) and (7) in the diagram above:

• Manual – where there is no OIN integration available to push passwords, the shared account credentials can be stored in the vault and accessed according to policy. But there is no password rotation.

• Automated – where the is an OIN integration that has been tested for password rotation, OPA will store and manage the password for the account. When the credentials are checked-in or on a timer, OPA will rotate the password for that account and the OIN integration will push that new password to the SaaS app.

The list of supported SaaS apps is growing as Okta works through the OIN catalog and validates the password rotation use case.

The SaaS accounts are associated with Okta application definitions and synchronised into OPA. They are assigned to a Resource Group + Project for management. As with other privileged resources in OPA, security policy and rules must be created to define who can access which SaaS account and how (e.g. require MFA or JIT Access Request). The policy membership is based on groups pushed from Okta.

Currently SaaS account credentials are revealed and then copied and pasted into the application login prompt. Expect to see more integration in the future.

The remainder of this article will look at the user experience and then delve into the mechanics of the feature.

The User Experience

We will walk through the user experience for accessing a SaaS service account.

Check Out Credentials

Wendy, our user, goes to their Okta Dashboard and clicks on their Okta Privileged Access tile. The MY PRIVILEGED ACCESS menu contains a number of items including the SaaS Apps menu item. This shows the apps that this user is allowed to access credentials for.

In this case there are two, a Salesforce.com instance that is automated (connected to the OIN app for password rotation) and a LinkedIn instance which is manual (static username and password stored in the vault).

Wendy selects the Salesforce.com app and sees that there is a single account she can access. It’s currently available (i.e. not checked out nor unavailable (due to the password being rotated)).

She selects the account. As with server access, there is an access method associated with accessing the account credentials, and this will show the conditions to reveal the credentials. In this case the account can be (exclusively) checked out, and there is no requirement for MFA or JIT Access Request.

On clicking the Show credentials button a popup window shows the username, password and the remaining checkout time. She could click the show button to see the password. Note that this is a complex password as it has been rotated by OPA.

These credentials are copied and pasted into the Salesforce login prompt to gain access.

Wendy can continue to leverage the credentials within that checkout window.

Check In Credentials

There is another menu item, Checked Out Accounts, where Wendy can view the accounts she has checked out.

She can see the Salesforce.com account is checked out and has a remaining time of 13 mins.

There are three options for check in:

• Wendy could click the Check in button,
• she could leave it until the remaining time expires and OPA will automatically check it in, or
• an administrator could use the OPA Admin Console to check the account in.

When the account is checked in, the password is rotated.

The manual accounts are slightly different. As the credentials are static, there is no concept of exclusive checkout or password rotation. So revealing the credentials for a manual account will not show in the Checked Out Accounts view.

The Mechanics

In this section we will look at how it’s put together, the administrator perspective if you like.

Overview

The following figure gives an overview of the components and flow involved in on-boarding a SaaS app account.

The flow is:

1. There is an application defined in Okta. This may be a live application leveraging OIN with provisioning enable (for automated accounts) or an app without password rotation (manual) such as a purely SSO app or some sort of dummy/disconnected app.
2. The new Service Account page is used to define one or more service accounts for the app.
3. A background process will synchronise any new accounts from Okta to OPA
4. In OPA the new accounts are assigned to a Project in a Resource Group
5. These accounts are then subject to common settings for that Project – primarily password strength rules
6. Policies and rules are created to allow groups of users to access the account.
7. Users can access the SaaS app account credentials as we saw above.

Once the account is checked back in, the password is rotated and the new password is passed back via the sync to Okta. This is then applied to the application via the OIN integration.

Managing the Service Accounts

The steps on the Okta side and the integration between Okta and OPA are new to this feature. You can interact with the Service Accounts page to manage the accounts from the Okta end (3 in the diagram above).

You can also access the Resource assignment page in the OPA console to see the accounts that have been sync’d but not yet assigned to a Resource Group and Project (4 in the diagram above).

Once an account has been assigned, the rest of OPA similar to managing other resources.

Roles, Resource Groups and Policies

Once an account has been assigned, the rest of OPA similar to managing other resources.

As for all access in OPA, users are assigned to the OPA app in Okta and groups are pushed from Okta to OPA. These groups are assigned to admin roles and are also principals (the subjects) of policies.

The SaaS accounts are a unique resource type in OPA. So within a Project there are different tabs. You can see the accounts assigned to the project, the currently checked out accounts and the settings that apply the the accounts (5 in the diagram above).

The settings for SaaS accounts are: password strength, password rotation interval and checkout time.

Policies are the same for other resource types, but the rules are unique to SaaS accounts. OPA will know whether an account is automated or not, so you can’t have both in a rule. You select either Automated or Manual, and then select the accounts (of the selected update method) to include in this policy (6 in the diagram above).

Then you need to select any conditions that apply to accessing the credentials. You can have one or more of Approval requests, MFA and a Maximum Checkout time (overriding the setting in the project) if you wanted a unique time for these users in this policy rule.

As always, the policy must be enabled for users to access resources.

System Log Entries

It is worth mentioning the system log. Activity within OPA is reflected in events in the Okta system log.

The following shows the activity of our user Wendy above.

Looking at the events from bottom (oldest) up, you can see:

• Wendy authenticating into the OPA app
• Checking out the SFDC Shared Admin account and revealing the password
• Checking in the SFDC Shared Admin account
• The automatic password rotation for that account being kicked off in response to the check in
• Password rotation completed
• The new password being pushed from Okta via the OIN app to the application

As with all system log events, there is more detail contained in the event that may be useful. You could write Workflows to respond to certain events and perhaps send emails/chat messages or log a ticket. Perhaps you might want to generate an Access Certification campaign in OIG in response to a specific PAM event (“what else does this user have access to when getting access to a privileged account”). All of this is possible leveraging other capabilities from Okta.

Conclusion

Controlling access to privileged accounts in SaaS apps is a concern for everyone. Whilst some privileged access may involve federated accounts where you can manage entitlements dynamically through an IGA solution, many SaaS apps still have non-federated accounts that require a username and password to access. With the SaaS Service Accounts feature, Okta has brought those accounts into OPA and subject to the same controls as other privileged resources.

This article has provided an introduction to the SaaS Service Accounts feature, providing an overview and then walking through the user experience and the mechanics of it.

For more information see:

• The OPA Product Hub has a Secure SaaS Service Accounts Admin Guide that walks through the configuration of the feature.
• The OPA Product Hub also has an OPA Getting Started Guide that includes a section on Exploring Okta and SaaS Service Accounts.
• Managing and Using Okta Shared Accounts with Okta Privileged Access looking at the Okta app as a SaaS service.