To better grasp Okta 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., it's helpful to understand user management in Okta and how apps are configured and users are assigned to them.
The Okta Provisioning workflow begins with user management. When you add a user to 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.. This 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 account already exists in the app that matches the one in Okta, then the Okta account and app account are matched and linked.
Users are managed (mastered) based on the method used to add them to Okta. The following are the possible methods:
Manually creating users in Okta
Users manually added in Okta are mastered by Okta and Okta is the single source of truth for these users. This means Okta manages or "masters" the user information, making this information the most current "source" of user information.
By integrating with Salesforce for provisioning, users created in Okta are pushed down to Salesforce, but continue to be 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 enables 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 down to the integrated, third-party app where the application user account is also updated.
Importing (reading) users from a directory service or app
- Directory service such as AD 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 Import Active Directory users)
- HR-management app such as Workday (see Workday Provisioning)
- CRM app such as Salesforce (see Configuring Provisioning for Salesforce)
- App suite such as Microsoft Office 365 (see Provision users to Office 365)
- Users created in a directory service or integrated, third-party application are pushed up to Okta and turned into new AppUser objects, for matching against existing Okta user accounts, or creating new Okta user accounts.
Profile Mastering is a more sophisticated version of read (import) users. It flags an application as the source of truth for user attribute information on users pulled in from the application. Mastering defines the flow and maintenance of user-object attributes and their lifecycle state. When a user profile is mastered from a given resource (directory or application), the Okta user profile’s attributes and lifecycle state are derived exclusively from that resource. In other words, an Okta user mastered by 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 an HR system) has an Okta profile. However, the profile cannot be edited in Okta by the user or Okta 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., and derives its information exclusively from Active Directory. If the lifecycle state of the user in Active Directory moves to Disabled, the linked Okta user also switches to the corresponding lifecycle state of Deactivated on the next import.
Okta is periodically adding profile masterA profile master is an application (usually a directory service such as Active Directory, or human capital management system such as Workday) that acts as a source of truth for user profile attributes. A user can only be mastered by a single application or directory at any one time. For more details, see the Profile Master page. When users are mastered by attribute, we call this attribute-level mastery (ALM). ALM delivers finer grain control over how profiles are mastered by allowing admins to specify different profile masters for individual attributes. Profile mastering only applies to Okta user profiles, not app user profiles. For more details, see Attribute Level Mastering. capabilities to an expanding number of apps and directories (see Profile mastering).
The Import User Schema feature—also known as Schema DiscoveryAbility to import additional attributes to Okta, imports additional user attributes from apps such as Salesforce.
- The import of users is achieved through one of the following integration technologies:
Okta's lightweight, on-premises 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. that synchronizes with your AD configuration. You can set up Real-time Synchronization and Just-In-Time (JIT) Provisioning to ensure that you always have the latest user profiles and do not have to wait for scheduled imports.
Okta provides integration with several popular LDAP vendors using a lightweight agent. Okta's LDAP agent provides Real-Time Synchronization and JIT ProvisioningWith Just-in-Time provisioning, you can use a SAML assertion to create regular and portal users on the fly the first time they try to log in. This eliminates the need to create user accounts in advance. For example, if you recently added an employee to your organization, you don't need to manually create the user in Salesforce. When they log in with single sign-on, their account is automatically created for them, eliminating the time and effort with on-boarding the account. Just-in-Time provisioning works with your SAML identity provider to pass the correct user information to Salesforce in a SAML 2.0 assertion. You can both create and modify accounts this way. Because Just-in-Time provisioning uses SAML to communicate, your organization must have SAML-based single sign-on enabled., similar to its AD agent.
This app supports profile mastery, a CRM-driven app such as Salesforce, or an HR-driven app such as Workday. Automated provisioning from an HR-driven app is useful for organizations that want to use their HR systems as their main user store—as their single source of truth. AD becomes a downstream provisioning target. This feature provides ongoing profile synchronization and ensures efficient on-boarding.
JIT Provisioning enables automatic user account creation 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..
Importing users from a CSV file
For this import, users are managed in Okta and any user profile changes are pushed down to the integrated, third-party app.
Events impacting a user's lifecycle trigger certain provisioning functions that can change the user's lifecycle state (see Okta Provisioning functions). These can include such events as an employee position change, app license expiration, and employment termination (see Triggering events and user identity flow).
As part of Okta Lifecycle Management (LCM), Okta Provisioning is instrumental in the onboarding, transitioning, support, and off-boarding (deprovisioning) of employees and external users in an organization. The flow of a user's identity throughout the different lifecycle stages is known as a user’s lifecycle state change. Events that trigger a lifecycle change put into action a process that ensures access to resources stay compliant with business and security policies.
The following are events that would trigger a user lifecycle change.
Employee is hired
When an employee is hired, HR needs to create an account for that user. Depending on the organization, it is then up to a combination of HR, IT, and the employee supervisors to grant access to all of the apps and accounts they will need, as well as to introduce and enforce the organization's security requirements. With the proliferation of cloud apps, IT organizations may have to manage user accounts in numerous administrator consoles for each app. This can be quite difficult, if not unmanageable. Okta Provisioning reduces IT overhead and helps to automate user management.
Employee is promoted, changes roles, or adopts or drops various software tools
For these scenarios, user access requirements change. Organizations may restructure or acquire new businesses, bringing along new employees. They can also require temporary or permanent app access for contractors and partners.
Employee left an organization
As employees leave an organization, a process can be initiated by various departments to deactivate users. The user account needs to be deactivated. Deprovisioning deactivates the user account from the Okta Universal Directory. Deprovisioning ensures that persons who are no longer in your organization do not have access to sensitive applications and data.
You can deprovision users in Okta or from an external user store, such as AD or a CRM app, such as Salesforce. Typically, user deactivation is triggered from an external user store and it flows into Okta. In any case, deactivated users are automatically deprovisioned from supported apps. Admins receive an email describing any apps that require them to manually deprovision from users.
When a user is removed from the group that was providing him access to certain apps, the user is deprovisioned from these apps. As a member of a new group, the user inherits access to the apps belonging to the group.
App removed from user
For a particular reason, a user no longer needs an app or the app is no longer available to the user (such as an expired license). In this case, deprovisioning is important for compliance reasons and to help you maintain an accurate usage count for your applications.
In order to manage user lifecycle between Okta and an app, provisioning for an app must be enabled.
Below are the scenarios in which a user can be given access to an app. Based on your organization, a particular scenario may fit your needs better than another.
Individual user or users
- For an organization having one or a few members, it may be best to directly assign the app to user.
- You can assign the desired app to the user or the user to the desired app (see Assign and unassign apps to users).
Users originating from an external source, such as an application
- For an organization having user groups well organized in an HR-management app such as Workday or a directory service such as AD or LDAP
- You can assign the application group to the desired app or the desired app to the application group.
Users best served by an Okta group and rules
- If there are users across various locations such as Okta, apps, and directories, it may be best to assign all these user stores to an Okta group with access rights to the desired app.
- This scenario is based on an Okta user group and a rule. Using an Okta user group assigned certain app access is a best practice for assigning users app access to imported users in an app group. When an app group is imported into Okta, the members of that group will be assigned to the Okta user group, and thus the members will inherit the app access of the Okta user group. The assignment of users from the imported app group into the Okta user group is controlled by rules.
Now that you have some background information, let's learn more about Okta Provisioning.Top