To access network-based services including email, file servers, and business applications, every user must be authenticated. Managing user access individually is time consuming and inefficient. Using groups can help you simplify user management as changes to group access rights are automatically applied to all members of the group.
You can group users based on common or shared traits. For example, to make it easier for your sales team to access shared sales documentation, you can create a group named Sales and grant group members access to the Sales Documentation folder on your org file server.
Groups are important tools for identity management systems, and group data typically resides in a directory. Most applications support groups, either at the application level, or within the application to specific resources.
When searching for a group on the Groups ( ) page of the Admin Console, you can search for a group by full or partial group name. If you search for a partial group name, only those groups matching the prefix are returned. For example, if there is a group named Group 1 and you enter 1 as the partial search term, no results are returned. If you enter Group as the partial search term, all groups beginning with Group are returned.
You can use App Sign On Rules to restrict access to apps to a specific network location, or enforce the use of multifactor authentication (MFA). You can limit the scope of an app sign on rule to a group. You can configure policies to implement MFA for remote, temporary, or contract employees.
Groups in applications and directories
With Okta, you can define group membership in one directory and then use your groups in multiple connected systems. In on-premises systems, applications can connect to and query for groups from a central directory. Cloud applications often lack a common Active Directory, but the Okta push groups feature lets you use groups with these types of applications.
Okta automatically adds all administrators 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.
The Okta Administrators group can only be assigned to sign-on policies, not apps. All admins can see this group, but it can only be used by a super admin who sets the global policy. Due to security reasons, the member counts are not 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 is 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 is available as part of the SAML template. If your target application accepts group information by SAML, you can configure a template without requiring an engineering effort to implement group push.
These use cases demonstrate how Okta can help you manage groups.
Provision users in target applications
Applications that support provisioning can use group membership to determine which user accounts are created, updated, deleted, or deactivated. After you have configured provisioning, assign a group to your application. Members of the group are automatically created in the target application.
Some services have additional data that you can assign to a newly created user. For example, when you assign a group to a Salesforce application 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 are assigned to collaboration folders.