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 groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with 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 orgThe Okta container that represents a real-world organization. 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.
Groups are used in almost every IT department. This document clarifies how groups work in Okta.
Note: When searching for a group on the Groups (Directory > Groups) page of the AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. 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.
The following table describes Okta group types.
|Native Okta groups||
Before you connect Okta to applications or other resources, you can create groups in your Okta org. The default group Everyone contains all users in your Okta org.
To manage your Okta groups, sign in to your Okta Admin Console and click Directory > Groups.
|Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. groups||
Active Directory (AD) is the most common source for groups. Nearly every business of significant size uses an AD instance to manage users. You can use the Okta AD agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. integrate your AD instance with Okta.
Note: Okta does not support DomainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). Local Groups containing members from multiple domains. We do support Universal Security Groups with cross-domain membership if there is a two-way trust established between the domains. Universal Security Groups do not support cross-forest membership.
|LDAPLightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. groups||You can use the Okta LDAP agent to import groups from LDAP-compliant Windows and Unix servers. For supported LDAP distributions, see LDAP Agent Deployment Guide.|
Some applications have groups that you can import into Okta. The ability to import these groups depends on whether or not the groups can be accessed through an API and if the application has been integrated with Okta. These are a few of the applications that support group import:
You can use AppAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. Sign On Rules to deny access to apps if users are not accessing them from a particular network location, or enforce the use of multifactor authentication (MFA). When you define an app sign on rule, you can limit its scopeA scope is an indication by the client that it wants to access some resource. 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 is useful to allow a small group of users to 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.
You can push groups from Okta to other connected applications and directories such as Box and AD. These are a few of the applications that support group push:
- Active Directory
- Office 365
Groups are pushed to applications using one of the following two methods:
- By name: An Okta application administrator selects groups from Okta to be created and updated in the target app.
- By rule: You use a string in either the group name or description to push many groups at once. Group push by rule is not available for AD integrations.
Using SAML JIT group provisioning
You can provision groups during the SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IdP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. 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. For more information, see Manage groups with Box.
This image shows the location of the Push Groups via SAML option:
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.Top