IAmDavid

Author: iamdavid

  • Implementing an Offline Password Vault with Okta Privileged Access and KeePassXC

    Okta Privileged Access is a SaaS offering. Currently it does not have an offline mode for local storage of break glass credentials. But you can extend it to do so, and that’s the subject of this article. We look at a simple mechanism to export secrets from a folder and push them into a local vault (in this case KeePassXC, an open source password manager). The article will provide an overview of the solution, dive into the mechanics of the components for those interested in building something similar, then discuss some of the security implications of this type of solution.

    Introduction

    Okta Privileged Access (OPA) can be used in many privileged access management scenarios, including storing break glass accounts and their credentials. These accounts can be stored in Secrets in OPA, and then policy applied to control who can access them and how – such as requiring MFA to access. Okta Identity Governance can be layered over it so that access to secrets can be transient and auditable.

    OPA is a Software-as-a-Service implementation built on Okta’s cell architecture and subject to 99.99% SLA. But what if your internet connectivity is down and you need to access break glass accounts stored in OPA? Currently there is no offline mode for OPA, but there’s no reason you couldn’t implement your own.

    This article will walk through a simple implementation of an offline mode to store break glass accounts in a local password vault. For this example we have chosen the open source KeePassXC as the local vault. The solution components are shown in the following figure.

    Okta Privileged Access has it’s Vault with secrets stored in folders. It also has the usual collection of users, groups, admin roles, resource groups/projects and policies/rules.

    The “local” components are stored on an Ubuntu Desktop machine. This machine has the OPA Client (sft) with a user enrolled on the machine who has permissions in OPA to access secrets (in specific folders).

    The local machine also has KeePassXC installed, which includes the command line interface (keepassxc-cli), a database for the break glass passwords (entries) and the UI for accessing the passwords.

    Finally, there is a custom script to use the sft client to get the relevant secrets and add/update them in the KeePassXC database. As you will see in the following sections, this is all very straightforward (but has some limitations).

    This is a one-way solution – the secrets are pulled from the OPA Vault and written into the KeePassXC DB. It will add/update items in KeePassXC, but not delete them.

    This solution only works on credentials stored as Secrets in the OPA Vault. It will not work on server shared accounts or SaaS Service Accounts as there is no way to reveal these credentials via the OPA client (or API). This means it’s ideally suited to only the break glass accounts – the “I’ve got no other option, I need to get at the account that will get me into the system to fix things” option.

    Implementation

    This section will drill into the details of the implementation.

    KeePassXC

    The most up-to-date version of KeePassXC was installed on the Ubuntu desktop. Note that the Ubuntu 22.04 instance we used had some challenges with self-signed certs with the default installation mechanisms. In the end we used “sudo apt install keepassxc”.

    We created a local key file and a new database (BreakGlass.kdbx) using command line tools. This means that the database could be accessed using the local key file and not a password, making it easier to use in a script.

    openssl rand -out keepass.keyx 256
keepassxc-cli db-create --set-key-file keepass.keyx Passwords.kdbx
keepassxc-cli db-info Passwords.kdbx --key-file keepass.keyx --no-password

    Then to access the database via the UI, the key file is used instead of a password.

    Within KeePass there is a single folder called Passwords. You could have multiple folders and have different names, but this was the default when the database was created and the export script is coded to work with a single folder.

    Secrets in Okta Privileged Access

    In OPA, a single top-level folder was created in it’s own Resource Group and Project. The single top-level folder was chosen for simplicity. You could have a hierarchy of folders for the break glass accounts, but the export script was written to process a single folder.

    The single folder has a number of break glass accounts in it.

    Each secret has three values: username, password and url. The export script will look for those three key names.

    The URL is not strictly necessary, but KeePassXC has the ability to use the URL to connect to it with the credentials, so it’s included to show it getting added to the DB.

    The Export Script

    A simple Bash script was written to pull the secrets from the OPA folder and write (add or update) into the KeePassXC DB.

    The script is just a simple example of how it could be done and we expect there are much better ways to script it. Consider it as a way to show the commands needed to pull secrets from OPA and write them into KeePassXC.

    The high-level flow is:

    1. A set of variables are defined for the OPA Resource Group, Project and Folder where the secrets are stored.
    2. The OPA Client (sft) is used to get all secrets in the folder and write them to a temporary file
    3. Each secret in the file (each on a line) is processed in a function that will
      • Extract the secret ID and name from the line
      • Use the sft client to get the key:value pairs from the secret and store the username, password and url
      • Check to see if there’s already an entry in the KeePassXC DB for that secret and set the verb accordingly (“add” or “edit”). We could have put the next CLI command in the loop.
      • Use the KeePassXC CLI to add/update the password entry in the DB
    4. The temporary files are deleted

    We will explore the different CLI commands used in the following sections.

    Using the OPA Client to get the Secrets

    The OPA client, sft, is a command line utility, often used for command-line connections to servers. However with the secrets capability added to OPA, a number of sft secrets options were added.

    The export script uses two of these – one to list all secrets in a folder and one to reveal the key:value pairs of a secret.

    These are restricted commands so will prompt the person executing the script to authenticate to Okta/OPA. If MFA is assigned to the OPA app, they will also need to respond to the MFA prompts. The user will only need to authenticate once. As there is no unattended mode (to be addressed with NHI work this year) the script must be run by a user authorized to access the secret folder and reveal the secrets.

    The first call uses the sft secrets list command telling it what the resource group, project and folder id are.

    sft secrets list --id $bg_id --resource-group $bg_rg --project $bg_pr | grep -v '^NAME' > ./temp_secrets.txt

    The result is a tabular display with a header row. The command above removes that header and writes the output to a temporary file. The output of this command looks like the following, showing name, the secret id, RG & Project, and description.

    TestBG1 key_value_secret 5aa64709-62dc-4eab-b728-a293965d5a03 BreakGlass_Secrets_RG BreakGlass_Secrets_Proj Test BreakGlass Account 1
AnotherBG key_value_secret 79d4deb6-996b-4742-aee4-71212f3c4379 BreakGlass_Secrets_RG BreakGlass_Secrets_Proj Another break glass account
TestBG2 key_value_secret eabfcc85-360a-4477-95f7-62b0652b2bcd BreakGlass_Secrets_RG BreakGlass_Secrets_Proj Test BreakGlass Account 2

    The script will strip out the name and secret id from the list and then use the sft secrets reveal command to get the key:value pairs.

    sft secrets reveal --resource-group $bg_rg --project $bg_pr --id $secret_id > ./temp_secretvals.txt

    This results in a tabular output with the key:value pairs.

    KEY_NAME SECRET_VALUE
    username testacct2
    password Fred1234
    url https://okta.com

    The values from the secret and key:value pairs are stored in variables to use with the KeePassXC CLI.

    Adding/Updating Passwords in KeePassXC

    KeePassXC also has a command line interface that’s installed with the product, keepassxc-cli.

    We saw earlier how it can be used to define databases. It can also be used to show, add and edit entries, which we use in the script.

    As there’s no CLI to add/update in the one command, we need to check to see if the entry is there first, using the keepassxc-cli show command.

    keepassxc-cli show -k keepass.keyx --no-password BreakGlass.kdbx $secret_name

    Note that we’re using the key file with a –no-password option meaning the person running the script does not need to enter in the KeePassXC DB password for every execution of a CLI command.

    If the entry (by name) is found a verb variable is set to “edit” (i.e. edit an existing entry) otherwise it is set to “add” (i.e. add a new entry).

    Then a second cli command is run to add/edit the entry.

    echo $secret_password | keepassxc-cli $keepass_verb -k keepass.keyx --no-password -u $secret_username --url $secret_url -p BreakGlass.kdbx $secret_name

    The existing password from OPA needs to be piped into the cli command, otherwise it will prompt for it to be entered which is not what we want.

    At the completion of the script, you can see the three secrets now showing in the Passwords folder in the KeePassXC DB.

    Each entry is based off the secret name in OPA, with the username, URL and password stored. You could apply KeePassXC controls to restrict access to the entries. Note that there is a Notes field – it would be nice to copy the OPA secret description into this field, but there’s no argument to pass to the cli for this.

    So that’s it, a simple script to export secrets from a folder in OPA and create/update entries in a KeePassXC database to use as an offline store of break glass accounts.

    A Few Thoughts on Security

    Break glass accounts will normally be static, high-privilege accounts needed to fix something when all other means have failed. They should be used only in exceptional circumstances and should be managed with the utmost care.

    If you have reached this point of the article, you would have seen usernames and passwords displayed in the clear, and that is a concern for break glass accounts. The following are some thoughts about applying better controls.

    First is the choice of implementation. By using the OPA client (sft) you will export secret values in the clear as that is how the sft secrets reveal command is delivered. Unfortunately when handing off between one command (like the sft command) and another (like the keepassxc-cli command) you will need to pass a password value. If it’s in a script, it may be visible. A better design would be to use compiled code with relevant API calls so passwords are better controlled.

    This implementation is built on a single users workstation. It relies on an sft client being installed and enrolled for a specific user on a specific workstation. That user will also be tied to a group that controls the access to the secret folder and secrets. They will also need to authenticate to Okta/OPA when they run the script (preferably with MFA). So there are multiple layers of controls. If implementing a solution like this you should consider how widely you deploy it – ideally keeping it to one or two people that are highly trusted.

    The Okta/OPA implementation has a separate top-level secrets folder in it’s own Resource Group and Project. This keeps it away from other secrets folders and users. You should apply delegated administration to this RG and minimise the users who can access. Similarly a separate Policy should be applied to a tightly controlled group of users (with governance controls wrapped around the group membership) who can access the secrets. MFA should be used.

    In this example implementation, the script, key file and KeePassXC DB files are stored in a single directory on the users workstation. This directory should be hardened so only the authorized user can access it.

    The script does use temporary files to store the list of secrets and then the key:value pairs for each one. This was done to keep the script simple. If implementing something based off this, you should think of a better (in-script/in-memory) way of processing the data extracted from OPA.

    The keepassxc-cli commands are using a key file to reduce the need for the user to type in a password every time they run the script. This is a better approach than using passwords, but this file should be secured as effectively as the actual database.

    Finally, this script has been written to run interactively by a user. The OPA client requires this as it will need to authenticate the user. It cannot run on a schedule in the background. When the NHI capabilities are added to OPA, it may be feasible to run this automatically in the background.

    Conclusion

    In this article we have presented an example of implementing an offline vault for storing break glass accounts, and a means to synchronise secrets from Okta Privileged Access into a local vault. The vault used is KeePassXC, an open source password manager that can run on many platforms. The article provided an overview of the mechanism then walked through how the components were implemented, how the OPA and KeePassXC CLIs were used in a script to copy secrets across and ended with some security considerations for a solution like this.

    The article has shown that whilst there is no native offline vaulting capability in OPA, it’s very straightforward to implement one. If you’re concerned that OPA being a SaaS app and the internet may not be available, it provides a means to mitigate that risk.

  • Importing Entitlements for Disconnected Apps in OIG

    Okta recently introduced a new feature into Okta Identity Governance for importing users and entitlements for disconnected apps via a CSV import. This article explores the new feature.

    Introduction

    Okta has had the ability to import users via a CSV file for a long time. This has been an effective way to bulk load users without having to resort to programmatic means.

    With the introduction of Entitlement Management with Okta Identity Governance (OIG), users can be associated with fine-grained app-level entitlements such as Roles and Licenses. Many of the Okta Integration Network apps have been extended to import entitlements and entitlement assignments.

    But what about governance for disconnected apps, apps that aren’t defined in Okta? You can create these app definitions in Okta, but up to now you would need to manually assign users and their entitlements to them.

    This new feature extends the existing Import from CSV functionality to include entitlements. An imported CSV file will be scanned to determine the complete set entitlements and values and create them against the application. Then it will consume all the user-entitlement assignments and define them in Okta. This means you can see which users are assigned to what assignments, and run access certification campaigns against those assignments (potentially highlighting entitlements to be manually removed in the app).

    This article walks through the configuration, building and importing a CSV file, and running an access certification campaign against the entitlements.

    Configuration

    Let’s walk through the Okta configuration to consume a CSV file.

    Step 0 – Enable the Feature

    At the time of writing this article, this feature is in Early Access and needs to be enabled in the Settings > Features section of the Okta Admin Console.

    Step 1 – Create New App Instance in Okta

    You will need an app definition that supports provisioning to represent the disconnected app. See the list of Supported applications for Entitlement Management. You will want to create an app with one of the Template Apps, such as a SCIM app (it will be a dummy app, there is no provisioning plumbing connected to it).

    For this example we created a SCIM 2.0 Test App (Basic Auth) with SWA for Sign on and no sign on URLs specified.

    By default the app will have a single app user profile value – username (mapped to the Okta username).

    Step 2 – Define additional app user profile attributes

    Your app may have additional attributes you want to store in Okta and sync with Okta user profile values. You may want to use these values if creating a new user in Okta when you import the CSV. You may also want to use them to provide more information about the user, such as when reviewing access in Access Certification.

    Use the Profile Editor to add attributes to the app user profile. In this example, we have added three: First Name, Last Name and email.

    With the attributes defined, you can map them to the appropriate Okta User profile attributes.

    Step 3 – Enable the Governance Engine (Identity Governance)

    To allow visibility and management of app entitlements, the Governance Engine must be enabled for the disconnected app. This is done on the General tab of the app in the Identity Governance section.

    It may take a few minutes for the Governance Engine to be enabled. Once this is done, you can start looking at the CSV file.

    Importing a CSV File

    To import a CSV you can download a template file with the required user attributes or build one from scratch, then import it and check the results. We will walk through the process using the downloaded template.

    Step 1 – Download the CSV Template

    A CSV Template is available with the app user profile attributes pre-populated. If you have set up the attributes as above, the following steps will have them as columns in the CSV.

    Go to the app instance and the Import tab. Click on the Import from CSV button.

    On the Import Users from CSV dialog, click the CSV Template link to download the CSV file.

    You can Cancel the dialog and go edit the file, or leave it open to come back to.

    Step 2 – Fill in the CSV File

    If you open the downloaded template file, you will see that it contains a single row, the attributes to be populated.

    Username,First Name,Last Name,email,ent_Entitlement1,ent_Entitlement2

    There are three sets of values:

    • The Username,

    • The app user profile attributes you added in the Profile Editor (in or case First Name, Last Name and email), and

    • Two dummy entitlements, Entitlement1 and Entitlement2 (both prefixed with ent_)

    See the User entitlement CSV guidelines for entering data into the file. Some key points:

    • All entitlements must be prefixed by ent_, so in the standard template you have two entitlements (Entitlement1 and Entitlement2)

    • Multiple values are entered in quotes

    • You can have null values by using ,, or ,"",

    Also note that this mechanism only supports full imports. So your CSV file for a disconnected app is the master set of users and their entitlements.

    The following CSV file was used. It contains two users and three entitlements (Role, Lic and Scope). Each entitlement could have multiple values.

    Username,First Name,Last Name,email,ent_Role,ent_Lic,ent_Scope
    paula.partner@atko.email,Paula,Partner,paula.partner@atko.email,"Admin","Publishing,Admin","Prod,QA,Dev"
    peter.partner@atko.email,Peter,Partner,peter.partner@atko.email,"Editor,Writer","Publishing",Prod

    Step 3 – Import the CSV File

    Return to the Import Users from CSV dialog, enter the file name and click the Upload CSV button.

    This will upload the file and perform a syntax check of the contents. You will get errors if the file is improperly formatted. Otherwise it will give you the results of the parsing.

    Click the Import Users button. Once it has imported you are presented with the normal user match screen for an import. Review user mappings and select the users to import. Click the Confirm Assignments button to import the selected users. where you can define whether to match existing users in Okta.

    The import process is now complete.

    Viewing the Results of the Import

    With the file successfully imported, you can confirm the upload. First you can go to the Governance tab for the disconnected app and look at the Entitlements.

    In this example we have three entitlements Lic, Role and Scope (sorted alphabetically, not how they were in the file). And each has the values specified in the file.

    As with any entitlements on apps, you could create Bundles for requesting access or policy for default assignment. But note that there is no plumbing behind the app instance to push any changes to the app (you could potentially build something with SCIM or Workflows).

    Next if you return to the app and look at the Assignments, you will see the users from the file.

    In this example you can see the two users from the import file – Paula Partner and Peter Partner. Selecting the more icon and selecting the View access details action will show the entitlements for this user.

    In this example, Paula has two licenses (Admin and Publishing), one role (Admin) and three scopes (Dev, Prod and QA). This corresponds with entry in the file shown above.

    Access Certification

    With the entitlements assigned to users in the disconnected app, you can run access certification campaigns against them.

    The campaign is a standard Resource Campaign for the disconnected app and all entitlements enabled.

    Note that remediation is disabled for the review. You could set it to remove access when the reviewer clicks the revokes button, but as there’s no integration (plumbing) behind the app instance, it won’t make any changes to the target system. You could setup Workflows to react to the system log events to trigger a process to remove the access in the app and modify the import CSV.

    The review is as for any resource with entitlements review. Clicking a row will open a slide-out window with more details including the entitlement and the other entitlements the user has for context.

    As for every other campaign, the reviewer would progress through the reviews and approve, revoke or reassign them.

    Conclusion

    In this article we have explored the ability to import users and entitlements for disconnected apps into Okta via a CSV file. We have looked at the configuration of the app; how to download, fillout and import the CSV file; how to verify the import was successful; and how to run an access certification campaign against the disconnected app.

    This mechanism greatly expands the reach of Okta Identity Governance. No longer are you limited to apps defined in Okta. You can run governance controls for disconnected apps and have a single place to audit activity.

  • 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:

  • An Introduction to Resource Collections in OIG

    This article introduces the new Resource Collections feature in Okta Identity Governance, looking at how collections are defined, requested and reviewed.

    Introduction

    Okta has introduced a new feature into Okta Identity Governance (OIG) called Resource Collections (or sometimes referred to as just Collections).

    They are a way to define a role that spans different entitlements across different applications. Prior to collections, you would need discrete Entitlement Bundles for each application. Let’s say you had a media role that required access to Salesforce, Google and some Physical Building locations, and each had discrete entitlements needed for that role. Before, you would need to create a bundle for each of Salesforce, Google and the Physical Access app. With Resource Collections you can create a single collection (role) that can be requested.

    In this article we will look at the new feature, how to define the collections and how to use them. The article assumes some familiarity with OIG, access requests and access certification.

    Note that this feature is in Early Access at the time of writing. There is some additional functionality planned for this feature soon after it becomes Generally Available (GA), so what you see in your environment may be slightly different to what’s in this article, depending on when you view it.

    Creating a Resource Collection

    As the new feature is in early access, you need to enable it via the Settings > Features menu item. This is for customers that have the OIG product.

    The need to enable it will go away when the feature becomes Generally Available.

    Once enabled, you will see a new menu item under Identity Governance called Resource Collections.

    Creating a new collection is straightforward – click the button, give it a name and a description.

    Then you assign Resources to it, where resources are apps and their entitlements.

    The new collection is now ready to use. An administrator can manually assign users, or an Access Request condition can be created for it.

    Requesting Access to a Resource Collection

    This new feature leverages the new Access Request conditions mechanism in OIG. This is the same that is used for application entitlement bundles and groups associated with applications.

    An Access Request will consist of a Condition associated with the resource and the condition will call a Sequence for the flexible flow portion of the access request. For application-specific access, the Condition is tied to the application. For resource collections, the condition is tied to the condition.

    Additional articles on Access Request Conditions include:

    Creating an Access Request

    A condition can be created under the Access requests tab for the collection.

    The condition, and associated sequence are managed in exactly the same way as a condition associated with an application.

    In this example, there is a single condition for everyone, with the Single Approval – Manager sequence. Let’s walk through a user example.

    Requesting Access

    A user selects the Request Access button on their Okta Dashboard to see what they can request access to. In this case they see the new collection “Marketing – Media”.

    Selecting this shows the apps in the collection and requires a Business Justification to be supplied.

    When the request is submitted, an access request is raised and the reviewer (in this case the user’s manager) gets and email to tell them there is a request to review. They access the request to see the request for the collection.

    They can use the Details tab to see the apps covered by the request.

    When it is approved and the user returns to their Dashboard, they will see the apps associated with the collection.

    An administrator can view the entitlements associated with each app for the user in the Admin Console.

    The administrator can also see all of the users assigned to the collection under the Assignments tab for the collection.

    The administrator can manually assign users. They can also edit the expiration of the access or unassign a user from the collection.

    Recertifying a Resource Collection

    In the Early Access release, you can run Resource Campaigns that will highlight when an entitlement has been granted via a collection. The following shows a campaign run across the apps and entitlements covered by the collection.

    Selecting a user and entitlement row will show if it was assigned via a collection.

    As a collection could represent a complex mix of apps and entitlements, any Revoke action on a review will be flagged for manual remediation.

    Expect the access certification capabilities for collections to be enhanced post GA.

    Conclusion

    The new resource collections feature allows definition of cross-application roles within Okta Identity Governance. It builds on the Entitlements Management and Resource Catalog and Access Request features introduced into OIG last year, to provide a more comprehensive approach to governing access through the request and review processes.

  • Preconfigured Access Certification Campaigns in Okta Identity Governance

    The Access Certifications capability has been a core part of Okta Identity Governance (OIG) since its inception. However in the first update for this year (2025.01.0), Preconfigured Access Certifications Campaigns were added to OIG. This article explores the new feature.

    Overview

    Building of access certification campaigns is very straightforward. The wizard-like flow walks you through the steps to define the resources and users, the reviewers, how the campaign is to run and how to respond to a revoke action. It has been extended over the years for additional functionality, such as multiple levels of review, entitlements and UARs.

    So what’s new? Some of the options for specific use cases have been “templatized” to make them easier to create and run.

    When exploring Access Certifications under the Identity Governance menu item in the Okta Administration Console, you may notice a new tab called Preconfigured campaigns.

    There are currently two preconfigured campaigns: Discover inactive users, and Okta administrator review. We will explore each of these.

    Discover inactive users

    This campaign will “identify and manage users who have been inactive for more than 90 days in the top five apps with the most inactive users”. It is not looking at all apps for all users, just the big hitters. The example above shows the top five apps with the most inactive users in my test system.

    When the Create campaign button is used, the campaign details are pre-filled. You are not walked through the creation steps, but you can go back and modify them.

    There is some background work that Okta has done to determine the top five apps with the most inactive users in your Org. You have no control over this (although you could change the app list in the campaign, it’s just that OIG has determined the biggest ones).

    There is a Predefined user scope to restrict the users to “No recent activity” within the last 90 days.

    This is a standard option for Access Certification campaigns. You could apply this scope to any resource campaign.

    The campaign defaults to the administrator who built the campaign. It also takes no remediation action on a revoke or no response at campaign end.

    As for any other campaigns, you can Schedule and (optionally) Launch it. It appears in the reviewers list of Open campaigns.

    The campaign will show all users, with the standard options to Approve, Revoke and Reassign.

    Clicking a user reveals the slide-out panel with the details of the user and resource (in this case the app).

    The reviewer can see details about when the user was assigned to the app, last access date and application usage to help them decide if they need to retain access.

    Okta administrator review

    The Okta administrator review campaign will “ensure users have the correct admin roles and identify users who may no longer need admin access based on activity.”. This is a powerful tool to help reduce the administrative privileges in Okta (see also Reduce Risk Through Governance for Okta Administrators).

    This type of campaign has been available since the Govern Admin Roles feature was released in Okta (see A Look at the new Govern Admin Roles feature), this update has made it a template for easier use.

    The Resources scope is looking at the Admin Console app and the entitlements (i.e. Admin Roles) associated with it.

    The Users scope is all users assigned to the selected resources (i.e. the Admin Console app). As with the other preconfigured campaign, it is assigned to the administrator creating it (but they will be automatically excluded) and there are no remediation actions taken.

    The review shows all admins (except the requester) and the Admin Roles they have.

    Selecting a user produces the slide-out window with more detials.

    You can see the specific entitlement (Admin Role) but also the other active entitlements for the user in one place. This provides a simple view of what that admin can access and the reviewer can decide what (if any) they should retain.

    Bonus Integration

    In addition to be able to create campaigns off the two templates, the Inactive Users capability is integrated with the applications view.

    In the above example, when looking at the AWS IAM Identity Center application, there is a widget showing the number of inactive users for the last 90 days, with a button to create a campaign off it. The campaign will be scoped to only the selected app.

    Conclusion

    The new Preconfigured campaign feature provides for templates to simplify creation of campaigns. The two templates provided, Discover inactive users and Okta administrator review, can be created manually (although the first would require knowing which apps have the most inactive users).

    The new feature has made it easier to generate these campaigns, which may mean organisations run them more often and use them to reduce the number of inactive users and users with unnecessary admin access, leading to a more secure environment.

  • Automating Individual Secret Folders in OPA with Workflows

    Okta Privileged Access has a secrets function, where a folder hierarchy can be built and policies applied to allow groups of users to access shared secrets. Whilst it’s not it’s primary use case, it could also be used to provide an individual secrets folder mechanism where users in Okta could have their own personal secrets folder.

    This article explores how automation, with Okta Workflows, could be used to simplify creation of folders and associated policies for this.

    For more information on secrets and the APIs you can see Using the Secrets API with Okta Privileged Access. However that article is focused on accessing secrets with APIs, with a bit of info on Folder management, and nothing on the policies/rules involved.

    Introduction

    One of the primary use cases for Okta Privileged Access (OPA) is secrets management, with credentials stored in the OPA vault. A hierarchy of secret folders can be defined, with policy applied at different levels of the folder tree to grant permissions to manage or access the secrets. For example, you might have departmental high-level folders with a small group of departmental admins managing them, but team-specific folders under that with a local administration group allowed to administer the folder and secrets, and a group of users who can access the secrets therein. You might have an IT department top-level folder managed by an IT dept admin group, then folders for DBA, Web, App Server etc. each with their own admins and users.

    This approach is suitable for a structured organisation. But could it be applied to personal folders for personal secrets? Yes, but the challenge is the creation and maintenance of the individual folders, the individual (personal) groups to access them and the policies and rules to control access into the folders. This is where the OPA API comes in. You can automate the creation and destruction of these objects programmatically using the APi and some programming language.

    In this article we walk through the creation of the various objects for personal folders using Okta Workflows. In the following example there is a main flow and a set of sub flows that will:

    1. Be passed an Okta username, validate that user in Okta, validate they are assigned to the Okta Privileged Access app in Okta (and if not, assign them), then validate the user is in OPA itself
    2. Create an OPA group for that user and assign the user to it in OPA
    3. Create a folder for that user under a common “individual folders” top-level folder in OPA
    4. Create a policy and rule that allows that OPA group to access that OPA folder with all folder/secret permissions

    The details of each workflow will be described later. However many call the relevant OPA APIs directly with the Custom API Action card on the Okta Privileged Access connector in Workflows. This is because the connector does not have action cards for all of the admin API functions needed for this use case.

    The Outcome

    Lets start with the end result of the flow. It has been built to consume an Okta username. It was built that way to show the flow, but could be structured to consume a list of usernames (such as in a CSV file).

    When the flow completes, the user will see the okta Privileged Access tile on their Dashboard (if they didn’t beforehand).

    Selecting the tile, they are taken to the Okta Privileged Access UI with the functions that they can access. In this case they are not an administrator so they only see the MY PRIVILEGED ACCESS menu items. Under the Secrets menu item, they see a single folder named <username>-Folder (which is under the Individual_Secret_Folders top-level folder, but they can’t access that).

    Within that folder, they can create (and manage) both folders and secrets.

    They could create (and manage) their own folder hierarchy within their -Individual folder. They could also create (and manage) secrets anywhere in that hierarchy.

    Once a secret is created, they can reveal the values at any time they want. In this case as they are personal secrets, the policy rule does not enforce MFA or access approval conditions on the reveal (you could build them into the workflow that defines the policy).

    Thus the user has their own personal folder in the vault for storing their personal secrets. This was all done by one execution of a workflow.

    The Workflows that Implement this Automation

    This section will walk through the configuration of the solution.

    Environment Setup

    The following was configured in the environment for the workflows to function.

    In Okta Workflows, both an Okta connector and an Okta Privileged Access connector were created to the local Okta/OPA.

    In OPA, a new Resource Group and Project were created.

    A top-level folder called “Individual-Secrets” was created in that Resource Group/Project.

    Finally the Service User that the OPA connector uses was assigned to a group and that group assigned to a policy to allow the Workflows to create folders in that top-level folder AND be able to create policies and rules. In this case there is a policy assigned to the Individual-Secrets folder that allows the folder permissions on that folder and any sub-folders, but not the ability to manage or reveal secrets.

    This implies that this user could manage folders within the individual folders the workflow will create. You could apply a deny-type policy rule for this workflows service user once you created the folder and policy, but then workflows could not clean up after the user no longer needs a personal folder. Of course a super administrator can change the policies. You should focus on policy design if implementing a mechanism like this. It can’t be bulletproof as you still need superadmins, but you could wrap other controls around the use of superadmin accounts.

    Overview of the Flows

    There are five flows in the solution, a main flow and four subflows called from the main flow.

    Lets walk through them. Note that the flows do not contain a lot of fault handling – consider them proofs-of-concept and you would need to make them more resilient in production.

    M00 – The Main Flow

    The main flow (M00 – Create Individual Folder) is the high-level flow that prompts for an Okta username.

    It will setup some fixed arguments for the top-level folder (RG ID, Project ID and Folder ID) and the OPA application ID (in Okta). All of these could be dynamically discovered using APIs and actions in Workflows, but this shortcut was chosen. These values do not change across executions of the workflow (all individual folders would be stored in the one top-level folder).

    Next it checks that the user is a valid Okta user, returning some user profile attributes like first and last names.

    It calls a subflow (M10) to verify that the user is assigned to the OPA app in Okta and if not, it assigns them.

    The next card (Compose) builds the OPA username from the firstname and lastname. Again this could be done programmatically by looking at the user app profile for that user on the OPA app, but we are simplifying for this example. The default configuration of OPA has a firstname.lastname format.

    The username is converted to lowercase as most of the OPA APIs are case-sensitive and usernames in OPA are lowercase.

    The OPA Connector Find Users action is used to verify that this user is in OPA. It will return the number of found users. In this case it will only continue the flow if exactly one user is found.

    The rest of the flow calls subflows to create an OPA group for that user (M20), create a folder for that user (M30) and create a policy to allow the user to manage their folder and secrets (M40).

    The M20 and M30 flows return the Group and Folder IDs that are used in the M40 flow.

    M10 – To Check the Okta User

    This flow is passed the Okta user ID and OPA app ID from the main flow. It will try (inside a try/if error function) to find the user in the app using the Okta Get Assigned User for Application card.

    If the call fails, it checks if it’s a 404 and if so assigns the user to the app using an Okta Assign User to Application for SSO And Provisioning card.

    It has a 30 second delay built in to allow the provisioning of the new user from Okta to OPA.

    M20 – To Create an Individual Group in OPA

    The M20 flow has two parts. The first part will define a group name (<username>-Individual) and then use the Create a Group API to create it in OPA.

    The second part uses the Add a User to a Group API to assign the user. Note that this API requires the OPA username NOT the ID.

    It returns the ID of the new group to the calling flow.

    M30 – To Create an Individual Folder in OPA

    This flow creates an individual folder in the top-level folder. It is passed the IDs of the resource group, project and top-level folder as well as the username.

    Three compose cards build: The foldername (<username>-Folder), a description for the folder and the URL for the API.

    Then it uses the Create a Secret Folder API to create the folder in OPA.

    It returns the ID of the new folder to the calling flow.

    M40 – To Create a Policy with Rule for the Folder and Group

    This last flow will run a single API, the Create a Security Policy API, to create the policy with rule and assign it to both the user group and the folder. Note that the product docs do not currently contain an example of creating a policy w/rule for a secret folder.

    This API requires a fairly complex Body object to be passed to it. like the following:

    {
  "rules": [
    {
      "privileges": [
        {
          "privilege_type": "secret",
          "privilege_value": {
            "secret_create": true,
            "_type": "secret",
            "secret_update": true,
            "folder_delete": true,
            "secret_delete": true,
            "folder_update": true,
            "secret_reveal": true,
            "folder_create": true,
            "list": true
          }
        }
      ],
      "resource_type": "secret_based_resource",
      "resource_selector": {
        "selectors": [
          {
            "selector_type": "secret_folder",
            "selector": {
              "secret_folder": {
                "id": "4693e3b6-913f-4ffd-93eb-67d5da04073c",
                "type": "secret_folder"
              },
              "_type": "secret_folder"
            }
          }
        ],
        "_type": "secret_based_resource"
      },
      "name": "Owner Folder Management"
    }
  ],
  "name": "nigel.newbie-Policy",
  "active": true,
  "principals": {
    "user_groups": [
      {
        "id": "d24608d0-988a-44be-8100-b0c31ad64c98"
      }
    ]
  },
  "description": "Policy to allow nigel.newbie full rights to their own secrets folder."
}

    It has a name and description, and a state of “active” (i.e. the policy will be enabled when created). It has two other top-level components:

    • principals – defining the id of the user group (i.e. the individual group created in M20).
    • rules – defining a single rule to allow all secret/folder permissions against the users folder (i.e. the individual folder created in M30).

    The flow comprises a series of Object Construct and List Construct cards to build up the privileges, rules and principals object in the complex structure required of the API.

    With the Body object main components built, it then defines a policy name and description, and wraps all of the fields into the Body object. It then calls the API to create the policy with rule.

    It does not return anything to the calling flow. If the API fails, the flow and calling flow will show the API error.

    This concludes the flows used to build this solution.

    Conclusion

    This article has provided an example of how Okta Workflows and the OPA APIs can be used to create a personal secrets folder for a user and the groups and policy to control access to that folder. It shows both the APIs to achieve this as well as how they could be structured into a flow with Workflows.

    This addresses the requirement for providing personal secrets management within the Okta Privileged Access vault, and alleviating the manual work required if this was to be done in the Okta Privileged Access UI.

  • Automating Realm Creation in Okta with Workflows

    The new Realms feature in the Okta Workforce platform and the Secure Partner Access (SPA) product built on top of it are designed to make management of discrete user populations simpler. Realms can be managed via the Okta Admin Console. But what about when you want to automate the process, such as onboarding a large number of partners. Okta provides various APIs for this, and some of them are baked into the Okta Realms Workflows connector.

    This article looks at how the APIs can be used in Workflows to automate the process of realm creation as well as all the objects related to realms, such as realm assignments, admin groups and admin resource sets.

    Introduction

    When working with realms there are some constructs you need to be familiar with:

    • Realms – the definition of the containers for storing user populations.

    • Realm assignments – rules to define which users are assigned to which realm, normally through some user profile attribute condition.

    • Administration roles – users need to be assigned to administration roles to be able to manage users in a realm. Roles define the scope of permissions (what object types and attributes can be managed by admins). There is a default role generated with the Secure Partner Access product called “Partner Admin” covering the standard set of permissions.

    • Administration resource sets – what objects and administrator can manage. Whereas roles define the “what a user can do”, resource sets define “what they can do it on”.

    • Administration groups and assignment – whilst you can assign users to a role+resource set combination, it’s cleaner to assign a group, then manage the group membership (perhaps with Okta Identity Governance)

    If you were to create a separate realm and set of related objects for Secure Partner Access, the flow would be similar to this:

    1. Create the Realm

    2. Create one or more Realm Assignments to define which users are assigned. You would enable it, and could rerun the assignment rules to move users into the realm.

    3. Create an administrators group and assign users to it.

    4. Create an administration role if the supplied one doesn’t cover what you want.

    5. Create an administration resource set for the new realm and it’s users, and optionally any groups or applications you wish to allow the realm admins to manage membership/assignment for.

    6. Assign the admin group to the role + resource set.

    7. Assign the admin group to the Secure Partner Access portal.

    Most of these steps are covered in the flow described below. Note the administration configuration for realms is explored in Assigning Administrators to Realms in Okta.

    Overview of the Flow

    The set of workflows built to implement this automation have a main flow and associated sub-flow and some utilities. The main flow in this case is a delegated flow, so it could be exposed to an administrator to enter the required attributes. Or you could have a main flow that reads a CSV file into a table then processes each record in turn.

    The overall flow is:

    1. Create a new realm

    2. Create a new realm assignment, including an assignment condition to put users into that realm (it does not activate or run the new rule – this can be done by an admin later)

    3. Create an admin group (it does not assign users – this can be done later)

    4. Build an administrator resource set for the realm and assign the admin group to the standard SPA role and new resource set

    5. Assign the admin group to the Partner Admin Portal so an admin can access the portal (from their Okta Dashboard) to manage users

    We will walk through the details later on, but most of the flows are leveraging Okta APIs, to manage Realms, Realm Assignments and get Org details. The Okta workflows connector is used to create the group and assign the group to the portal application. There is also an Okta Realms workflows connector, but it uses the earlier realms API that does not support SPA, so direct API calls (Custom API Actions) on the standard Okta connector were used as needed.

    Running the Flow

    Lets walk through the execution of the main flow.

    An administrator goes to the Delegated flows menu item and runs the flow.

    It prompts for the attributes (inputs) used in the flow.

    Most of these inputs are the labels for each of the objects that will be created.

    Of note is the Assignment Condition input. This is the condition that will assign users to the new realm. In this case it will select all users where the primary email field contains “deadwoods.com”. Note the escaping of quotes.

    When the flow runs, it will execute a number of sub flows.

    These follow the steps listed above. As a result of this, there is a new realm created.

    A new realm assignment is created.

    This has the condition entered earlier and will assign matching users to the new realm. Note that the status is INACTIVE. We could activate it in the relevant workflow, but you would probably want to review the new assignment rule in the context of the others and their priorities before activating.

    A new Okta group has been created and assigned to the Partner Admin Portal.

    The new admin group has been assigned to the combination of Partner Admin role (the default one with SPA) and the new resource set.

    If we look at that new resource set, we can see it is assigned two resources – the new realm itself and the users in that realm (none yet). It does not have any applications or groups assigned to the resource set.

    The realm, and realm-related objects, are ready to use. You could assign one or more users to the new group and they would automatically get the admin rights to manage the users in the realm. You could manually assign users to the realm, or activate the new realm assignment rule and have the users automatically assigned.

    As mentioned earlier, this flow has been built as a delegated flow to allow an administrator to run it from the Admin Console. But you could apply the same approach with reading a CSV with all the input fields into a table and processing each row.

    Details of the Flows

    The components in this include: a connection, a table, a main flow and some calling flows, and some utility flows.

    Connection

    You need to allow the relevant Okta API scopes in the Okta Workflows OAuth application.

    • okta.applications.manage

    • okta.groups.manage

    • okta.orgs.read

    • okta.realmAssignments.manage

    • okta.realmAssignments.read

    • okta.realms.manage

    • okta.realms.read

    Whilst the normal Okta connector can perform some of the operations needed, you need to set some customized scopes. So you either modify your existing connector or create a new one. You need customized scopes on the connector. You can leave the default scopes selected under Customzie scopes (advanced) or trim them down. You will need to manage groups, and application memberships. You will also need to add the following custom scopes:

    • okta.orgs.read

    • okta.realmAssignments.manage

    • okta.realmAssignments.read

    • okta.realms.manage

    • okta.realms.read

    With the connection authorised, all the operations in the flows can run.

    Table

    There is a single table called Env Vars. It has two columns, varname and varvalue.

    It needs to have a single row, with varname of “APIToken” and varvalue of the API token you setup in your org. This is used as authorization for each API call.

    Main Flow

    There is a single main flow that is called as a delegated flow.

    It prompts for the input fields shown earlier, then calls subflows to:

    1. Get’s the API token from the table as an authorization object for the API calls

    2. Get’s the org id from a simple API call as this is used in later flows

    3. Create a realm (M10 flow)

    4. Create a realm assignment (M20)

    5. Create an admin group (M30)

    6. Create an administration resource set, then assign the group to the SPA default role and this resource set (M40)

    7. Assign the admin group to the Partner Admin Portal (M50).

    We will explore these flows in the following sections.

    M10 Flow

    The first subflow will create the realm using the name passed into it and the realm API.

    The first two cards build the Body object for the API call. The body includes the name and the realmType fields. For the realm to be accessible in the Partner Admin Portal, the type must be “PARTNER”.

    {
   "profile": {
      "name": "Deadwoods Realm",
      "realmType": "PARTNER"
   }
}

    The new Realm ID is returned to the calling flow.

    M20 Flow

    The second subflow creates the assignment for the realm.

    It uses a simple compose card to build up the Body object then calls the API to create the assignment. The Body object could be built up out of a series of Object Construct cards, but that would have taken many cards and the body structure does not change.

    The Body object is shown below. It’s basically saying, for users where the condition is matched (in our example it’s where primary email profile attribute (user.profile.email) contains “a set string”deadwoods.com) then assign the user to the realm specified by realmId. Notice that there is a profileSourceId field set to the Okta org. Realm assignments allow specifying different identity sources (Okta profile or a directory integration).

    {
   "actions": {
      "assignUserToRealm": {
      "realmId": "Realm ID"
      }
   },
   "conditions": {
      "expression": {
         "value": "Assignment Condition"
         },
      "profileSourceId": "Org ID"
   },
   "name": "Assignment Name",
   "priority": 0
}

    You could set the priority here, but we’ve chosen to leave it for when an admin would review this assignment rule in the context of the others before activating.

    M30 Flow

    The third subflow creates an Okta group which will represent the administrators of this realm.

    It builds a description, creates the group using the standard connector card and returns the new group ID to the calling flow.

    M40 Flow

    There are multiple stages in the flow to assign the new admin group to the role + resource set.

    First, it searches for the SPA-generated “Partner Admin” role and gets the ID of it.

    Next it creates a new resource set for the new realm.

    It constructs strings to represent the description of the new resource set, and the two resources to go into the resource set. They use the ORN nomenclature to refer to the new realm and the users in the realm (including reference to the Realm ID and the Org ID).

    The two resource strings are put into a list and assigned to the body object. The API will then create the resource set.

    A sample body object is:

    {
  "description": "Resource set for users and realm Deadwoods Realm",
  "label": "Deadwoods Realm Resources",
  "resources": [
    "orn:oktapreview:directory:<orgid>:realms:<realmid>",
    "orn:oktapreview:directory:<orgid>:realms:<realmid>:users"
  ]
}

    Finally it assigns the group to the role + resource set combination.

    Note that the assignment is of type CUSTOM.

    Thus it has found the id of the role, created a new resource set and got the id of that, then assigned both (by ids) to the admin group.

    M50 Flow

    The final subflow assigns the new admin group to the portal app. It searches for the app, named “Partner Admin Portal”, then assigns the group to it.

    These are standard Okta connector card actions.

    Utility Flows

    The last two flows used are utility flows. One will pull the API Token from the Env Vars table, format an Authorization object from it and return that to the calling flow.

    The other will lookup the Org to get the org ID. This requires a Custom API Action as there are no standard actions for this on the Okta connector.

    The Org ID is returned to the calling flow.

    This concludes the exploration of the workflows in the solution.

    Conclusion

    The new Realms feature in Okta, and the Secure Partner Access product leveraging it, can be managed in the Okta Admin Console. But a partner scenario where partners may be onboarded in bulk or there is a steady flow of new partners, calls for some form of automation. Okta provides APIs to manage realms and their related objects for this purpose.

    This article has shown an example of how a set of workflows could be built to automate the creation of a realm, and related realm assignment rule, admin group, admin resource set and assignment to the role+resource set and portal app. This is a standard flow that is called as a delegated flow, but could be the basis of a more advanced mechanism (like reading from a CSV). The article explored each of the flows and who they use the relevant APIs. This should provide enough detail if you wanted to build your own.

  • Assigning Administrators to Realms in Okta

    Realms were introduced into Okta to provide an alternative mechanism for delegated administration with discrete user populations. A key aspect of this is the administration – you may need to have different types of administrator roles for the users in the realm, but also allow cross-realm roles. In this article we explore configuring administrators for realms.

    The article relates to both realms used for Secure Partner Access (SPA) and realms used within Okta for user management. Realms are currently only available with either the Secure Partner Access or Okta Identity Governance products.

    This article is part of a series of articles looking at Realms and Secure Partner Access. More articles can be found here.

    An Introduction to Roles, Resources, Administrators and Realms

    The new Realms feature leverages the existing Okta RBAC model, where Okta users are assigned administrative privileges based on roles and resources. Roles define the permission set and resources define what objects those permissions are applied to. You may have a role to manage users, and then a resource set to define the users that can be managed. That way you can have common reusable roles and use different resource sets to scope the access for different admins.

    This is shown in the following figure.

    To manage the realms and the users in the realms, admins can use the Okta Admin Console. If the new Secure Partner Access product is used, then its Partner Admin Portal can be used in addition to or instead of the Admin Console.

    You will need to have roles and resource sets assigned to admin users to allow administration of users in realms (with or without Secure Partner Access).

    In this article we will explore those admin constructs (Roles, Resources and Assignments) and how to configure the different admin UIs if Secure Partner Access is used.

    Roles

    Roles define the administrative permissions within Okta. Roles can range from all-powerful Super Administrator to more closely-scoped roles like Read-only Administrator and Report Administrator. For deployments that want more ganularity, custom rules can be defined using the palette of permissions provided within Okta. These can be used to manage realms.

    Custom Roles for Realms vs. The SPA-Generated Role

    Custom admin roles can be created to manage resources in Realms. If SPA is enabled, there is a custom role generated called Partner Admin.

    If you do not have SPA, you will need to create one or more custom roles. Even if you do use SPA, you may want to look at custom roles if the generated role does not meet your needs.

    Role Permissions

    When assigning permissions for a role related to realms, you need to consider: the realm, the users in the realm, and resource types that users may be associated with such as groups and apps (that are outside the realm).

    The default SPA Partner Access role provides a good baseline for realm role permissions.

    The User permissions in this role are:

    • Edit users’ lifecycle states

    • View users and their details (with conditions)

    • Edit users’ authenticator operations

    • Edit users’ profile attributes (with conditions)

    • Edit users’ application assignments

    • Create users

    • Edit users’ group membership

    These may be overly permissive for your environment so you may want to reduce the permissions in the role, or create a new custom role with less permissions.

    You an also restrict the user profile attributes that can be viewed and/or edited.

    The other permissions in the default role are:

    • Group
      • Manage group membership

      • View groups and their details

    • Realms
      • View realms and their details

    • Application
      • View application and their details

      • Edit application’s user assignments

    The realms permission is important to be able to see the realms and users within realms. The group and application permissions allow visibility into the resources, and assignment of the users to them, but not management of the resources themselves.

    With roles defined, you need to define the scope of those roles through resource sets and resources.

    Resources and Resource Sets

    Resources are the Okta objects you are restricting access to, like users and groups. Resource sets define logical grouping of resources. For example you may have a resource set that covers all users in a specific group and a set of applications. These are tied to roles to scope what resources the role permissions are applied to.

    Resource Sets for Realms

    With Realms, you may want to create a resource set for each realm, such as the example below where there are two resource sets, one for each realm.

    You might have resource sets across multiple realms, and there may be overlapping resource sets. They are just configurations to control who (admins) can do what (role permissions) on what (resources).

    Resources for Realms

    When working with realms, you would define resource sets that include:

    • Users – the users in the realm(s) you want to allow a set of admins to manage

    • Groups – the groups you may want to manage membership for those users

    • Applications – the applications you may want to manage membership for those users, and

    • Realms – the realms that this applies to (this is important)

    An example is shown below. It is focussed only on the “Atko Partner” realm. The users are limited to those in the “Atko Partner” realm. There are four groups and four applications that the assigned admin can manage membership for.

    This is just an example, and your resource sets may cover multiple realms, and may have different groups/apps assigned. You might have different resource sets for different sets of groups/apps across the same realm(s).

    Finally, the roles and resource sets must be assigned to users (admins).

    Assignments

    To grant permissions to any admin function in Okta, you need to associate a role (and possibly a permission set) to a user. This can be done individually or by group (where group membership would be preferred and the admin group membership managed with IGA controls). The following example will show individual admin assignment for simplicity.

    Admin assignments can be seen under the Admins tab. In this case the one user, Mike Manager, is assigned to two roles, Partner Realm Admin (a custom role) and Partner Admin (the SPA-generated role).

    These two roles could have different sets of permissions. When creating or managing role assignment, you can also associate a resource set. As we saw earlier, you create resource sets for realms.

    So in this case the user Mike has the Partner Realm Admin role with the Partner Realm resource set. He also has the (SPA-generated) Partner Admin role with the Atko Partner resource set. So, different sets of permissions on different sets of resources.

    You can also view the roles + resource sets assigned to a user via the user view under the Admin roles tab.

    We now have a user who is defined as an administrator for two realms in Okta because they are mapped to two admin roles (with resource scoping).

    Controlling Administrator UIs (SPA vs Okta Admin)

    A standard Okta org has two user interfaces, the Desktop where users access apps, and the Admin Console where administrators manage the org. When a user as assigned to an admin role, they automatically get access to the admin console, with functionality based on the role(s) and resource set(s) assigned to that user.

    This includes roles for managing realms and users in realms. Once you assign a user to a role and permission set for a realm, they can access the admin console with functions restricted to what the role gives them.

    With the introduction of Secure Partner Access there is a new admin UI called the Partner Admin portal. This is a simplified user experience, designed for partner administrators to manage their users.

    But do you want your partner admins to access both the Admin Console and the SPA Partner Admin Portal? Probably not. To address this there is a new Settings tab on the Administrators page where you can define admin role assignment to the Admin Console.

    The default behaviour is that all admin users are automatically assigned to the Admin Console. You can change the behaviour so that the super admin assigns users to the Admin Console.

    So, to have a realm admin only have access to the Partner portal, you would assign them to the Okta application called Partner Admin Portal.

    If that user was already assigned to the Okta Admin Console, you would remove them.

    Then when they access the Okta Dashboard, they will see the new Partner Admin Portal tile but not the Admin button.

    When they access the portal, they can see the portals, users, groups, and apps that the role + resource set grants them.

    You now have Okta users that have scoped access to realms and the users within those realms, via the Partner Admin Portal (and without access to the Okta Admin Console).

    But if you are not using SPA, then you will need realm admins to use the Admin Console.

    Conclusion

    In this article we have looked at how we define administration of realms (with or without Secure Partner Access).

    This involves using the standard Okta constructs of admin roles, resource sets and assignment of these to users. We have looked at how these are defined.

    The second aspect, driven by the introduction of Secure Partner Access, is which interface will be used for this administration. We have looked at how you can use the default Admin Console or disable it and only allow access via the Secure Partner Access portal.

  • An Introduction to Realms in Okta

    Okta recently added a new feature to the Universal Directory called Realms. This article provides an overview of the new feature.

    Note that Realms is only available with the Okta Identity Governance and Secure Partner Access products. At the time of writing this article, Realms is in Early Access.

    Background – Why do we need Realms?

    It is common in many identity management products to need to manage discrete populations of users with some form of delegated administration. The most common example is where partners are defined in the IdM solution and you want someone from each partner to manage their users and the access they have. Another example is geographic or departmental dispersion where you want nominated administrators to manage only the people in their domain. Across all of this you still need system-wide administrators.

    With Okta this has been possible via two patterns:

    1. Use of Groups and Admin Roles – in this pattern the different user populations are made members of groups and then administrative roles are created to restrict the functions an admin can perform on the users in those groups. This pattern allows overlap of administration as a user may be in multiple groups. As all users and apps are in the one org, management of app assignment is straightforward.

    2. A multi-org deployment – where different Okta tenants (orgs) are created for each user population and admins and roles are defined in each org. This does not need to use groups (but they could be). This model could allow a user to be in multiple orgs. Management of app assigment in more complex in a multi-org deployment as apps may be spread across different orgs.

    The two patterns are shown (simplistically) below.

    The challenge with both of these is the administrative overhead, particularly when you need to add or remove new user populations.

    What Are Realms?

    Realms are user containers with inherent administrative boundaries. A user belongs to a realm (and only one realm) and administrative roles are assigned to the realm (or realms). Assignment of administrators to collections of users is much simpler as you assign them to the realm.

    This is shown in the following figure.

    There is always a default realm, and if Realms is turned on in an existing org, then all the existing users are put in that default realm. You can then create additional realms for the different user communities and define the admin roles to manage the users in them.

    Realms only contain users, the app and groups remain system-wide.

    Realms are used by Secure Partner Access, and users’ realms can be used by some functions in Okta Identity Governance for scoping. Realms is only available with the Secure Partner Access or Okta Identity Governance products (SKUs).

    A more detailed explanation can be found in Realms for Workforce Management – A New Flexible Way to Manage your Organization. There’s also an overview video on YouTube.

    Working with Realms

    In this section we will look at some of the capabilities of Realms.

    Realm Administration

    Realms can be managed in the Okta Admin Console under the Directory menu.

    Users can be viewed by realm, but when managing users you’re still managing the user profile.

    Realms administration can be found under the various Manage Realms help topics.

    Automatic Onboarding of Users into Realms

    Now that there are different containers for users, how do you assign users to these containers? You can select the realm when creating a user profile in the Admin Console. But this is not practical when bulk-loading users.

    This is where Realm assignments come in. They allow creation of conditions (rules) to control how users are assigned to different realms.

    These conditions can be prioritised and also toggled from active to inactive. The conditions can also leverage different IdPs, not just Okta. This is particularly useful for federated users.

    Realm assignments will be evaluated on each user create. But you can also run all realm assignments to re-evaluate all users (which may result in users being moved).

    See the Realm assignments help page for more details.

    Delegating User Management

    One of the drivers for the Realms feature was a simpler delegated administration model. To apply delegated administrators to realms, you need to:

    1. Create a custom admin role,

    2. Create a resource set for that realm, and

    3. Create an admin assignment

    When these are configured, the assigned realm admins have a restricted user interface for managing the users (note that the Secure Partner Access product also has a Secure Partner Access portal for this).

    See the Delegate realm management section for more details.

    Okta Workflows and Realms APIs

    Okta Workflows is great for building automation and user management can benefit from this, such as importing users from an external store.

    There is a new Okta Realms connector in Workflows. There are action cards to:

    • Create a realm,

    • Create a realm user (create a user into a realm),

    • List realm users,

    • Read realm,

    • Search realms,

    • Update realm, and

    • Update realm for user

    Note that there are no actions for managing the assignment rules (but there are APIs).

    An example of using the Okta Realms connector to list all users in a realm is shown below.

    There are Realms and Realm Assignments APIs available. You could combine the Workflows actions, these APIs and the Administrator Roles API to automate the creation of new realms.

    Managing Partners

    Okta has release the Secure Partner Access product to leverage Realms for partner management. We have a dedicated Secure Partner Access page for all the SPA- and Realms-related articles.

    Applying Governance

    Okta Identity Governance (OIG) also provides the Realms functionality. With OIG you are managing a users’ assignment to groups, applications and/or entitlements. You aren’t managing user profiles against realms or moving users between realms.

    The two use cases supported with OIG involve scoping users by realm:

    • Certify users in your realms with Access Certifications – scope users or reviewers in a campaign by realm

    • Configure application entitlement policy with Entitlement Management – leverage the user.realmId profile attribute in an app entitlement policy.

    See Realms with Okta Identity Governance for more details and examples.

    Known Limitations and Workarounds

    Please see the Requirements and Limitations section of the product documentation. We won’t copy them here as they are liable to change as the feature develops.

    Conclusion

    Realms represent an elegant solution to the challenge of managing disparate populations of users in a delegated administration model. It removes or reduces the need for complex admin groups or multi-org deployments. Realms are built into Universal Directory and leveraged by Secure Partner Access and Okta Identity Governance.

    You may find the following links useful:

  • Reduce Risk through Governance for Okta Administrators

    In this article we explore the different patterns for associating users with administrative roles and how we can reduce the risk around these using governance. There are multiple articles listing the controls that should be applied to the administrative access in Okta, but this article will focus on the governance controls.

    Introduction

    Okta administration is based around administrators and administrative roles. There are three patterns we see for allowing users (administrators) to perform administrative functions in Okta.

    These are:

    1. Individual Assignment – where an Okta user is directly assigned to one or more administrative roles,

    2. Group Assignment – where an Okta user is assigned to one or more administrative roles through one or more groups, and

    3. Shared Users – where an Okta user is created to be shared by users, and assigned to one or more administrative roles (possibly via groups, but this doesn’t affect the governance approaches).

    There are many articles available covering the different controls you should apply to reducing the risk associated with Okta administration, including:

    Understandably, there are common controls in all of these articles, including some governance controls we will discuss in the following sections and how they can be applied to the different patterns.

    Individual Assignment to Admin Roles

    The first approach to having administrators is to assign Okta users directly to administrative roles.

    Traditionally in identity management this has been considered a bad practice. You can easily get sprawl leading to over permissioning (“just give me the same access as Joe has”) and may lead to high-privileged orphan accounts if an organisation doesn’t have a solid de-provisioning and access review mechanism.

    Okta has a number of mechanisms to reduce the risk of individual assigment:

    1. The Administrators UI shows the roles assigned to each user and could be periodically checked to ensure that individual assignment is kept to a minimum and is appropriate,

    2. An Admin Roles Report can be run (downloaded as CSV) and reviewed, so could be used as part of a periodic review, and

    3. The Govern Admin Roles feature can be used to control the individual assignments

    The latter, Govern Admin Roles, is a new feature which allows moving from static to dynamic assignment of users to admin roles. Specific admin roles can be requested, approved and assigned for a limited period of time and then automatically removed. This feature also includes an access certification capability to periodically review assignment to administrative roles. Use of this feature can significantly reduce the standing privileges in an Okta instance. For more information see the following articles:

    Use of this feature significantly reduces the risks associated with individual assignment of users to admin roles, and is highly recommended.

    Group Assignment to Admin Roles

    The second pattern is to use groups, where the groups represent job roles or business roles and are assigned to one or more admin roles. Assigning/unassigning users to/from the groups will grant/revoke administrative access.

    This is simpler to administer than individual assignments, but still runs the risk of standing privileges if the group memberships are not effectively managed.

    As for the individual assignments you can use the UI and Admin Roles Report to periodically check what groups have access.

    The group membership could be managed by Okta Identity Governance (separate license). The Access Requests capability can allow users to request specific group membership with an approval flow and automatic removal after a set time. The Access Certifications capability can be used to periodically review the members of specific groups. This can ensure only the right people get access by following an approval and audited process, for a limited time, and there’s a process to revalidate those that have long-term access.

    Shared Users and Admin Roles

    A more unique pattern is to have Okta users created for specific administrative functions and potentially shared amongst multiple users. This may be where a specific scoped API token is required, or due to business reasons a shared account needs to be used by all members of a team. These are not ordinary Okta users with access to admin roles, but rather separate Okta users created for specific admin purposes.

    These shared users represent a higher risk because they rely on shared credentials – in the worst case they involve sharing a password around a team and that password may not be updated regularly for fear of someone not being able to access it.

    To address this concern, a new feature has been added to Okta Privileged Access to manage SaaS service accounts (where service accounts refers to any non-federated account that users access via a username and password). This includes management of Okta shared accounts.

    This feature will flag shared accounts, store them in the Okta Privileged Access vault and rotate the password (so only Okta Privileged Access knows the password and this new password is applied to the account in Okta). Policy and rules are then used to determine who can checkout the password for the shared account and under what conditions (such as requiring MFA or a manager approval). When the account is checked back in, the password is again rotated. For more details see Managing and Using Okta Shared Accounts with Okta Privileged Access.

    Using this feature can significantly reduce the risk of shared accounts with standing privileges using passwords.

    Conclusion

    In this article we have looked at the three basic patterns for users getting administrative access in Okta: an individual user assignment to one or more admin roles, an individual user assigned to a group which is assigned to one or more admin roles, and use of a shared account (user) which is assigned to one or more admin roles.

    There are multiple articles (linked above) on the controls that should be applied to any administrative access. In addition you can use some governance controls to reduce risk:

    1. Periodically review admin role assignment through the Administrator UI and the Admin Roles Report.

    2. Use the Govern Okta admin roles feature to move to a dynamically assigned role approach (rather than standing privileges),

    3. Use Okta Identity Governance Access Requests and Access Certification to control admin group membership, and/or

    4. Use the Okta Service Accounts feature in Okta Privileged Access to vault and regularly rotate the password for shared accounts, with controls around who can access them and how.

    Use of these features can reduce the risks associated with administrative access into Okta.

  • Using Ansible to Manage the Server Agent in Okta Privileged Access

    This article looks at how Ansible could be used to manage the server agent (‘sftd‘) on a fleet of Linux servers. The article assumes there’s an Ansible deployment configured and the controller can connect to and run playbooks on managed servers.

    Note, I’m not an Ansible guru, I started looking at it a few days ago in order to figure out some systems management tasks for sftd. The set up I used is very basic and could be improved, and the playbooks I created could probably be better. The examples are just to show how it could be done. YMMV.

    Introduction

    In a small environment with a handful of servers managed by Okta Privileged Access, manually managing the components isn’t a problem. But if you have many server instances, you need some automation/systems management to manage the components. Ansible is a popular tool for automation/systems management across fleets of servers. It can be used to manage the Okta Privileged Access infrastructure components like the server agent (sftd) and the gateway (sft-gatewayd).

    This article looks at how some simple tasks can be implemented into Ansible using playbooks. The tasks are:

    • Checking the sftd is running on a set of servers and if not, restarting it,

    • Checking the version of sftd on a set of servers,

    • Updating sftd to the latest version, and

    • Moving the server enrollment to another resource group/project

    You could also use it to install and configure the server agent, but we won’t cover that in this article.

    Before looking at these use cases, we will look at some of the Ansible set up done for this environment.

    Ansible Set up

    The Ansible set up for this was a simple non-production type deployment. If you already have Ansible installed and configured, it would probably look different to this.

    In this environment there was an Ansible controller and two managed servers running the sftd process. All were Ubuntu 22.04 servers.

    Security

    From a security perspective, the aim was to use native mechanisms and stay away from what Okta Privileged Access could provide.

    We created an ordinary user on each managed server called “ansible“.

    Rather than rely on username/password, we configured a ssh key pair on the Ansible controller (using ssh-keygen) and distributed the public key to the new ansible accounts on each target servers (using ssh-copy-id).

    So that the ansible user could sudo without password, the user was added to the /etc/sudoers.d/90-cloud-init-users file (same as for the default ubuntu account).

    # Created by cloud-init v. 24.3.1-0ubuntu0~22.04.1 on Mon, 25 Nov 2024 04:48:39 +0000

# User rules for ubuntu
ubuntu ALL=(ALL) NOPASSWD:ALL

# User rules for ansible
ansible ALL=(ALL) NOPASSWD:ALL

    This is not the best practice for security. There are many ways you could tighten security on that account, such as restricting what sudo commands can be run and controlling where the user can log in from. Note that there’s an Ansible Vault feature that may also be useful in managing account credentials.

    Other Set up

    For this environment, all files are in a single directory (which wouldn’t be the case in a production deployment of Ansible).

    This includes an inventory file that has a single group ([ubuntu]) with the two test servers, the connection method and the account to use (the ansible account mentioned above)

    There are some files with enrollment tokens for projects in Okta Privileged Access. There are a set of playbook files (sftd.*.*.yml). We also had a simple script that runs a ping via Ansible to check connectivity.

    The use of the files will be explained in the sections below.

    Ansible Automation Examples

    Let’s look at some examples of how Ansible can be used to manage the sftd processes.

    Check Status and Start sftd Process

    The first use case is checking to see if the sftd process is running, and if it’s not, to start it. Ansible provides a set of out-of-the-box modules, including one called ansible.builtin.service which is used to work with Linux services, like sftd.

    The playbook shown below will use this module to check if the service is in a started state. If not, it triggers the handlers section that will restart it. Note that most modern Linux OS support the serviced mechanism that this module is talking to.

    This playbook will use the become and become_user arguments to elevate the user (ansible) to root (i.e. run the commands via sudo to root). This is why we needed to allow the user to run sudo commands without requiring a password. If you didn’t you would need to pass in a password.

    - name: Verify sftd running
  hosts: ubuntu
  remote_user: ansible
  become: true
  become_user: root
  tasks:
    - name: Ensure sftd is running
      ansible.builtin.service:
        name: sftd
        state: started

  handlers:
    - name: Restart sftd
      ansible.builtin.service:
        name: sftd
        state: restarted

    To test this we log directly into one of the managed servers, stop the sftd service, and check the status of the process.

    It’s now down.

    On the Ansible controller, we run the ansible-playbook command, passing that inventory file mentioned earlier, and the playbook file from above. It shows that there was nothing done on one of the servers (ip-172-31-12-41) but on the other (where we stopped the process) it did make a change.

    Checking the service again, we can see it was restarted.

    This is a fairly simple use case and you could schedule the command to run frequently. If the sftd process is still running, as you would expect, it doesn’t do anything.

    Check sftd Versions

    For the next use case we want to check the versions of the sftd installation on each server (to use in the next use case). The sftd -version command will return the agent version. This command will run on any supported server agent OS.

    To get this in an Ansible playbook, we could use the ansible.builtin.command or ansible.builtin.shell modules. There are subtle differences between the two, but as we wanted to parse out the actual version, we chose to use the shell module. It uses the register argument to specify an object name for the command and then a debug task to display the info,

    - name: Check sftd version
  hosts: ubuntu
  tasks:
    - name: Get sftd version 
      ansible.builtin.shell: /usr/sbin/sftd -version | awk '{print $3}'
      changed_when: False
      register: sftdver

    - debug: msg="Current version = {{ sftdver.stdout }}"

    Running the playbook includes some text in the output showing the version number of the two servers – one is at the current version (1.87.1, as at Nov 2024) and the other is an older 1.83.1 version.

    Now that we know we have some older versions in our environment, perhaps we can use Ansible to update them?

    Update sftd Version

    There are different processes to update a sftd package (scaleft-server-tools) on different Linux platforms depending on the package manager for that platform, but none of them are documented. You need to look at the install steps to see the package manager used and extrapolate from there. For Ubuntu/Debian it uses apt. On Red Hat (RHEL)/Amazon Linux/Alma Linux/Fedora it uses dnf or yum. On SUSE Linux it uses zypper. The standard update option should work, but we did not test updating sftd with platforms other than Ubuntu.

    There is an Ansible module, ansible.builtin.apt, to run apt commands (there are dnf and yum_package modules in Ansible, but nothing for zypper).

    The playbook for updating sftd to the latest version is shown below. Note that you do not need to tell it to restart the service, the module does all of this for you. As shown earlier, this will run as (sudo to) root. You could use the same command to install sftd if it wasn’t already installed, but there are additional steps required, so the only_upgrade argument is used.

    - name: Update sftd version
  hosts: ubuntu
  tasks:
    - name: Update sftd version 
      become: true
      become_user: root
      ansible.builtin.apt:
        name: scaleft-server-tools
        state: latest
        install_recommends: true
        only_upgrade: true

    Running this playbook across both Ubuntu servers results in one not being upgraded (as it was already at the latest version) and one being changed (i.e. updated).

    Running the versions playbook from earlier confirms that the second machine is now at the latest version.

    This completes the standard systems management tasks.

    Move Server Enrolment to Another Project

    For a more advanced topic, lets look at how we could use Ansible to re-enrol a server agent into a different resource group/project in Okta Privileged Access. Enrollment is controlled by the enrollment tokens passed to the server agent. If you change the enrollment token, you change the project the server is mapped to. This mechanism could be part of automation for a wider migration exercise.

    The playbook will walk through the steps to do this:

    1. Stop the sftd process

    2. Blow away all of the state files associated with the agent (in /var/lib/sftd)

    3. Recreate the /var/lib/sftd directory and set the owners to root and permissions

    4. Copy an enrollment token file for the new project from the local directory across to the target server as /var/lib/sftd/enrollment.token and set the owners to root and permissions

    5. Restart the sftd process

    It uses two other builtin modules – ansible.builtin.file and ansible.builtin.copy, and runs as (sudos to) root.

    The playbook file has the target server and source token file hardcoded, but you would parametrise this in production.

    - name: Copy token file and restart sftd
  hosts: ip-172-31-12-41
  become: true
  become_user: root
  tasks:
    - name: Stop sftd service
      ansible.builtin.service:
        name: sftd
        state: stopped
    - name: Delete /var/lib/sftd
      ansible.builtin.file:
        path: /var/lib/sftd
        state: absent
    - name: Create /var/lib/sftd
      ansible.builtin.file:
        path: /var/lib/sftd
        state: directory
        owner: root
        group: root
        mode: '0755'
    - name: Copy new token file
      ansible.builtin.copy:
        src: ./new-enrollment.token
        dest: /var/lib/sftd/enrollment.token
        owner: root
        group: root
        mode: '0644'
    - name: Restart sftd service
      ansible.builtin.service:
        name: sftd
        state: started

    This playbook just has the commands needed. In production, you would need to look at some error handling between steps and some stdout/stderr notifications written out.

    Running the playbook performs each step (if you monitor the /var/lib/sftd directory you will see it be cleared out, and then recreated with a different inode).

    Checking Okta Privileged Access you can see the server has been defined in the new project.

    NOTE – This process does NOT delete the old server definition in the other resource group/project. There is no way to do this programmatically from within Ansible. Whilst there are two server definitions, users cannot connect to them. You can wait for it to be automatically removed from Okta Privileged Access, or go into the admin console and delete it from the old project.

    You may also need to revisit any policies that leverage the server to make sure they are still as you expect.

    This completes this use case.

    Conclusion

    Ansible is the ideal tool for automation/systems management across a large fleet of servers. It can be leveraged for the day-to-day management of the Okta Privileged Access infrastructure components.

    This article has shown a simple Ansible deployment and how playbooks can be used to check/restart the sftd process, check versions, automatically update to the latest version and even move a server from one project to another in Okta Privileged Access.

    The examples shown are trivial implementations but should provide a start towards implementing Okta Privileged Access infrastructure component management with Ansible. There are ample examples of different Ansible commands and playbooks across the web, the the Ansible documentation is excellent. We’d love to see what you come up with the manage your environment.

  • Managing and Using Okta Shared Accounts with Okta Privileged Access

    Okta recently announced a new SaaS app service account capability for Okta Privileged Access. This includes being able to manage the passwords for Okta users (accounts) that may need to be shared for administrative functions. This article will explore this new capability.

    Introduction

    Users in Okta may be consumers of Okta services, like SSO, but also administrators of the platform. There is a rich set of roles and permissions that can be assigned to users to perform administrative functions. These may be assigned to individuals or groups.

    It has been standard practice to assign groups to roles and permissions then manage membership of those groups through Okta Identity Governance (access requests to get access, time limits to minimise standing privileges and access certification to review any long-term administrative access).

    Earlier this year Okta introduced a new capability called Governance for Admin Roles which applied a similar approach to individual assignment to roles and permissions. This was just one of the areas Okta focussed on to tighten up security for the platform. Another was enforcing Mulit-factor Authentication (MFA) to every administrative access to the platform.

    Another recently announced capability is managing Okta service (or shared) accounts in Okta Privileged Access. Many Okta deployments setup shared Okta accounts for administrative functions. This may be so that a team can use the same account to perform specific tasks rather than granting admin rights to individual users. It may be that a special account was setup to create API Tokens or for use with legacy agents. Moving these accounts into Okta Privileged Access means that security around access to them can be tightened – increasing to overall security posture of the Okta deployment.

    The new capability uses the term “service account”. This does not mean it applies to just service accounts, but rather any shared/functional privileged account.

    The capability is automatically enabled in Okta Privileged Access and the associated Okta feature flag will get enabled when it becomes Generally Available. In the meanwhile, you need to work with Okta to get the feature flag turned on.

    An Overview of Managing Okta Shared Accounts in Okta Privileged Access

    The solution involves both core Okta (Okta WIC) and Okta Privileged Access. There is an in-built synchronisation component between the two platforms.

    The steps in setting up a new Okta service accounts are shown in the following figure. This gives an overview of the components and how they work together.

    The new account flow is:

    1. A new or existing user is assigned to one or more administrative roles in Okta WIC. Technically the user does not need to be an administrator to be used in this capability, but it doesn’t make sense to apply these controls to an ordinary user.

    2. The user is flagged as a service account by applying the “Manage with Privileged Access” action.

    3. The user is now visible in the new Service accounts view in the Okta administration UI.

    4. At the same time, this new account is synchronised across to Okta Privileged Access and placed into an “Unassigned accounts” holding area.

    5. The new account is assigned to a Project within a Resource Group. This Project may have specific settings for password complexity, rotation schedule and exclusive checkout.

    6. A Policy and Rule must be configured to allow users (Principals) to access that service account. The rule can also apply an Access Request condition and override the Maximum Checkout time.

    7. A user who is entitled can reveal/checkout the Okta service account username and password and leverage them to log into Okta

    From an Okta (WIC) perspective the capability is leveraging Okta Users and Administrators, but has added the ability to flag an account as a service account and sync it to Okta Privileged Access.

    From an Okta Privileged Access perspective the capability is leveraging standard constructs – Resource Groups, Projects with settings, Policies and Rules with controls. It has added a new resource type of “Okta service accounts” alongside servers and secrets (and SaaS app service accounts that will be covered in another article).

    An Example

    Let’s look at an example of a user that needs to use a shared (service) account. The user is in a group assigned to the appropriate policy with rule to access the account.

    The user logs into their Okta Dashboard and clicks on the Okta Privileged Access tile. They are SSO’d to Okta Privileged Access and have the option of Okta Service Accounts under MY PRIVILEGED ACCESS. This shows one Okta account they can use.

    They select the account and will see the access methods available. There may be multiple policy rules that apply to this user. In this case there is only one, so only one access method. It’s set to allow the user to show and checkout the account credentials.

    They see the Username and Password for the account (the password is masked by default to reduce the risk of shoulder surfing, but they can reveal the password).

    This is a complex password that Okta Privileged Access has generated and applied back into Okta (rotated in PAM terminology). There is also a checkout timer set for this access.

    They copy’n’paste the Username and Password into a login prompt in another browser window.

    From the Okta Dashboard, the user would launch the Admin UI and would then perform any MFA enrolment and/or response as required. They are now in the Admin UI as the service account with only the admin functions that are assigned to that user.

    Back in their original Okta Privileged Access session, they close the dialog that showed the username and password. The account is now shown as CHECKED OUT, meaning no other user can access this account until it’s checked back in.

    They can wait for the checkout timer to expire and have it checked in automatically. Or they can Check it in themselves. The go to the Checked Out Accounts menu item to see all accounts they have currently checked out. In this case there’s only the account they used above.

    The can use the Check in button to return the account to the pool.

    It’s worthwhile looking at the Okta system log to see what occurred with the Check In. You can see the access with the account in the bottom three events. Then there are events related to the check in and password rotation starting, the password being updated in Okta by Okta Privileged Access (passed via the synchronisation mechanism), and then the check in and password rotation completing.

    The account now has a new password that is not known to the user who last accessed the account.

    Considerations for MFA for These Accounts

    As mentioned earlier, as part of Okta’s commitment to tighter security around the platform, MFA is now required for all administrative access into Okta. Putting the passwords into the vault does not change this requirement. So, if using this capability with its password rotation there may be times that MFA makes the process less than optimal. This is not a constraint with Okta Privileged Access, it’s just the way that Okta WIC is configured and you would strike the issue with shared accounts not in Okta Privileged Access. Let’s explore different scenarios.

    If you are still running an Okta Org that doesn’t require MFA on admin access, either because it’s old or there is an exception in place, there is no issue. You can checkout the username and password and just access Okta and the Admin UI.

    If the shared account will only ever be accessed by one user, then the first time you checkout the username and password and go to the Admin UI, you will need to set up MFA as you would with any new account. From then on, each time you check out the shared account you would just use the MFA you’ve already set up.

    However, this becomes more challenging if there are multiple users who need to checkout and use the shared account credentials. The first time the shared account is checked out and the Admin UI is accessed, Okta will prompt to setup MFA. The next time when someone else goes to checkout the shared account, Okta will know that MFA has already been set up and prompt for verification against the previously registered factor (which may be the phone or laptop of the prior user). You could try to add another factor, but the enrolment process will want to use the previous factor for verification. This is how MFA works in Okta. How to handle this situation? Some suggestions:

    • Encourage each user to remove their factor when they have finished using the shared account (or possibly build some automation using the Factors API to automate this). This is a painful manual process and probably wouldn’t be 100% reliable.

    • If the MFA factor being used has a transferrable SID, you could store this SID in a Server in the Okta Privileged Access vault and have a process to reveal the SID and apply it to the factor. This could also be a painful process.

    • Have one person in the team, and their authentication factor as the single factor for the shared account no matter who uses it. That way you have a “dual control” approach.

    • Use a shared mechanism for authentication, such as a shared phone, shared email address, even a shared physical token stored in a safe. All have been used in the past for similar situations.

    This multi-user, one shared account scenario is probably an extreme edge use case, but may need to be considered. Ideally, the plan should be to move away from shared admin accounts in Okta, and Okta is helping this with initiatives to reduce the need for shared admin accounts, like removing the need for API Tokens with agents.

    Conclusion

    In this article we have looked at the new Okta service account capability, where shared account credentials are stored in Okta Privileged Access, can be revealed and used by entitled users and regularly rotates the password of those accounts. We have provided an overview of the capability, an example of it’s use and a discussion on how this works with the requirement for MFA on all Okta admin access.

    Replacing a static/shared password for these accounts with a complex/regularly rotated password will significantly improve the security posture of your business. Ideally the strategic goal would be to remove the shared admin accounts from Okta and move to individual admin assignments, but in the interim the mechanism shown in this article provides a tactical approach to improve security of the Okta environment.

  • The Combined Power of Okta Privileged Access and Okta Identity Governance

    This article looks at the benefits of combining Okta Privileged Access with Okta Identity Governance to reduce the risk of using privileged accounts and access.

    Introduction

    Both Okta Privileged Access (OPA) and Okta Identity Governance (OIG) are part of the Okta Workforce Identity Cloud platform (Okta WIC). OIG is focused on governing identities – having controls to manage who gets access to what and being able to prove it. OPA is focused on managing access to privileged resources. Together they can provide an effective way to reduce the risk of using privileged accounts in one platform and move to a Zero Standing Privileges model.

    Both products leverage shared components in the Okta WIC platform. You can see this in the following figure showing the architecture of OPA.

    In addition to the core PAM capabilities built into the OPA cloud tenant (aka “Team”) there are additional capabilities provided by other Okta WIC components through the OPA SKU:

    • OPA is an application within Okta WIC in the same way that any other SaaS app is. This means the app authentication policies (including MFA) can be applied; it has users assigned (individually or via groups); and groups can be pushed to OPA from the app.

    • Authenticators (i.e. MFA) defined in Okta WIC can be applied to access policies in OPA, so that when a user goes to access a privileged resource they are prompted for Okta-managed MFA.

    • All events in OPA are written to the Okta WIC system log along with all other Okta WIC events. Custom reporting can be built around those events, whether they are specific to OPA or across multiple components.

    • The OIG Access Requests platform has been extended for just-in-time (JIT) approval of OPA access. For example you could have a policy where accessing certain servers with specific accounts requires a manager’s approval. This can be done with OIG Access Requests.

    • During Oktane24 it was announced that OPA will be able to manage Okta service accounts and SaaS app service accounts (either a supported OIN integration handling automated password rotation or a BYO model for other apps).

    In addition to the native capabilities list above, there are scenarios where OIG or Okta Workflows can be used to provide additional controls for Privileged Access Management (PAM). These will be explored in this article.

    As a side note, there are PAM scenarios that can be addressed without needing OPA, just capabilities within Okta WIC. For example, privileged access to Amazon Web Services is driven by roles or permission sets chosen when performing single sign on to AWS (and those roles or permission sets grant privileged access). Assignment to those roles or permission sets in Okta can be controlled by group memberships and this can be incorporated into OIG access requests and access certification.

    Using Okta Identity Governance to Enhance Okta Privileged Access

    Lets have a look at some of the Okta Identity Governance, including lifecycle management and Okta Workflows, capabilities and how they can be used to enhance PAM use cases in OPA.

    Just-in-time Access Approval

    Okta Privileged Access uses a policy framework to determine who can access privileged resources and how. The “how” can be conditions (such as “traffic must be routed via a gateway”) and/or controls (such as “phishing-resistant MFA” must be used to access this server for this account). 

    A common control to apply in a policy rule is to require approval. You can define approval flows in the OIG Access Requests platform and initiate a flow when attempting to access a privileged resource.

    For example, you may have a security policy whereby accessing production servers by one of the high-risk shared accounts (like root, system admin or DBA accounts) requires the approval of both your manager and the service owner. This flow is implemented in the Access Requests platform and linked to the relevant policy rule.

    When a user attempts to access the server a request is raised and their manager notified via email. They can use the Access Requests web UI or one of the chat apps (Slack or Teams) to review the request and approve (or decline).

    Thus you can apply governance controls at the time that the user needs to access a privileged resource, supporting the Zero Standing Privileges model. This is functionality included with the OPA product, it does not require additional OIG licenses.

    This was explored some time ago in the article Okta Privileged Access and Okta Access Requests. Note that the direct OPA integration still uses the older Request Type mechanism in Access Requests. Migration to the newer Request Catalog (discussed later) is on the roadmap.

    Access Requests for OPA Access

    Okta Privileged Access has administrative roles to control who can administer OPA and policies to determine access to privileged resources. Both of these are based on groups within OPA. These groups can be pushed from Okta WIC.

    This is shown in the following figure. Groups in OPA are attached to policies and roles. These groups can be pushed as Push Groups from Okta WIC like any other SaaS application defined in Okta. These groups could be assigned via Access Request flows (either the older Request Types or the newer Conditions). 

    Users can request access to these groups via Access Requests and have an approval flow run to allow assignment to the group.

    This triggers an access request in the OIG Access Request platform that the manager will review.

    This assignment would flow to OPA and grant access to the roles and/or policies for the group.

    Access Request flows can also apply timers. You could set flows to only grant access for a short window (like 2 hours) or for a longer period (up to a certain date). Once the timer expires, the user loses group membership and can no longer access the privileged resources.

    The earlier example was for JIT approval for resource-specific access. This example provides broader controls to manage who, and when, users have access to admin roles and policies in OPA. Together you can apply a multi-layered approach to access to minimize standing access and have the appropriate risk-based controls tied to that access.

    This approach requires both OPA and OIG.

    A more in-depth exploration of this can be found in Managing Access in Okta Privileged Access with the new OIG Resource Catalog.

    Access Certification for OPA Access

    In the previous section we showed how groups in Okta can be pushed to OPA and tied to admin roles and policies to grant access, and the membership of these groups can be requested through OIG Access Requests. In many cases you would assign group membership with a timer so that the access would be automatically removed in a short time. 

    But how do you provide visibility and control for longer-term access? You can use OIG Access Certification to periodically review group membership that’s granting access in OPA. For example, the following image shows a number of groups assigned to (and pushed to) OPA.

    An access certification campaign can be created and launched that reviews the membership of those groups.

    When run, the reviewers (such as user managers) can see the groups their people are assigned to and decide whether they need to retain the access or not.

    The campaign can be set to automatically remove access once the reviewer clicks the Revoke button.

    Combining this with the previous example, you can use OIG to control which OPA groups a user can be assigned to and automatically revoke the access after a set period of time. For the longer term assignments, access certification campaigns can be run to periodically review access and remove them. Combining this with JIT controls (like access approval and MFA) can reduce standing privileges and reduce the risks associated with getting privileged access.

    Enhancing the Information Available to Reviewers

    There are many scenarios where you can leverage Okta APIs and Okta Workflows to enhance the OPA information available within Okta and OIG.

    For example, the following blog articles look at collecting information on group assignments in OPA and putting the information into the group description that can be used by OIG.

    You can see the outcome of these in the some of the screenshots above.

    We are also working on an example of using the new Entitlement Management feature in OIG to be able to consume and show OPA Policies as entitlement bundles in both Access Requests and Access Certification. Details TBA.

    Leveraging Okta Workflows

    Okta Workflows is Okta’s no-code integration platform used to implement bespoke processes. It can be a standalone product but also comes as part of the Okta Identity Governance product.

    Whilst Okta Workflows isn’t needed for OPA, it can help with bespoke use cases. For example:

    • Using the OPA Reporting API to generate audit reports on privileged access

    • Building a migration tool to migrate from Okta Advanced Server Access into OPA

    • Sending reminders to admins when secrets are due for rotation

    • Notification on discovery of a new shared account on a server

    Okta has published a Workflows Okta Privileged Access Connector that implements many of the OPA APIs and provides a secure (OAuth) authentication mechanism for making the API calls.

    See the following articles for examples of using Workflows and the new connector:

    Note that Okta Workflows is not included with Okta Privileged Access.

    SaaS Service Accounts and OIN Connectors

    Okta recently announced support for management of SaaS app service accounts in Okta Privileged Management. It involves synchronisation between Okta WIC and OPA to bring application service accounts under management (and into the OPA Vault).

    The mechanism supports two approaches:

    • An automatic mode where the Okta Integration Network (OIN) integration supports password rotation. When a managed account password is rotated in OPA, the new password is sent to Okta WIC and the OIN integration applies that password to the account in the SaaS app.

    • A manual (or BYO) mode where there is no integration supporting rotation. When a password for the service account is rotated in OPA, it must be manually updated in the SaaS app.

    Where the passwords are rotated, the OIN integrations are used to provide the plumbing – there is no need for OPA-specific integrations or adapters. The number of OIN integrations enabled for password rotation will grow over time and the OIN integrations may be leveraged for other OPA functionality.

    Conclusion

    In this article we have explored integration patterns between Okta Privileged Access and Okta Identity Governance. Whilst OPA itself can implement many Privileged Access Management scenarios, the addition of OIG can supplement OPA to provide greater control over who gets access to what privileged resources, when and how, leaving to a Zero Standing Privileges model where users only get privileged access when they need it after passing the appropriate controls.

  • Okta Privileged Access Requests with JIRA and Okta Workflows

    This article looks at how to use Jira to raise and manage time-bound privileged access requests in Okta Privileged Access. It leverages an Okta Workflows solution that integrates with Jira and then manages Okta group membership.

    Introduction

    Before looking at the solution details and the user flows, it’s worthwhile providing an overview and some design considerations.

    Overview of the Solution

    The solution is implemented in Okta Workflows, with integrations into Jira, Okta and email.

    The following figure shows the main components and interactions.

    Starting on the right of the diagram, there is Okta Privileged Access (Okta PA or just OPA). It has policies that control who (via groups) can access which resources (e.g. servers) and how (different accounts and controls). It’s important to note that this is controlled at the group level in OPA, not the individual. These groups are normally pushed from Okta (WIC).

    In Okta the Okta PA application has push groups assigned. Whenever these groups are changed in Okta, the updated group is pushed to Okta PA which affects who is subject to the OPA policies. Thus you can have different groups in Okta to represent different access roles in OPA assigned to different policies.

    Whilst these groups could be managed in Okta itself by an admin, via APIs or via Access Requests in Okta Identity Governance, we want to be able to manage them from within Jira. To do this we have implemented a series of Okta Workflows to respond to tasks raised in Jira. These tasks could be to request (create) privileged access, extend privileged access or view the current privileged access.

    Within the Workflows solution there is a table to keep track of requests (and one for an audit trail, not shown) and a series of workflows:

    1. A workflow to create a new request, which will add the request to the requests table and add the user to the group in Okta.

    2. A workflow to extend an existing request, which will update the expiry time on the request in the requests table (but not change the group membership)

    3. A workflow to view the existing requests for a user, including the expiry times for each

    4. A workflow to periodically check for pending (soon-to-expire) requests and notify the user

    5. A workflow to periodically check for expired requests and remove the user from the relevant group

    The first three are triggered on a new task being created in Jira. The last two run on a timer to periodically check for soon-to-expire and expired requests. All workflows will result in emails being sent to the user.

    Some Design Considerations

    It is a common ask for service delivery or ticketing tool to be able to raise requests against Okta resources (apps, groups and entitlements) using Okta Identity Governance and its Access Requests feature. This involves the tool, like Jira, to make API calls into Access Requests to raise a request. For this solution, we chose to bypass Access Requests and build the mechanism into Okta Workflows directly. This means no OIG license is needed (only Workflows) and there is greater control over the timer functionality.

    Okta Workflows has a Jira connector that includes actions such as listening to new issues raised in Jira. Jira has the flexibility of adding custom fields to an issue type. Thus we were able to add an Access type (New access, Extend access, View access) and Admin group (the Okta group the user is requesting access to). These are passed into the workflow using the connector and used for routing and assigment.

    A key component of this solution is that access to OPA resources is time-bound. Users are added to a group and an end-time calculated (and when that end-time arrives, access is removed). This time could be fixed or calculated based on the request information. In this case we have used the Change type field: Emergency = 4 hours, Standard/Normal = 12 hours. This is purely arbitrary. You could base this off the Change risk (higher risk = shorter time) or even the group being given access to (e.g. prod group = 4 hours, non-prod = 12 hours). You could use the standard Jira start and end dates. You could even get the user to select a period and pass it into the workflow. This is just to show how it could be done.

    The mechanism doesn’t do any vetting or approval. In a real deployment, this would be done in Jira prior to the Workflows getting involved. We have just assumed this is done for the sake of simplicity.

    Many of the workflows are bare-bones to show how the solution can be implemented. This includes some back HTML-formatted emails being sent. You could improve them or swap them out for Slack/Teams notifications via the connectors available in Workflows.

    The persistent store for both the requests and the audit trail is in Workflows tables. These are not designed for scale or performance, so if you were implementing a solution based on this, you should look at some other persistent store (like an AWS-hosted DB accessed via Lambda functions).

    The solution could close out the Jira task when each request is complete, but this was not implemented in the workflows. This could be done by the Transition issue card.

    One last consideration, any user requesting access to one of the groups pushed to OPA still needs to be assigned to the OPA application in Okta. This could be done by also mapping the push groups as assignments to the app, having a group assigned for anyone who may need OPA access, or dynamically adding them to an assignment group at the same time as adding them to the push group.

    User Experience and Background Flows

    Lets walk through the flows from an end-user experience. We have a user, Neville Newadmin (neville.newadmin@atko.email) who is defined in Okta and Jira and needs to perform some urgent maintenance work in some Linux servers.

    User Requests Privileged Access

    Neville raises a request in Jira request selecting the project and type (Task) and providing a summary and description.

    He sets the standard change type, risk and reason fields. The access type is New access as he is raising a request for some new privileged access. He selects the admin group for the request, which is the Okta PAM Linux Sysadmins group (which is assigned to policies in Okta Privileged Access to grant access to Linux servers). He sets a start and end date and team and submits.

    Note that not all of this information is needed for the workflows solution, but would form part of the task history in Jira.

    Neville checks his email and sees there’s a new email titled Privileged Access Granted.

    Opening the email he sees notification that his access has been granted to the Okta group, with the start and end dates of the access.

    The access was granted for four hours because it was set to an Emergency type access.

    Checking Nevilles profile in Okta, we can see he’s been added to the PAM Linux Sysadmins group as requested.

    You may notice that the PAM groups shown contain additional information about the access granted by the group membership. For more information on this see Okta Privileged Access and Access Certification – Getting Roles into the Group Description.

    Looking at the Okta system log, you can see that the user was added to the group and that group was immediately pushed to Okta Privileged Access.

    This means Neville can access the Linux servers via Okta Privileged Access.

    User is Reminded about Pending Expiry of Access

    There is a background task (workflow) that is periodically checking for upcoming acess expiration. Neville notices a new email indicating his Linux access will expire soon.

    This hasn’t removed any access, it is just checking for access due to expire soon.

    User Checks Their Privileged Access

    To confirm, Neville raises another Jira task to view his access.

    Most of the information here is not important (we just simplified things by reusing the one task template). The access type of View access will trigger a check of Nevilles access.

    He receives an email titled All Access Requests.

    The email shows that he has three access requests, one completed (DONE) and two that are active – one for his urgent Linux request and a longer (lower risk) Windows server access request.

    User Extends Privileged Access

    He decides he needs to extend his Linux access as he needs more time for the maintenance task. He enters the same details as for the initial request, but selects an access type of Extend access.

    He receives an email indicating his access has been extended with the new expiry date and time.

    Note that there has been no change to his access in Okta or Okta Privileged Access.

    Privileged Access Expires and is Removed

    There is a background task (workflow) that is periodically checking for expired access and if it finds any it removes the access. Neville notices a new email indicating his Linux access has expired.

    Checking the Okta system log, we can see that the group membership was removed and pushed to Okta Privileged Access.

    Checking Neville’s profile in Okta, you can see he has lost the PAM Linux Sysadmins group membership.

    This Neville can no longer perform privileged administration functions on those Linux servers (unless he requests access again).

    Details of the Solution

    This section of the article looks at how the solution is built. It won’t go into fine details of all the components.

    JIRA

    The standard Jira task template was modified to add two new Context fields – Access type and Admin group. A set of standard fields were also kept, but only the Change type field is used by the workflows.

    The Access type is a pulldown field with three fixed values – New access, Extend access and View access. The workflows are expecting these options exactly as they are.

    The Admin group field is a pulldown field with the list being the (exact) group names for the Okta push groups on the Okta Privileged Access application. In this example we have two, one to represent Linux sysasdmin access and another to represent Windows sysadmin access (both tied to specific policies in Okta Privileged Access).

    The only other change to Jira was to setup an API token for a user to use in the Workflows connector.

    Okta Workflows Connectors

    The solution uses three Okta Workflows connectors:

    • The Jira Connector – to listen for new issues being raised in Jira and lookup user details

    • The Okta Connector – to lookup users/groups, and update group memberships, and

    • The GMail Connector – for sending emails (you could replace this with another email connector)

    These need to be setup prior to importing and using the solution.

    Okta Workflows Tables

    The heart of the solution is the persistent store of requests. This Access List table stores:

    • The Okta ID of the user

    • The Okta username (e.g. first last)

    • The user email (their username in Okta and email in Jira)

    • The Okta ID of the group being assigned

    • The name of the Okta group

    • The access start date-time

    • The access end date-time

    • The status – one of NEW (new active request), EXTENDED (extended active request) and DONE (expired/completed request)

    • The access end time in human-readible format in the timezone of the request

    This table is accessed by all of the workflows.

    The second table, Audit Trail, is a running log of all request updates (add, extend and remove).

    This table is written to, but not read. You could export it to CSV for reporting.

    Okta Workflows Main Flows

    There are eight main flows used in the solution.

    The A** flows are used for all three task types coming from Jira:

    • The A00 flow is listening for the new Jira task. It will check it’s the type of issue we’re looking for then call one of A10, A20 or A30 depending on whether this is a new, extend or view request.

    • The A10 flow will collect the relevant details from the Jira task, find the user and group in Okta, assign the user to the group, add a record to the Access List table and write an audit record out, then send an email to the user.

    • The A20 flow will collect the relevant details from the Jira task, find the matching record in the Access List table and update it for the new end date-time (and write an audit record), and send an email to the user.

    • The A30 flow will lookup this users records in the Access List table, format them and send an email with the results

    The B** flows are for checking for upcoming expirations and notifying the user(s). This would be scheduled to run on a timer, with the frequency dictated by how soon before you want to check and notify. For example, you could run it every hour and check forward an hour, or run it every 15 minutes and check forward for 15 minutes (the sample is set at four hours). There are two flows:

    • The B00 flow will search the Access List table for any active (i.e. not “Done”) requests that have an end date-time in the next X period. For each found it calls B01.

    • The B01 flow will format and send an email with the results and send an email to the user.

    The C** flows are for expiring access and notifying users. This would also be run on a timer and the frequency would be dictated by how soon you need access taken away after an expiry. There are two flows:

    • The C00 flow will search the Access List table for any active (i.e. no “Done”) requests where the end date-time has passed. For each found it will call C01.

    • The C01 flow will remove the user from the group, update the Access List table (and add an audit record), and send the user an email with confirmation.

    These flows all leverage other helper flows.

    Okta Workflows Other Flows

    There are two sets of other flows involved in the solution – the flows that interact with the two tables (Access List and Audit Trail), and some utility flows.

    The T** flows interact with the tables:

    • The T10 flow will write a new request into the Access List table and write an entry to the Audit Trail table

    • The T20 flow will update a request in the Access List table to indicate the new end time and write an entry to the Audit Trail table

    • The T30 flow will read all records in the Access List table for a specific user, and using T31 on each returned record, format the list into a HTML table for use in an email

    • The T40 flow will update a request in the Access List table to mark it as “DONE” and write an entry to the Audit Trail table

    Finally there are two utility flows called from other flows:

    • The U10 flow will find the user in Jira and Okta and return the various Ids for the user

    • The U20 flow will do some time calculations to determine end times

    This concludes the exploration of the solution components.

    Conclusion

    It is common to integrate service desk/ticketing tools with Okta. One approach is to use Okta Identity Governance, particularly the Access Requests module. However it may be simpler to tie the service desk/ticketing tool directly into Okta (WIC) and manage apps/groups/entitlements there and ignore OIG completely.

    This article has shown how Jira can be used for time-bound privileged access in Okta Privileged Access, leveraging Okta Workflows with the Jira/Okta connectors, and Okta groups pushed to the Okta Privileged Access app and assigned to policies there. We have looked at how you can implement mechanisms to raise requests, extend the time of access, view access and automatically expire access after the allotted time.

  • Troubleshooting Okta Privileged Access

    This post looks at the tools to use when troubleshooting issues with Okta Privileged Access (OPA). It’s not a “if you see this error, go do this” article – Google is great for that! It will look at where to go to look for diagnostic info to help troubleshoot issues.

    This article is based off the older Troubleshooting Okta Advanced Server Access (ASA) post as many of the infrastructure components, and thus diagnosis approaches, are the same. Much of this content has been consolidated into the Okta Privileged Access Technical Guide for Infrastructure Components, found on the OPA Product Hub. This article has not been maintained, but the Guide has.

    Revisiting the Okta Privileged Access Components and Flows

    Before diving into troubleshooting, it’s worth revisiting the product components and flows so you know where to look for something breaking.

    Okta Privileged Access Architecture

    The Okta Privileged Access architecture is shown in the following figure.

    There are multiple cloud services involved: the Okta Workforce Identity Cloud (WIC) org, the Okta Access Requests Platform tenant, and the Okta Privileged Access tenant (“team”). Okta Workflows is not included in Okta Privileged Access license, but may be used for bespoke automation.

    The bottom quarter of the figure shows the infrastructure components that are currently used in the server access use cases. These are: the Client (“sft”) that runs on the users workstation, the Agent (“sftd”) that runs on the servers, and optionally the Gateway (“sft-gatewayd”) that runs on a gateway server.

    These infrastructure components are the same as for Okta Advanced Server Access.

    Components and Flows

    The flows between the components are shown in the following figure.

    The three infrastructure components will only ever communicate with the Okta Privileged Access team (the team will never contact the components):

    • The Client will contact the team to perform authentication and authorization of the user and the command they are trying to run, request and consume policy evaluation, raise an access request or get passwords/certificates issued.

    • The Gateway will contact the team for enrollment and to get certs issued.

    • The Agent will contact the team for enrollment, certificate issue, user provisioning and writing audit events.

    The Client will establish SSH or RDP sessions either directly with the server, or via the Gateway. Any gateway used will be based on the Settings in the Project for the relevant server.

    The Okta Privileged Access team will interact with the other cloud services to raise access requests, consume users and groups from Okta WIC and write audit events to the Okta System Log.

    Communication Protocols and Ports

    The port requirements are listed in the product documentation – https://help.okta.com/en-us/content/topics/privileged-access/pam-default-ports.htm. 

    The following figure summarizes the protocols and ports used.

    All of the cloud components communicate over HTTPS, using port 443. When the infrastructure components communicate with the Okta Privileged Access team, they use HTTPS to port 443.

    The gateway service (“sft-gatewayd”) is listening on port 7234. If the client is to connect to a server via the gateway (based on policy) the client will connect over SSH to the gateway on port 7234.

    The agent service (“sftd”) is listening on port 4421. If a connection involves just-in-time provisioning, the client (optionally via the gateway) will connect to the agent on port 4421 to check if the account is there and trigger provisioning. 

    If the target server is a Microsoft Windows server, the client (optionally via the gateway) will also establish a SSH tunnel (mTLS) to the server (the agent in this case will act as the ssh daemon listening on 4421). The RDP session will be established as a localhost connection on the server to port 3389. See also https://help.okta.com/en-us/content/topics/privileged-access/pam-windows.htm. 

    If the target server is a Linux server, the client will establish a ssh connection from the local (workstation) ssh client to the ssh daemon on the server. This is a standard ssh connection to port 22 on the server.

    Note that the gateway and agent listening ports can be configured. Also, the arrows in the figure going to the Agent (B, C, D, E) could terminate at the server or agent depending on the flows described above.

    Troubleshooting the Cloud Services

    The three cloud services, the Okta WIC org, the Okta Privileged Access team, and the Okta Access Requests platform instance, are closed applications hosted by Okta. 

    The only logging that is available to users is the Okta System Log. Events from the three platforms are written here and can be used to check activity and timestamps. Note that All Okta Privileged Access events have an EventType that begins with “pam”.

    Expanding an event shows key event information, including the team, project and user.

    Expanding all for an event shows a wealth of information, including the DebugData that is often very useful to determine what was going on. In the following example, you can see the policy being used, the target system, and MFA challenge info and the access method (“sally via RDP (admin level individual account)”).

    This information can be useful in debugging issues with policy configuration. Similarly if you suspect issues with MFA or access request conditions, you should see events in the system log corresponding to those activities.

    Troubleshooting the Client

    The infrastructure components are the client (“sft”), server agent (“sftd”) and gateway (“sft-gatewayd”). Let’s look at the client first as it will often be the where issues with connecting to a server show up.

    Verifying the Client Version

    With the constant rate of change of functionality, it’s not uncommon for failures to be due to an old version of the client. Before starting debugging you should check the client is at the appropriate version (preferably the latest version).

    The client version can be confirmed by running the sft -version command in a command window.

    larry@larrys-desktop:~$ sft -version
    sft version 1.84.0

    Workstation platforms like Windows and MacOS may have other means to check the version (such as the ScaleFT icon on the task bar).

    Client Logs

    On a Mac or Linux system you should see logs in <user>/Library/Logs/ScaleFT/sft or equivalent (e.g. <user>/.cache/ScaleFT/logs/sft). On a Windows system you should see the logs in <user>\AppData\Local\ScaleFT\logs.

    Client Command Debugging

    You can also run the sft client in debug mode by setting the SFT_DEBUG environment variable before running any sft command.

    On Windows workstations:

    In Powershell
    PS> C:\Users\<user>> $env:SFT_DEBUG="1"
    PS> C:\Users\<user>> sft rdp <server_name>

    # Windows CMD
    C:\Users\<user>> set SFT_DEBUG="1"
    C:\Users\<user>> sft rdp <server_name>

    On Linux workstations:

    larry@larrys-desktop:~$ SFT_DEBUG=1 sft rdp <server_name>

    You can set this for any sft command (example below is on a MacOS workstation).

    david.edwards@N3F4YXC99J ~ % SFT_DEBUG=1 sft list-servers

    2024-10-01T14:20:57.501+1000 INFO sft command {"version": "1.83.5", "pid": 35101, "args": ["sft", "list-servers"], "log_directory": "/Users/david.edwards/Library/Logs/ScaleFT/sft"}

    2024-10-01T14:20:57.519+1000 DEBUG macOS User Defaults check returned error {"error": "exit status 1"}

    2024-10-01T14:20:57.743+1000 INFO RecordSpan {"tags": null, "operation": "device.cloud.info", "start": "2024-10-01T14:20:57.743+1000", "duration": "4.292µs", "traceID": 1907366058819643408, "t": "trace", "spanID": 2600321935164281505}

    2024-10-01T14:20:57.775+1000 INFO RecordSpan {"t": "trace", "traceID": 1907366058819643408, "spanID": 2043889579375440998, "tags": null, "operation": "device.mac.filevault", "start": "2024-10-01T14:20:57.743+1000", "duration": "31.972416ms"}

    With SSH commands you can also pass the debug argument (-v = debug level 1, -vv = debug level 2 and -vvv = debug level 3) if you have aliased ssh to run via sft. For example:

    larry@larrys-desktop:~$ ssh -v opa-demo-linux
    OpenSSH_8.6p1, Ubuntu-3ubuntu0.10, OpenSSL 3.0.2 15 Mar 2022
    debug1: Reading configuration data /home/larry/.ssh/config
    debug1: Executing command: '/usr/local/bin/sft resolve -q  opa-demo-linux'

    If you need to log a ticket with Okta support, there are sft support collect and sft support submit commands. There are equivalent commands for the other infrastructure components – https://help.okta.com/en-us/content/topics/privileged-access/pam-get-support.htm. 

    Troubleshooting the Agent

    The agent may be called the “agent”, the “server agent”, or identified as “ScaleFT Server Tools”. The process/daemon is sftd.

    Verifying the Agent Version

    With the constant rate of change of functionality, it’s not uncommon for failures to be due to an old version of the client. Before starting debugging you should check the client is at the appropriate version (preferably the latest version).

    On Windows servers you can view the Control Panel > Programs > Programs and Features window and find ScaleFT Server Tools.

    On both Windows and Linux you can check the log files (see next section) and look for the last log entry with “sftd: Starting”. It will list the version.

    The sftd binary also supports a sftd -v (or –version) option.

    Agent Logs

    On a Windows server the logs files can be found in: C:\Windows\System32\config\systemprofile\AppData\Local\scaleft\Logs\sftd

    On Linux systems the native system logging mechanism is used and can be different depending on the platform. From a colleague “When the agent is installed on a Linux server, it identifies if the server is running systemd (RHEL7+, etc.), and specifically the journald component of systemd. If it finds journald, the agent will use systemd-journald.service for logging. If systemd is NOT present, it will fall back to whichever syslog server is available, i.e. syslog-ng or rsyslog”.

    For most Linux servers you can use the journalctl -u sftd command to see the logs. Otherwise, look in the /var/log/sftd folder.

    You may also find useful information in system/security logs. For example, the following is from the /var/log/auth.log on an Ubuntu system and shows both sftd (user creation) and user activity via ssh.

    System logs like these may help with adding context to the system logs for the sftd process. If you have a SIEM you should capture these system logs as well as the sftd process logs and correlate the events.

    Setting the LogLevel for Agents

    The logging level is set to info by default, but can be set to any one of warn, info or debug (increasing levels of verbosity). This is controlled by the LogLevel option in the sftd.yaml file. The location of the configuration file depends on the operating system running the server agent (it can be created if it doesn’t exist).

    • Linux: /etc/sft/sftd.yaml

    • Windows: C:\Windows\System32\config\systemprofile\AppData\Local\scaleft\sftd.yaml

    You may need to restart the sftd process to get the new log level setting. 

    Troubleshooting the Gateway

    Gateways may be used to route traffic between clients and servers, and also perform additional functions like session recording. 

    The gateway is software running on a Linux server and has its own process – sft-gatewayd.

    root@ip-172-31-26-3:/home/ubuntu# ps -ef | grep gateway
    root       363     1  0 03:45 ?   00:00:10 /usr/sbin/sft-gatewayd service
    sft-gat+   698   363  0 03:45 ?   00:00:18 /usr/sbin/sft-gatewayd proxy --log-level info

    Verifying the Gateway Version

    As with the other components there is a command to check the version:

    root@ip-172-31-26-3:/home/ubuntu# sft-gatewayd -v
    sft-gatewayd version 1.83.1

    You can also look in the logs for the last “service starting” message to get the current version.

    … sft-gatewayd service starting        {"version": "1.83.1"}

    Gateway Logs

    As with the agent on Linux, the gateway logs are viewed using the journalctl command – journalctl -u sft-gatewayd.

    The logs are a rich source of information on all traffic flowing through the gateway and will often pinpoint connection errors. There may be some spurious ERROR messages relating to the config file and setup token, but you can generally get a lot of information about the user and the connection from the client to the server.

    Setting the LogLevel for Gateways

    The logging level is set to info by default, but can be set to any one of error, warn, info or debug (increasing level of verbosity). This is controlled by the LogLevel option in the /etc/sft/sft-gatewayd.yaml file (it can be created if it does not exist).

    To restart the service, use the systemctl stop sft-gatewayd and systemctl start sft-gatewayd commands.

    What About Specific Issues?

    As mentioned at the outset, this article is meant to help you diagnose issues, not list the common problems. If you encounter a problem it’s worth Googling any error messages you see. 

    There is a dedicated Okta Privileged Access tag in the support knowledgebase – see https://support.okta.com/help/s/topic/0TO4z000000a942GAA/okta-privileged-access?language=en_US.

    Two particularly useful support articles:

    The suggested approach to any debugging exercise is:

    1. Check the versions of the different components

    2. Google the error message returned by the client

    3. Check the gateway logs if the gateway is in the flow – this log is the most useful in debugging

    4. If there isn’t a gateway, or it doesn’t help identifying the issue, look at the agent logs

    Conclusion

    This article has provided a guide to troubleshooting Okta Privileged Access. It has looked at the architecture, components and flows to help you zero in on the problem area. It has explored the logging and files that can be used for troubleshooting. 

    Hopefully you won’t need to use the information in this article, but if you do it should help you identify the issue and continue using Okta Privileged Access. We recommend you have a look at your environment and explore the process and logs to understand how the components are working together.

  • New Features for the Access Request Conditions and Resource Catalog in Okta Identity Governance

    Two new features have been introduced into the Access Request Conditions and Resource Catalog (aka RCAR) feature in Okta Identity Governance – Request on Behalf Of, and User-specified Access Duration. This article introduces these new features.

    Request On Behalf Of

    Okta Identity Governance introduced the ability to request access on behalf of another user into the older Request Types mechanism a while back. It has now been added to the newer Access Request Conditions and Resource Catalog feature.

    This option is turned on at the application level – you don’t need to enable it across all apps. When you go into the Access requests tab for an app, you will see a new Settings button.

    There is currently only on setting – Request on behalf of. When you enable it you are presented with two options – manager-only (i.e. a manager can request for their direct reports, based on the manager settings on user profiles) or anyone. The description is basically saying the requester must have the ability to request a app/group/entitlement that they are requesting for the requestee.

    When a user (manager or anyone depending on the selection) selects an app and access level they can select who the access is for (including “Yourself”, the default value).

    From here it will follow the standard steps in the Sequence associated with the Request Condition.

    Even though the access has been requested by someone else, the request flowing through the Access Requests platform is treated as if it was raised by the requestee not the manager. So even if the manager had initiated the request, if there was a manager approval step in the flow, then the same manager would need to approve it.

    The following figure shows a request raised by a manager (Monty), but is assigned to the requestee (Homer) as the requester. There is no indication it was requested by the manager.

    Note that the settings apply to all Conditions for an app. There’s no way to apply request on behalf of for specific Conditions.

    User-specified Access Duration

    The second new feature is the ability for users to specify a duration for a requested access. Prior to this, the access duration was fixed within the Condition. Now there is an option to Ask requester to specify expiration.

    When that option is selected, the administrator must specify a Maximum duration to limit the time the user can set.

    When a user requests access, they see an additional set of fields For how long do you need access. This will control the timer duration built into the Condition.

    These two additions are bringing parity from the old Request Type mechanism in Access Requests to the newer Access Request Conditions and Resource Catalog mechanism as it approaches General Availability later in the year.

    For more information on the Access Request Conditions and Resource Catalog feature, see this introduction document on the Okta Identity Governance Product Hub. There is also an earlier post looking at Okta Privileged Access and the new feature, titled Managing Access in Okta Privileged Access with the new OIG Resource Catalog.