When you add a user in Okta, you are creating a user account—or user profile, for the user in the Universal DirectoryUniversal Directory enables you to store an unlimited amount of users and attributes from applications and sources like AD or HR systems. Any type of attributes are supported including linked-objects, sensitive attributes, and pre-defines lists. All of it accessible by all apps in our OIN catalog, over LDAP or via API.. Universal Directory is the user store for all Okta users.
User accounts often originate in a third-party 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.. During provisioning, if an existing app user account matches an Okta user account, then the Okta account and app account are matched and linked.
The method used to manage (master) users is determined by how user data is added to Okta. Three methods are available to create user profiles: manually, importing from a directory or application, or importing from a CSV file.
Manually create user profiles
Users manually created in Okta are mastered by Okta and Okta is the single source of truth for these users. User data is managed or "mastered" in Okta and Okta is the most current source for user data.
For example, if you integrate with Salesforce for provisioning, users created in Okta are pushed to Salesforce, but are managed in Okta. Updates and terminations made in Okta are reflected in Salesforce (and any other integrated, third-party application that’s part of the process). This downstream connection lets you to have a single source of truth, where any changes made in Okta are reflected in Salesforce. As the single source of truth, Okta manages employee and contractor access to applications.
Okta pushes user information to the integrated, third-party application, which results in the creation of a user account within the application.
When user account information is updated in Okta, this information is pushed to the integrated, third-party app where the application user account is also updated.
Import user profiles from a directory service or app
User data can be imported into Okta from:
- Directory services such as 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. or 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.. See Manage Active Directory users and groups.
- Human resources applications such as Workday. See Workday Provisioning.
- Customer relationship management (CRM) applications such as Salesforce. See Enable Salesforce provisioning.
- Application suites such as Microsoft Office 365. See Provision users to Office 365.
Users created in a directory service or integrated, third-party application are pushed to Okta and new AppUser objects are created, for matching against existing Okta user accounts, or creating new Okta user accounts.
Profile Mastering is a more sophisticated process for importing user data and makes an application or a directory the source of truth for user attribute information. Profile Mastering defines the flow and maintenance of user-object attributes and their lifecycle state. When a user profile is mastered from a directory or application, the Okta user profile’s attributes and lifecycle state are derived exclusively from that resource. An Okta user mastered by an application or directory has an Okta profile, but the profile cannot be edited in Okta and all user information is derived exclusively from the application or directory. If the user profile in the application or directory is disabled, the linked Okta user profile moves to the Deactivated lifecycle state on the next import.
You can use the Import User Schema feature, or Schema DiscoveryAbility to import additional attributes to Okta, to import additional user attributes from apps such as Salesforce.
Use one of the following integration strategies to import user data:
- Active Directory (AD) integration.
- LDAP integration
- Application integration
- JIT provisioning
Use the Okta Active Directory (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. to synchronize user data between Okta and your AD instance. You can set up Real-time Synchronization and Just-In-Time (JIT) ProvisioningProvisioning is the enterprise-wide configuration, deployment, and management of multiple types of IT system resources. Specifically, provisioning provides users access to equipment, software, or services. This involves creating, maintaining and deactivating required business process automation objects and attributes in systems, directories, and applications. to make sure that the user profiles remain current without the need to wait for a scheduled import.
Use the Okta LDAP agent to synchronize user data between Okta and your LDAP instance. You can set up Real-time Synchronization and Just-In-Time (JIT) Provisioning to make sure that the user profiles remain current without the need to wait for a scheduled import.
Integration with applications such as Salesforce or Workday is useful when you want to make the application the single source of truth for user data. AD becomes a downstream provisioning target. This feature provides ongoing profile synchronization and ensures efficient on-boarding.
User accounts are automatically created in Okta the first time a user authenticates with AD Delegated AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect., Desktop SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones., or inbound 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..
Import users from a CSV file
Users are imported from a CSV file and managed in Okta. Any user profile changes are pushed to integrated, third-party applications.
User lifecycle changes such as a position change, app license expiration, or employment termination trigger certain provisioning functions that change the user's lifecycle state.Top