Glossary

    A
  • The Access Request Workflow feature is a complete, multi-step approval workflow through which end users can request access to apps. Admins can designate approvers to grant users access for self-service applications. This feature enhances Okta's provisioning solution, which typically is used by IT teams to automate account provisioning and SSO access for users on their first day of employment. Later, users need access to job-specific applications that are often beyond an IT team's purview. The Access Request Workflow feature allows business application owners — rather than IT — to grant users access to apps and assign entitlements in apps that require them.
  • ACS Endpoint – Assertion Consumer Service URL – often referred to simply as the SP login URL. This is the endpoint provided by the SP where SAML responses are posted. The SP needs to provide this information to the IDP
  • Active 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.
  • An 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.
  • A 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.
  • An 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.
  • An app admin can be granted access to all instances of an app, or just specific instances of that application. This allows for more granular access control.
  • Authentication 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.
  • B
  • Once SAML is enabled, users and admins cannot login via username/password using the Service Provider’s login page. All user logins will be done through SAML via the Identity Provider. In most cases, Service Providers have backdoor URL’s which users can use if they need to login using their username/password.
  • C
  • The "buttons" that appear on an end user's Home page and represent each application they wish to access through Okta. Clicking the chiclet allows the end user to instantly sign in and authenticate themselves into their chosen app.
  • Essentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin.
  • Cloud computing refers to applications and services offered over the Internet. These services are offered from data centers all over the world, which are referred to collectively as "the cloud."
  • Each app found on the Okta Applications Page has either an Okta Verified, Community Created, or Community Verified designation. Community Created means that the app was created by the Okta community, but has not yet been tested and verified by Okta.
  • Each app found in the Okta Applications Page page has either an Okta Verified, Community Created, or Community Verified designation. Community Verified indicates that the app was created by the community and has shown some evidence of quality, such as active usage or multiple members of the community using it. However, Okta has not tested it and does not support it in anyway.
  • Referencing the common database operations of Create, Read, Update, and Deactivate (instead of Delete). The CRUD principle is used in Okta for the management of users in the Okta Universal Directory.
  • D
  • Allows users to directly access parts of an application. If supported, users can navigate to a deep link and authenticate to an application using SP-initiated SAML SSO. After authentication, the user will be re-directed to a specific page in the SP instead of the homepage.
  • A 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).
  • Network traffic is often described as either upstream or downstream traffic. Once a user in imported into the Okta Universal Directory, the user account created for the user is pushed downstream to the target app. Now, the user is registered to use the target app. Whenever the user account is updated in the Okta Universal Directory, the updated information is pushed downstream to the target app.
  • In the context of Okta provisioning, a downstream app is one that is receiving data from Okta.
  • E
  • Early Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves.
  • In Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control.
  • F
  • Users will be forced to re-authenticate through their Identity Provider when trying to access an app. Users will be required to re-authenticate even if they have an active session with the IdP already. For Okta, this means that it will also re-evaluate app sign-on policy if it was previously configured.
  • G
  • Generally Available features are available to all orgs automatically according to each customer's SKU. You don’t need to enable them in the console or contact Okta Support.
  • The Group Administrator role stands apart from the other admin roles because it allows for increased administrative control. While this role performs mainly user-related tasks (create users, deactivate users, reset passwords, etc.), it can also be used restrict these tasks to a select group or groups of Okta users. In essence, you can “delegate” permissions to a particular admin to manage a specific group.
  • Groups 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.
  • I
  • Instead of presenting both a Username and a Password field, "identifier first" sign in pages present only a Username field. As used in Okta IdP Routing Rule scenarios, "identifier first" sign in pages submit usernames to Okta for determining which IdP should be used to authenticate an end user.
  • An acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta.
  • Identity Provider Initiated (IDP-initiated) SSO - SAML authentication is initiated by the Identity Provider (IdP). In this flow, the Identity Provider initiates a SAML Response which is re-directed to the Service Provider to assert the user’s identity. In Okta, this is triggered after a user clicks the chiclet for a SAML application.
  • When Okta is used as a service provider, it integrates with an identity provider outside of Okta using SAML. Inbound SAML allows users from external identity providers to SSO into Okta.
  • An acronym for independent software vendors. Okta partners with various ISVs (usually producing enterprise applications) to integrate on-premises, in the cloud, or native-to-mobile devices with Okta.
  • J
  • With 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.
  • users are created/updated on the fly using the SAML attributes sent as part of the SAML response coming from the Identity Provider. The A user is created during initial login to the Service Provider and updated during subsequent logins. Turning on JIT Provisioning is normally a configuration value in the Service Provider.
  • L
  • Lightweight 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.
  • M
  • Mobile Application Management, software and services responsible for provisioning and controlling access to internally developed and commercially available mobile apps used in business settings on both company-provided and “bring your own” smartphones and tablet computers.
  • Mastery defines the flow and maintenance of user object attributes. When a profile is mastered from a given resource (application or directory), the profile attributes of an Okta user is derived exclusively from that resource and therefore cannot be edited in Okta. For example, an Active Directory mastered Okta user has an Okta profile. However, that profile is not editable in Okta by the user or administrator and derives its information exclusively from Active Directory. Okta has implemented a more granular version of this concept, where mastery can be applied at the attribute level, rather than only at the whole profile level. This permits an Okta user profile to derive portions of its attributes from multiple different masters. See the Attribute Level Mastering document for more information.
  • This is the central home page for Okta users. It is the first page that appears after signing into Okta each day, and displays the chiclets that represent an end user’s applications.This page will usually have a URL that looks something like acme.okta.com/app/UserHome.
  • O
  • OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0, an authorization framework. The standard is controlled by the OpenID
  • An acronym for the Okta Integration Network. The OIN is comprised of thousands of public, pre-integrated business and consumer applications. As an on-demand service, OIN integrations are continuously validated, always up to date, and constantly growing both in number and capability. Okta performs a single integration with an ISV or SP, providing thousands of end users with point-and-click customization for their orgs.
  • A sandbox environment that you request from Okta. This sandbox is an org that lives in oktapreview. It gives you complete access to a fully functioning version of Okta to test things like AD integrations and application configurations prior to pushing them out to your full set of users.
  • Each integration found in the Okta Integration Network is either Okta Verified, Community Created, or Community Verified. Integrations can receive Okta Verification status in one of the following ways: 1) If the integration is Okta-built and is tested and verified by Okta. 2) If the integration is ISV-built (partner-built) and tested by Okta, then verified by a customer in production.
  • An acronym for Okta Mobility Management. OMM enables you to manage your users' mobile devices, applications, and data. Your users enroll in the service and can then download and use managed apps from the Apps Store. Managed apps are typically work-related, such as Box or Expensify. As an administrator, you can remove managed apps and associated data from users' devices at any time. You can configure policies, such as data sharing controls, on any of your managed apps. See Configuring Okta Mobility Management for more information.
  • The Okta container that represents a real-world organization.
  • An acronym of Organizational Unit. Organizational units are Active Directory containers into which you can place users, groups, computers, and other organizational units. It is the smallest scope or unit to which you can assign Group Policy settings or delegate administrative authority.
  • P
  • The Provisioning features of some OIN apps are built by a third-party, typically the vendor of the app product or service. These features are Okta Verified through a rigorous Okta review process. Partners-Built EA: Partner-Built EA application features have been verified and tested by Okta but may not have been deployed or used by a customer in an Okta production environment. We recommend that you fully test these integrations for your own provisioning use-cases before deploying in production for your end users. Okta Verified: A Partner-built EA application becomes Okta Verified after a customer has verified the integration in production.
  • A 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.
  • Mastering is a more sophisticated version of read (import) users. Mastering defines the flow and maintenance of user-object attributes and their lifecycle state. When a profile is mastered from a given resource (application or directory), the Okta user profile’s attributes and lifecycle state are derived exclusively from that resource. In other words, an Okta user mastered by Active Directory (or HR system) has an Okta profile. However, the profile isn’t editable in Okta by the user or Okta admin, 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 the read (import).
  • Provisioning 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.
  • S
  • An 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 a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated.
  • Ability to import additional attributes to Okta
  • System for Cross-domain Identity Management (SCIM) is an open standard that allows for the automation of user provisioning. It was created in 2011 as it became clear that the technology of the future would be cloud-based. SCIM communicates user identity data between identity providers (such as companies with multiple individual users) and service providers requiring user identity information (such as enterprise SaaS apps). In short, SCIM makes user data more secure and simplifies the user experience by automating the user identity lifecycle management process.
  • A scope is an indication by the client that it wants to access some resource.
  • A SAML Service Provider sends a logout request to the Identity Provider which results in both the Identity Provider and Service Provider’s current session to close. Okta only supports SP-initiated log out.
  • An acronym for service provider. Generally, an SP is a company, usually providing organizations with communications, storage, processing, and a host of other services. Within Okta, it is any website that accepts SAML responses as a way of signing in users, and has the ability to redirect a user to an IdP (e.g., Okta) to begin the authentication process.
  • Service Provider Initiated (SP-initiated) SSO - SAML authentication is initiated by the Service Provider (SP). This is triggered when the end user tries to access a resource in the Service provider or login directly to the Service Provider.
  • An 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.
  • The super admin receives full access to every item in the Administrative Console and is the only role that can assign administrator roles to other user accounts. Accounts with other administrator role assignments have reduced functionalities to different permission sets. Contact Okta support to create an Okta Mastered account with Super Admin rights.
  • An acronym for Secure Web Authentication. SWA is a SSO system developed by Okta to provide single sign-on for apps that don't support proprietary federated sign-on methods or SAML. Users can enter their credentials for these apps on their homepage. These credentials are stored such that users can access their apps without entering their credentials each time. When users first sign-in to a SWA app from their homepage, they see a pop-up message asking if they were able to sign-in successfully.
  • U
  • Universal 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.
  • Network traffic is often described as either upstream or downstream traffic. Upstream refers to a directory (AD, LDAP) or app (HR management or other app) sending user information to Okta, whic is stored in the Okta Universal Directory as a user account.
Top