Integrations

Why Provisionr focuses on IdP-level integrations and what we connect to.

Many vendors have dozens or hundreds of integrations. Since we manage group and resource memberships, our focus is on integrating with vendors that manage access to those integrations, usually at the Identity Provider (IdP) level. You can learn why in the Identity Governance Landscape docs.

Our primary focus is on companies that use Google Workspace and Okta. You can learn why in our Product Mission.

Think of how many thousands of services you can integrate with Google. Okta has 7,000+ pre-built cloud and on-premise application integrations and 1,300+ SAML/OIDC integrations.

Provisionr manages access to the Google and Okta groups that grant access to those downstream applications, so we don’t need thousands of integrations ourselves, we simply provision the authorization policies for the integrations that you’re already using and trust.

We’ve also built integrations with GitLab and Slack. We were administrators of those systems and our policy engine was designed to handle provisioning for these systems elegantly.

Google Workspace

Google Groups are one of the foundational building blocks of using Google. They can be used to grant access to mailing lists, shared calendars, shared drives and folders, Google Docs/Sheets/Slides and uploaded files, GCP folders, GCP projects, assigning to Google Workspace organization units, and much more. Since Google Workspace also acts as an IdP, many systems connected using SAML/SSO can fetch group memberships to determine what the user should have access to when signing in with SSO.

Google has two different types of groups:

• Google Workspace Groups
• Google Cloud Identity Groups

If you do not know the difference, assume that you are using Google Workspace Groups.

Provisionr supports both types of groups and they use the same underlying policy engine. You can use either one (or both) as needed based on business needs. Keep in mind that Google Workspace Groups and Cloud Identity Groups are separate products as far as the API is concerned, so although they are similar in behavior, they cannot be “linked”.

You can assign a Google Workspace Group and/or a Google Cloud Identity Group to most resources in Google which is useful for Google Cloud and Google Drive resources.

A group is useful for granting multiple users or a named job role to Google resources. If you’re used to inviting a user based on their email address to specific resources, you can use Provisionr to add them to the policy using different methods:

• Create a rule for a specific user ID
• Create a rule with one or more conditions based on user attributes

The benefit of the condition approach is that users will be deprecated/removed when their attributes no longer match. This handles job changes gracefully. If a user is added based on their ID, they will only be removed when they are no longer employed or their IdP account is deprovisioned.

Provisionr can manage policies for the following Google resources:

• Google Cloud
  • GCP Folders — Inherited access with role(s) to any child folders and GCP projects.
  • GCP Projects — Least privilege access for specific team members based on their job role.
• Google Drive
  • Shared Drives — Automatically grant access during onboarding or job role changes.
  • Drive Folders — Grant higher-level role access to specific folders within a shared drive.
  • Drive Files — Grant explicit access to uploaded files (ex. read-only to a new HR policy).
  • Google Docs, Sheets, and Slides — Enable a Provisionr policy on any document to automatically grant access to users that match rule conditions.
• Google Workspace
  • Workspace Groups — The primary resource managed by Provisionr for Google.

For auth setup and credentials, see the Google Auth docs.

Okta Workforce Identity

Okta Workforce Identity is designed to allow users to see a dashboard of applications that they can access. When they click on the application tile, they will be redirected to the vendor and automatically authenticated since Okta has been configured as the Identity Provider (IdP).

Provisionr helps your Identity, IT, and/or Security team manage which application tiles that users can see based on their attributes and profile metadata. This is particularly useful for teams that have outgrown string matching group rules.

You can take three different approaches to managing users assigned to Okta applications:

• Existing Groups — If you have existing Okta app groups that you would like Provisionr to manage, you can change the UNMANAGED state to MANAGED state. This is the most common place that customers start when adopting Provisionr. When you first start managing an existing Okta group, you will keep the group in a non-authoritative state to ensure that changes are only additive. As you feel more comfortable with your policy, you can see a list of existing group users that do not match the policy and choose to add them or take no action. If you take no action and change the group to authoritative, those users will be removed. See the Okta Groups docs.

• Application Groups — When you connect Provisionr to Okta, we read a list of all of the Okta applications that you have configured. When you’re ready to manage users for an Okta application, Provisionr will create a new Okta App Group that you can start adding rules to. We do not manage the users assigned to the application itself — we only manage which users are assigned to the App Group that grants inherited access. This allows you to make a two-way door decision easily by attaching or detaching that group from the application. See the Okta Apps docs.

  Provisionr does not have any knowledge of your SAML/SCIM configuration, and only manages which users are assigned to the Okta App Group.

• Attribute Groups — Provisionr can automatically create an App Group for every one of your dimension attributes (ex. a group for Engineering Department or IT Security Team). Provisionr will manage the members based on the ruleset for each attribute. You can manually attach/detach one or more of these groups to/from applications as needed.

For auth setup and credentials, see the Okta Auth docs.

GitLab

Provisionr integrates with GitLab to grant users access to groups and projects with specific permission roles.

• GitLab Groups — Grant access to the parent “folder” with a specific GitLab permission role, providing inherited access to any child groups and project repositories. You can also manage members for membership-only groups used for CODEOWNERS, Merge Request Approvers, and tagging in issue and merge request comments.
• GitLab Projects — Grant access to specific project repositories with a specific GitLab permission role. This is useful for engineering teams that should automatically be granted access to the repositories that their team works on, or for providing read-only access to a wider range of users.

For auth setup and credentials, see the GitLab Auth docs.

Slack

Provisionr integrates with Slack to manage user groups for channel tagging and onboarding automation. See the Slack Groups docs.

For auth setup and credentials, see the Slack Auth docs.

Workspace Integrations

Your organization may have multiple deployments, environments, or instances for each vendor. Each is configured as a Workspace Integration in Provisionr with its own URL and/or API credentials.

By configuring multiple integrations, we can enrich the metadata that we have for each user with profile data from each integration. This also improves onboarding and offboarding automation since we can see user identities across all of your configured integrations.

Primary Integration

Provisionr uses a primary integration to establish the baseline identity for a user — their name, email address, and employment lifecycle state (active or deprovisioned). This is usually your single sign-on (SSO) vendor that is already connected to your HR Information System (HRIS).

After you create the Workspace Integration and configure the API credentials, Provisionr imports all of the users. You can configure which Directory User profile attributes to populate from this integration. Any changes to user attributes are detected during recurring sync jobs.

Users that are onboarding (joiners), have job or role changes (movers), or are offboarded (leavers) are detected during the sync and trigger audit and automation workflows.

Additional Integrations

Each additional integration that you add provides several benefits:

1. Aggregate user profile attributes from different integrations into a single unified Directory User profile
2. Automate IAM and RBAC provisioning and deprovisioning tasks across more systems
3. Monitor changes across multiple systems for audit and compliance