Groups

Groups enable you to simplify user management. Instead of assigning users to apps individually, you can assign users to a group, and then you can grant or deny access to a resource to the group. When access rights for the group are changed, those changes are automatically applied to all members of that group.

You can group users based on common or shared traits, like the department a group of users belongs to, or members of a project team. For example, you can create a group named Sales and grant those users access to a shared folder, like Sales Documentation.

Groups are important tools for identity management systems, and group data typically resides in a directory. Most apps support groups, either at the app level or within the app to specific resources.

You can search for a group on the Groups page at DirectoryGroups by full or partial group name. Okta displays the names of groups that match what you enter in the search field and returns only groups that match the prefix. For example, if there's a group named Group 1 and you enter 1 as the partial search term, Okta returns no results. If you enter Group as the partial search term, Okta returns all groups beginning with Group.

App sign-on policies and rules

App sign-on policies let you restrict access to apps. You can allow or deny access to groups that you specify, and enforce the use of multifactor authentication (MFA). If you have remote, temporary, or contract employees, you can create a group for each category and then configure different rules for each group.

Groups in apps and directories

Okta lets you define group membership in one directory and then use your groups in multiple connected systems. In on-premises systems, apps can connect to and query groups from a central directory. Cloud apps often lack a common Active Directory (AD) resource, but the Okta push groups feature lets you use groups with these types of apps.

Okta admins

Okta automatically adds all admins of your org to a group called Okta Administrators. The Okta Administrators feature allows you to create new sign-on policies that automatically apply to all admins in your org.

You can only assign the Okta Administrators group to sign-on policies, not apps. All admins can see this group, but only a super admin who sets the global policy can use it. Due to security reasons, the member counts aren't displayed for this group.

SAML JIT group provisioning

You can provision groups during the SAML sign-on process. This is recommended when you want to do the following:

  • Add users to pre-existing groups
  • Create new groups
  • Manage group membership
    There's no provisioning configuration. Group information is sent in the SAML assertion when the user signs in to a target app. This is less flexible than group push, in which you must use regular expressions to filter the groups you want. The advantage of this method is that it's available as part of the SAML template. If your target app accepts group information by SAML, you can configure a template without requiring an engineering effort to implement group push.

Use cases

These use cases demonstrate how Okta can help you manage groups.

Provision users in target apps

Apps that support provisioning can use group membership to determine which user accounts are created, updated, deleted, or deactivated. After you configure provisioning, assign a group to your app. Okta automatically creates group members in the target app.

Some services have other data that you can assign to a newly created user. For example, when you assign a group to a Salesforce app with provisioning enabled, you can choose the Salesforce roles and profiles that are assigned to users in the group.

Map AD groups to Box folders

A company using AD groups to control access to files is migrating to Box for file sharing. Folders are created in Box that reflect the same or a similar hierarchy to the on-premises file server. Groups are imported into Okta and then group push is used to send the groups to Box where they're assigned to collaboration folders.