Skip to content
Help Center

Securing high-risk actions in Workforce integrations

View Markdown Contact support Contact support 4 min read
On this page

Overview

Workforce and identity and access management (IAM) integrations, such as Okta, Microsoft Entra, Auth0, and PingOne, let your Workflows make changes to the users in your IAM. Some of these actions are powerful. If a Workflow sends them the wrong input, an attacker can take over a user, get more privileges than they are entitled to, or get back access that you removed.

The risk usually does not come from the action. It comes from the inputs. An action is only as safe as the values that tell it which user, group, or role to change, and where to send a credential.

The Workflow editor labels each of these actions with its risk category. When you add a step that has a label, examine how the step gets each of its inputs, and use the guidelines below.

A risk label does not mean that the action is unsafe to use. It means that a mistake in how you configure the step has a high cost.

Risk categories

Account takeover

An action in this category can give a person a way to sign in as a user. If the wrong person gets it, that person controls the user.

  • Issue a temporary access code, a Temporary Access Pass, or a temporary password.
  • Create a password reset link, a recovery link, or an invite link.
  • Remove or reset the MFA factors of a user. After this, a person who knows the password can enroll their own factor. This is an MFA bypass, which is a form of account takeover.
  • Change the email, phone number, or login of a user. Password resets and MFA enrollment then go to the new value.

Privilege escalation

An action in this category gives a user more access than they had before.

  • Add a user to a group, a role, or an organization membership. The user gets all of the applications and permissions of that group or role.
  • Grant just-in-time access.
  • Create or change a SCIM or provisioning configuration. These changes apply to the full tenant, not to one user.

Unauthorized access

An action in this category gives access to a person who does not have it now.

  • Restore access that an administrator removed on purpose: unsuspend, reactivate, unlock, enable, or activate a user. For example, the user of a former employee, or a user that your security team suspended during an investigation.
  • Create a user.

Guidelines for safe Workflows

Use only trusted inputs

Each parameter of a high-risk action must come from a source that you trust. A parameter is any value that the action uses, for example the target user ID, an email, a group, or a role. Do not use a value that the end user entered, or a value that the end user can change.

Get the data that you need directly from your IAM. Write it to the Persona Account, and use the values from the Account in the high-risk step. Do not write IAM data to an Inquiry field. Inquiry fields are made to be changed from the client, so the end user can change a value after your Workflow writes it.

Make sure that the verified person owns the user

Public flows, for example account recovery, must ask the end user for an identifier, such as their email or login. Persona needs it to find the user in your IAM. An attacker can try to use this. They enter the email of their own user, pass identity verification, and then change the email to the email of a different employee. If the Workflow reads the email again after verification, it acts on the user of that employee.

To prevent this:

  • Look up the IAM user from the identifier before verification, and write the IAM user ID to the Account.
  • Compare the verified identity with the IAM profile of that user, for example the name on the government ID with the name in the IAM.
  • In the high-risk step, use the IAM user ID from the Account. Do not use the identifier that the end user entered.

Do not let the end user choose a group or role

For actions that change users, roles, or groups, set the target group or role in the step configuration. Do not let the end user set it. If the end user can set the target, they can add themselves to an admin group, provision an admin user for themselves, or get other privileges that they are not entitled to.

Protect the attributes that recovery uses

Actions that change a user profile can change the email, phone number, or login of the user. If an attacker can set the new value, they can change the email to an address that they control. Then password reset emails, recovery links, and MFA enrollment go to the attacker. Change these attributes only with values from a trusted source, and only after you verify the owner of the user.

Plans Explained

Workforce Integrations by plan

Startup ProgramEssential PlanGrowth PlanEnterprise Plan
Workforce IntegrationsNot AvailableNot AvailableLimitedAvailable

Learn more about pricing and plans.

Last updated on .

Was this page helpful?If something is missing, let us know and we will take a look.
Thanks for the feedback. It helps us improve these docs.