Groups and Resources

Vendor Resources

Access Control allows you to manage users for the following vendor resources:

• AWS
  • IAM Group
  • Identity Center Group
• GitLab
  • Group Member (with Role)
  • Project Member (with Role)
• Google Cloud
  • Identity Group
  • Organization (IAM User with Role)
  • Folder (IAM User with Role)
  • Project (IAM User with Role)
• Google Workspace
  • (Shared) Drive Sharing
  • Group
• Okta
  • App
  • Group
• Slack
  • Channel
  • Group

:::tip Getting Started

If you’re just getting started. We recommend that you start with managing Google Workspace groups, Okta apps, and/or Okta groups. You can expand to other resources as your needs evolve and you become more comfortable.

:::

Groups vs Resources

A Group (ex. an Google group or Okta group) is one type of resource, and is the most popular type of resource managed by Access Control.

Throughout the docs, we may refer to groups or resources interchangeably as you learn about the various concepts, however the logic applies the same and is officially known as a resource.

Controlled Resources

When the Vendor Source is synced, all existing resources (ex. Okta Groups) are imported into Access Control with read-only visibility for the group and its members.

When a resource is imported into Access Control, the control_enabled boolean is false.

When you’re ready to manage the resource users (ex. Okta Group members), Access Control needs to know which users that should have access (a.k.a. be provisioned as members). This is defined using a Ruleset, which is our term for a membership criteria policy.

A Ruleset has a pre-calculated list of users based on the rules and conditions that you configure that use one or more of each users’ profile attributes.

Each Vendor Resource requires one or more Rulesets to be attached before you can change control_enabled to true and enable the automatic provisioning and deprovisioning of users for this resource. When set to true, this vendor resource becomes a Controlled Resource.

Vendor Sources

A Source is a unique connection or instance for a supported vendor that you provide service account API credentials for Access Control to use.

You may already be familiar with Directory Sources. A Directory Source is used for getting user attribute metadata from the respective vendor API (ex. Google Users or Okta Users).

When you’re ready to start managing Okta Groups, Google Groups, GitLab Groups, Slack Groups, and other resources that Access Control supports, you will create a Vendor Source for each of the respective vendors.

If you have multiple environments/instances of a vendor (ex. different domains or subdomains or account/customer/organization IDs), you will create a source for each one that you want to manage with Access Control. You can iteratively add each Source. If you’re not ready for your larger production environment, you can start with your staging or test environments or a specific team’s environment.

Vendor Resources

When you created the Vendor Source, all of the existing supported resources are imported into the Access Control database for visibility.

Access Control provides read-only analytics insight about the members of your existing resources. This allows you to see what dimensions and attributes that users have, and Access Control provides a recommended Ruleset if you want to start managing the resource with Access Control as a Controlled Resource.

You must manually enable (opt-in) for each resource that you want to be controlled by Access Control.

If a group is imported that you do not want visible in Access Control, you can soft delete the group, and all members will be permanently deleted from Access Control (not on the vendor side). The soft deleted record is preserved to prevent Access Control from trying to reimport that group in future sync jobs.

We do not use the term Vendor Resource in the API or database. This is referring to the overarching concepts that are shared by each vendors resources.

You will find these resources in the respective vendor namespaces.

Table	Endpoints
gitlab_groups	/api/v1/gitlab/groups
google_workspace_groups	/api/v1/google-workspace/groups
google_cloud_groups	/api/v1/google-cloud/groups
okta_groups	/api/v1/okta/groups
slack_groups	/api/v1/slack/groups

Controlled Resources

A Vendor Group is the most popular type of resource that you can manage with Access Control.

You can create new groups in Access Control that are pushed to the vendor. These are considered Controlled Resources from inception.

You have visibility into all of your existing groups, and you can take control of an existing group by changing control_enabled from false to true after you attach one or more Rulesets to start managing the members of the group.

As mentioned previously, the Rulesets that you attach to the group are culminated together to dynamically calculate the manifest of users that should be added as members of the group.

The culminated manifest of users are synced with the Vendor Group using the respective vendor group member API endpoints.

Authoritative Resources

Each Controlled Vendor Group has an authoritative_enabled boolean flag.

If a Controlled Vendor Group is not authoritative, any users on the manifest will be added to the Vendor Group, however any users that are no longer part of the manifest (ex. Attributes changed so no longer matched a Rule’s Conditions) or are pre-existing group members for an imported Vendor Group will not be removed. This can lead to an inconsistent state and complicate role changes and offboarding. This can be helpful for initial control of groups where you want to avoid breaking changes and ensure that users that don’t match the policy are reviewed and avoid removing their access automatically.

If a Controlled Vendor Group is authoritative, only users on the manifest can be group members. Any manifest users that are not vendor group members will be added, and any users that do not exist on the manifest or were recently removed will be removed from the group. If attribute and job role changes should automatically remove users from a group, it should be authoritative so the Ruleset manifest changes can trigger the automation to remove the user from the group.

You will choose whether a Resource is authoritative when you enable Control. You can enable or disable whether a Controlled Resource is authoritative at any time thereafter, either temporarily or perpetually. In other words, it is okay to not be authoritative in the beginning, however as a best practice you should enable authoritative at some point in the future.

You can read more about manifest member expiration to see how Access Control provides a deprecation grace period for job role changes without being disruptive to the user. The summary is that you can configure the number of days (default: 30) after a user is no longer eligible before deprovisioning their access. This covers job role changes and provides IT and Security teams a grace period to evaluate attributes that were renamed or removed (ex. during team realignments) and take action to update attribute or string matching conditions for your rulesets.