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 (Directory > 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.
You can also use this feature to exclude groups. This feature lets a group of users access apps from anywhere, but it is recommended that users should be on your corporate network. See Application Level Multifactor Authentication.
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.
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 in Box.
- Manage group membership in Box.
Essentially 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.