Okta Technical Concepts

Mastery

• Mastery defines 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 AD 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.

Profile Mastering

• Mastering defines the flow and maintenance of user-object attributes and their lifecycle state.
• Mastering is a more sophisticated version of read (import) users.
• If the lifecycle state of the user in AD moves to Disabled, the linked Okta user also switches to the corresponding lifecycle state of Deactivated on the next the read (import).

Profile Master

• A profile master is an application (usually a directory service such as AD, or HRMS 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.

ALM

• Users can be mastered by attribute -> 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.

Okta Lifecycle Management

LCM -> Provisioning/ deprovisioning of user accounts across systems/ resources.

• Expression-Language
• Assigned application missing from user’s Okta Dashboard

User Management

1. Manually create user profiles
2. Import user profiles from a directory or app
   1. AD integration
   2. LDAP integration
   3. Application integration
   4. JIT provisioning
      1. AD Delegated Authentication
      2. Desktop SSO
      3. Inbound SAML.
3. Import users from a CSV file

Provisioning and Deprovisioning

Provisioning Methods:

1. Agent-based Provisioning (good, robust strategy)
   • Active Directory
   • LDAP
   • On Premise Provisioning (SCIM)
2. API-based Provisioning (best, most extensible strategy)
   • Application’s Provisioning API
3. SAML JIT (restricted, inflexible strategy)
   • Creation and Updates of downstream users.
   • No Imports or Deprovisioning of downstream users.

Okta provides several provisioning methods:

• AD integration – Okta provides a lightweight, on-premises Active Directory agent to synchronize 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.
• LDAP integration – Okta provides integration with several popular LDAP vendors using a lightweight agent. Okta’s LDAP agent provides real-time synchronization and JIT provisioning, similar to its AD agent.
• HR-driven IT – Okta provides automated provisioning from HR (for example, Workday). This type of provisioning is useful for companies that want to use their HR systems as their main user store. AD becomes a downstream provisioning target. This feature provides ongoing profile synchronization and ensures efficient on-boarding.

JIT Provisioning

JIT provisioning enables automatic user account creation in Okta the first time a user authenticates with AD DelAuth, Desktop SSO, or inbound SAML.

• If JIT enabled, users don’t receive activation emails.
• JIT account creation and activation works for end users who are not in Okta.
• JIT updates the accounts of existing end users during full imports.
  • This means that end users who are confirmed on the import results page, regardless of whether or not they were subsequently activated, are not eligible for new JIT activation.
• If DelAuth is enabled,
  • No need to import users from AD first for JIT provisioning to create users..
• If no DelAuth enabled,
  • Import the AD accounts first, and they must appear on the imported users list for JIT provisioning to create Okta accounts.

Security at Okta

Tenant data encrypted using Symmetric-Key -> stored in Key-Store -> accessed by Master-Key.

• Okta encrypts the tenant confidential data in the database.
• The encryption is performed using symmetric encryption 256-bit AES with Tenant exclusive symmetric keys
  • Tenant symmetric keys ensures data segregation.
• Tenant symmetric keys are stored in a tenant-exclusive keystore.
  • The keystore can be accessed only with a tenant-exclusive master key.
• Tenant-exclusive master keys are encrypted in three different ways to achieve the highest level of availability and business continuity.
  • The use of application level encryption protects sensitive data, even in the event of partial compromise.
  • As a result, attackers lack the ability to decrypt the data if armed with 2 out of 3 of the following: Master Key, Key Store, and/or the user’s app context.

Identity Providers

Types:

• Social Identity Provider
• Inbound SAML
• Smart Card/ PIV Card
  • x.509 compliant digital certificate-based with certificate chains.

SAML issue debugging

• Login URL or Single Sign On URL -> ACS URL
• Audience Restriction/ Entity ID -> same as ACS URL
• The username format expected by the application (i.e. email address, first initial last name, etc)
• User experiences an endless loop of being redirected to Okta, and then back to the application’s normal login page (which can’t handle SAML assertions), then back to Okta, etc.
  • This can occur when the application utilizes a custom or “vanity” domain (ie https://MyCompany.my.salesforce.com) that is configured to redirect authentication to the IdP.

Provide these to SP:

1. Identity Provider Single Sign-On URL. The SP may refer to this as the “SSO URL” or “SAML Endpoint.” It’s the only actual URL Okta provides when configuring a SAML application, so it’s safe to say that any field on the Service Provider side that is expecting a URL will need this entered into it.
2. Identity Provider Issuer. This is often referred to as the Entity ID or simply “Issuer.” The assertion will contain this information, and the SP will use it as verification.
3. x.509 Certificate. Some service providers allow you to upload this as file, whereas others require you paste it as text into a field.

Account Linking

• Users can use multiple IdPs to sign in, and Okta can link all of those IdP profiles to a single Okta user. This is called Account Linking.
• If, for example, a user signs in to your app using a different Identity Provider than they used for registration, Account Linking can establish that the user owns both identities, allowing the user to sign in from either account.

Apps

• Apps can be:
  • Okta Verified
  • Community Verified
  • Community Created
• App Integration Wizard (AIW): If you want to add an integration that doesn’t already exist in the Okta Integration Network (OIN), use the App Integration Wizard (AIW) to create a new integration and connect Okta with SAML, OIDC, SWA, or SCIM application.
  • After you create your integration, assign it to users in org.
  • Integration is private, visible only within own Okta org.
  • Submit an app integration for OIN to make it public.
  • AIW following tabs:
    • General
    • Sign-on Policy
    • Provisioning (optional)
    • Import
    • Assignment

Authentication Types:

• Web App: SWA, SAML 2.0, OIDC
• Native App: None, SAML 2.0, OIDC (PKCE and Client Credentials: secrets is placed in the app; insecure)
• Single Page App: OIDC (PKCE)
• OAuth Service: OAuth 2.0

OIDC: If SPA app, decide what kind of app visibility and login flow you want.

• Configure  app to be initiated only in the background without an Okta app button, (or)
• Configure the sign-in request to be initiated either by the app or by Okta.

SCIM provisioning: SWA or SAML 2.0 as authentication types supported and NOT  OIDC is not supported.

• Basic Auth  — To authenticate using Basic Auth mode, provide the username/ password for the account that handles the create, update, and deprovisioning actions on SCIM server.
• HTTP Header  — To authenticate using HTTP Header, provide a bearer token that will provide authorization against SCIM app.
• OAuth2  — To authenticate using OAuth2, provide the access token and authorization endpoints for SCIM server, along with a client ID and a client secret.

Application User Profile object

• Application User profiles are app-specific, but may be customized by the Profile Editor in the administrator UI.
• SSO apps don’t support a user profile; because not much required in user-profile.
• Provisioning apps supports a user profile.
• Any profile properties visible in the administrator UI for an application assignment can also be assigned via the API.
• Some properties are reference properties and imported from the target application and only allow specific values to be configured.

External ID

• Users in Okta are linked to a user in a target application via an externalId.
• Okta anchors a user with his or her externalId during an import or provisioning synchronization event.
• Okta uses the native app-specific identifier or primary key for the user as the externalId.
• The externalId is selected during import when the user is confirmed (reconciled) or during provisioning when the user has been successfully created in the target application.

SCIM

• System for Cross-domain Identity Management specification, is an open standard designed to manage user identity information.
• SCIM provides a defined schema for representing users and groups, and a RESTful API to run CRUD operations on those user and group resources.
• The provisioning actions performed by an integration are described using the database operation acronym “CRUD“: Create, Read, Update, and Delete.
  • Along with this Okta supports Syncing Passwords and Profile Attribute Mappings via SCIM.
  • For audit purposes, Okta users are never deleted. Instead, they are deprovisioned by setting an active attribute to “false”. Then, if an existing user needs to be re-provisioned at a later date.

Apps SignOn-Modes

SWA Apps

Template Apps Types:

1. Template App: does a POST of username/ password to a sign-in page.
2. Template Plugin App: uses a plugin to search the username/ password fields in page to POST username/ password.
3. Template App 3 Fields – Similar to above; use if an app page also has an additional field such as Company ID
4. Template 2 Page Plugin App – Also similar to the Template Plugin App; use if sign in flow is spread over two separate pages
5. Template Basic Auth App – Use if the app supports HTTP basic authentication.

Plugin SWA application: A SWA application that requires a browser plugin.

• If the app has cross-site request forgery XSRF protection -> use the Template Plugin App or Template Plugin 3 Fields app.
  • To check, inspect the page to see if the server generated an XSFR token.
  • Also look for fields such as EVENTVALIDATION or FORMVALIDATION which are generated on asp pages.

SWA application (no plugin): A SWA application that uses HTTP POST and doesn’t require a browser plugin.

When you configure your sign-in options, you can set up SWA so that:

• User sets username and password
• Administrator sets username and password
• Administrator sets username, user sets password
• Administrator sets username, password is the same as user’s Okta password
• Users share a single username and password set by administrator

Browser Plugins

When end users start an app from their Okta End User Dashboard,

• A new browser tab opens to the app’s URL.
• The plugin uses an encrypted SSL connection to obtain authentication information and other required information from Okta.
• Then applies that information to the page.
• The plugin does not store their credentials after authentication is complete.

To enhance security, the plugin only works with trusted and verified sites. If end users have not installed the Okta Browser Plugin but have one or more applications on their end-user dashboard that require it, they see a notification to install the plugin on the dashboard.

Okta Browser Plugin provides the following functionality:

1. Automatically sign in to apps
2. Automatically initiate an Okta sign-in
3. Automatically fill in credentials on sign-in pages (if user have not enabled automatic app sign-in)
4. Automatically insert passwords on password-update pages
5. Update passwords
6. Quickly jump to Admin Console
7. Switch between multiple Okta accounts

Simulating an IdP-initiated Flow with the Bookmark App

• When an application only supports an SP-initiated flow, you can simulate an IDP-initiated flow with the Bookmark app.
• With the Bookmark application, the end user clicks a chiclet in Okta and is signed into the application.
• Internally, the chiclet calls -> Bookmark app with application URL that goes to the domain in the app, -> then calls Okta.
• You can customize the chiclet for Bookmark to display the logo for the application with the SP-initiated flow, so the end user experience is not different from logging on to any other application.
• Note: Provisioning features are not supported by Bookmark apps.

Pass Device Context to SAML apps using Limited Access

• Limited Access allows you configure Okta to pass device context to certain SAML apps through the SAML assertion during app authentication.
• The app can then use that information to limit access to certain app-specific behaviors, such as user permissions to edit the app or download files from the app.
• Supported attribute values

Attribute Value in SAML Attribute Statement	Definition
TRUSTED	User’s device is trusted as defined by the Okta app sign-on policy
NOT_TRUSTED	User’s device is untrusted as defined by the Okta app sign-on policy
UNKNOWN	The device context is unknown because one or both of the following is true: Device Trust is not enabled for the given device type (Security > Device Trust) Device Trust is not configured in the app’s sign on policy (Applications > app > Sign On > Sign On Policy)

• Use the Okta Expression Language to transform the value as needed for your use case.
• For example, to map Okta terms for a trusted device context to relevant Salesforce terms, you would enter this statement in the Value field:
  • device.trusted == “TRUSTED” ? “HIGH ASSURANCE” : “STANDARD”
• The above statement transforms terms as follows:

Okta device context attribute	Salesforce term
TRUSTED	HIGH ASSURANCE
NOT_TRUSTED	STANDARD
UNKNOWN	STANDARD

<org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221; xsi:type=”xs:string”>NOT_TRUSTED

Configure Expressions

1. source refers to the object on the left hand side:
   • Can be used in either Okta to App or App to Okta mappings.
   • Example: source.firstName
2. user refers to the Okta user profile.
   • Can only be used in the Okta to App mapping, where it returns the same result as source
   • Example: user.firstName
3. appUser (implicit reference) refers to the in-context app (not Okta user profile):
   • Can only be used in the Okta to App mapping, where it returns the same result as source.
   • Example: appUser.firstName
4. appUserName (explicit reference) refers to a specific app by name:
   • Can be used in either Okta to App or App to Okta mappings.
   • Used to reference an app outside the mappings.
   • Example: google.nameGivenName
   • If multiple instances of an app are configured, additional app user profiles that follow the first instance are appended with an underscore and a random string.
     • Example: google, google_, google_.

Selective Profile Push (uni-directional)

Along with mapping, the selective profile push feature allows admins to select which attributes are pushed from Okta to an app when a provisioning event occurs. While mapping may be bi-directional, selective profile push is uni-directional, meaning that this data can only be pushed from Okta to a target app.

• Apply mapping on user create and update: This pushes data when a user is created and also when there is a change in their profile.
• Apply mapping on user create only: This pushes data only when a new user is created, and does not automatically push data when a user profile changes.
• Do Not map: This removes an existing mapping.

Hide sensitive attributes

• Okta allows you to mark an attribute in the Okta user profile as sensitive, which ensures that no one in Okta can view the information stored in that attribute field.
• No Okta admins or end users will have access to any data marked sensitive.
• Only Okta Super admins can mark an attribute as sensitive and use sensitive attributes in mapping attributes or SAML assertions.
  • Passing sensitive data from one application to another through Okta.
    • For example, if you wanted to pass along a user’s employee number from a downstream app to an upstream app but do not want that information visible to Okta users or admins, you can mark that attribute as sensitive.
    • If the employee number is stored in AD, you would map the AD attribute to the appropriate field in the Okta user profile and mark the Okta attribute as sensitive.
    • Then map the Okta attribute to the upstream app (for example, Workday). The data will flow from AD through Okta to Workday.
  • Including sensitive attributes in SAML 2.0 app attribute statements.
    • You can also use these sensitive attributes in SAML assertions to provide extra validation when an end user is signing in to an app.

Custom user types in UD

https://help.okta.com/en/prod/Content/Topics/Directory/directory-UD-usertypes.htm

• Okta supports up to 10 user types: the default Okta user profile plus up to 9 custom user types.
• When create a custom user type, UD makes a copy of the latest default Okta user profile with the default 31 base Okta attributes.
  • The copy is created with the new user type name you give it (for example, “Contractor”). Once this copy is made, then add custom attributes that are relevant to the Contractor user type.
• Can customize the 31 base Okta user attributes.
  • Each custom user type can have different attribute settings. You can make some attributes optional or required, select different enum types, and so on. Each user type can map the Okta user profile attributes to different application attributes and add custom attributes.
  • This gives you complete flexibility in your authentication and provisioning scenarios.
• Each Okta end user can only have one user type. That is, Jane Doe can only have one Okta user profile type: either the default Okta user profile or a custom user type. You must maintain a one-to-one mapping.
• Key Features
  • Have up to 10 distinct user types within a single Okta org.
  • Apply different constraints on attributes. For example, for username, you can specify email as the format for one user type and sAMAccountName for a different user type.
  • Have different profile mappings for the same app for different user types.
  • One user, one user type.
  • The User type attribute is unrelated to the custom user types feature.

Enforce custom attribute uniqueness

• Enforce attribute uniqueness across organization for custom attributes in the Okta user profile, such as employee identification number.
• Declare a maximum of 5 unique attributes for each user-type.
  • Do not need to select the same set of attributes for each user type. For example, the 5 unique attributes you declare unique for user profile A do not need to match what you declared for user profiles B, C, or D.
• Unique attributes share a single namespace across all user types per org.
  • If user types A and B both contain the attribute ice-cream and you identify it as unique in both profiles, then if user typeA has the value chocolate, no other users of typeA or typeB (or any other user type with ice cream declared unique) can have that value.
  • To allow duplicates between unique attributes in different types, modify the attribute names to be slightly different. For example, ice-creamA in typeA and ice-creamB in typeB are tracked separately.
  • Attributes that are not unique are not tracked for uniqueness.
    • If the attribute candy is unique in typeE and not unique in typeF, and a user of typeE has the value caramel for the attribute, then no other users of typeE can have the value caramel for the attribute, but any number of users of typeF can still have the value caramel. Although candy is unique in E, it is not unique in F, so the value for the attribute in users of type F does not matter.
• When you mark an existing custom attribute as requiring a unique value, UD will run a validation check to ensure that no duplicate entries already exist.
  • This check may take some time, depending on how many user records you have.
  • A status message on the Profile Editor page indicates:
    • how many records have been checked
    • how many duplicates have been found and,
    • the estimated time remaining.
  • If duplicate records are found meaning the attribute cannot currently have uniqueness applied to it, the Restriction check box will be cleared automatically. You will have to resolve the duplicate values before applying uniqueness to the attribute.

• The status message on the Profile Editor page displays the validation progress and status. This message is displayed to all admins viewing the Profile Editor page so that they are aware a validation check is running.

Incremental Imports

AD Integration

Supported AD integration features

• Out-of-scope OU refers to an OU that does not appear in or is not selected in the relevant OU selector.

Delegated Authentication

When Okta is integrated with an AD instance:

• • DelAuth, JIT and AD–Profile Mastering enabled by default.

• The user enters their username and password in the Okta end user home page.
• The username and password are transmitted over the SSL connection implemented during setup to an Okta-AD agent running behind a firewall.
• The Okta AD agent passes the user credentials to the AD domain controller for authentication.
• The AD domain controller validates the username and password and uses the Okta AD agent to return a yes or no response to Okta.
• A yes response confirms the user’s identity and they are authenticated and sent to their Okta homepage.

Delegated authentication maintains persistence for directory authenticated – DelAuth sessions and AD is ultimate source for credential validation.

• As AD is responsible for authenticating users, changes to a user’s status (such as password changes or deactivations) are immediately pushed to Okta.
• If disable AD as profile master, changes made in AD are not pushed to Okta.

Lifecycle Settings:

• Define what happens when a user is deactivated in AD.
• Users can be deactivated, suspended, or remain an active user in Okta.
• Only the highest priority profile master for an Okta user can deactivate or suspend an Okta user.
• To verify the highest priority profile master, review the Profile Masters page.

Synchronize Passwords

Sync Password: Okta -> AD

• Enable Sync Password from the Okta Admin Console Provisioning page.
  • With Okta to AD synchronization, the Okta password is pushed to AD.
    • Useful if Okta to be the final authentication resource and need to use AD instance to authenticate access to legacy resources that you can’t connect to Okta.
  • To allow Okta to synchronize with AD, DelAuth must be OFF.
    • AD agent needs additional permissions to write the new password to AD.
  • All password changes should be initiated in Okta and propagated to AD and users should be prohibited from changing their passwords directly in AD.

Okta Password Sync agent: AD -> Okta

• Install on all integrated domain controllers in domain.
  • When DelAuth to AD is enabled, directory passwords are not synchronized to Okta because DelAuth performs the authentication and there is no Okta password.
  • With DelAuth, users use their directory password to sign on to Okta.
  • Change password in AD.
  • This is useful to access DSSO scenario where user uses same AD password to access cloud apps via DSSO.

Application Password synchronization

(Okta -> Apps)

Okta uses standard APIs to synchronize passwords with cloud and on-premises applications when they are available.

Google Suite, Salesforce, and Atlassian JIRA, can use Okta to create and assign passwords when a user first accesses the application.

• Sync Password is enabled,
  • Default behavior is to sync the existing Okta password.
  • If AD/ LDAP DelAuth configured, sync AD or LDAP password.
    • Okta uses the application API to synchronize the AD or LDAP password to the application.
    • The password is stored as the application password.
• Options:

1. 1. Sync Okta passwords or random passwords to provisioning enabled apps.
   2. Sync AD/ LDAP passwords and to provisioning enabled apps.

Mobile Password Synchronization

• With Okta to mobile synchronization, the password is synchronized to the application client on the mobile device.
• This functionality is only available for iOS and Android native mail clients that are configured with Okta Mobility Management (OMM).

Import safeguards

• Okta enables you to set a safeguard against an unusual number of app un-assignments during user import.
• An import safeguard is the maximum percentage of app users in an org that can be unassigned while Okta still allows the import to proceed.
• Apply an import safeguard either at the app level, org level, or both.
  • Org-level applies to all app user assignments in an org.
  • App-level applies to individual app user assignments in an app.

Take the example of an org with 10 apps and 100 users assigned to each app, for a total of 1,000 app users:

• Org-Level Safeguard – Applied against the total app user population of 1,000 app users.
  • If set at 20 percent, any import that would unassign more than 200 app users would be paused.
• App-Level Safeguard – Applied against the population of users assigned to any given app (100 users, in this example).
  • If set at 50 percent, any import that would unassign more than 50 users from a given app would be paused.

By default, the app-level and org-level safeguards are enabled and set at 20% each.

Match imported users

• When import users, set up Okta rules to match any attribute that is currently mapped from an AppUser profile to an OktaUser profile.
• This helps you sync identities across systems and determine whether an imported user is new or user profile already exists in Okta.

LDAP Integration

Supported LDAP integration features

JIT Authentication: Ability to authenticate user credentials through LDAP for access into Okta, and update group memberships and profile information before access.

• JIT Authentication = Authentication + Update profile + Update group membership 

LDAP incremental imports: Okta only supports time stamp-based change tracking.

• To identify changes made since the last import, the agent uses modifyTimestamp.
• If directory supports modifyTimestamp, incremental imports work.

Schema Discovery: Only add attributes to the directory profile if they are already in the directory, so Okta first does a schema discovery step to populate the attribute picker.

• For Okta to discover the attribute, it must be added to an object within the User object hierarchy in the directory: user, parent (eg: top) or auxiliary objects.

LDAP Interface

LDAP Interface allows cloud-based LDAP authentication against Okta’s UD instead of an on-premises LDAP server or Active Directory.

LDAP Interface connect LDAP applications to UD without installing and maintaining Okta LDAP agents:

• LDAP agent is usually deployed inside your firewall.
• LDAP interface is managed in the cloud.

The LDAP Interface lets you use Okta to centralize and manage your LDAP policies, users, and applications that support LDAP authentication protocol.

• The LDAP Interface is a cloud proxy that consumes LDAP commands and translates them to Okta API calls, providing a straightforward path to authenticate legacy LDAP apps in the cloud.
• To enhance security, add MFA to LDAP apps with Okta Verify Push and One-Time-Password (OTP).
• The Okta LDAP agent synchronizes user profiles to or from an existing LDAP directory.
• The LDAP interface lets you migrate certain applications from LDAP or AD servers to Okta.

Use MFA with LDAP Interface

• The format for entering your password and MFA token is: <password,MFAtoken>
  • For example, enter the following for Okta Verify: password,123456

CSV directory integration

CSV directory integration is a lightweight out-of-the-box option that lets you build custom integrations for on-premises systems using the On-Premises Provisioning agent (OPP).

1. All active users must be present for every CSV import.
   • CSV file is a representation of all active users from your source system.
   • All active users must be present in every CSV import or the user is considered inactive.
   • Okta uses the Unique Identifier that you designated as the primary identifier for each user.
2. The import behaves as follows:
   • If a user is missing during the latest import, Okta assumes the user is no longer active and deactivates the user in Okta.
   • If a new user appears who did not exist in Okta during a previous import as denoted by their unique identifier, then Okta creates the user.
   • If a user is present in Okta and was present in the latest import, Okta treats the current data in the CSV file as the source of truth, and executes any updates to that user’s attributes.
   • OPP also lets you use additional provisioning functionality such as:
     • profile push
     • password push
     • group push
     • user import
     • group import
     • user deactivation

Groups

Group Type	Description
Native Okta groups	The default group Everyone contains all users in Okta org.
Active Directory groups	Active Directory (AD) is the most common source for groups. Use the Okta AD agent integrate your AD instance with Okta. No support of Domain Local Groups containing members from multiple domains. Support Universal Security Groups with cross-domain membership if there is a two-way trust established between the domains. No support USG cross-forest membership.
LDAP groups	Use the Okta LDAP agent to import groups from LDAP-compliant Windows and Unix servers.
Application groups	Some applications have groups that 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. Box Google Apps Jira Microsoft Office 365 Workday

• App-Group deletion:
  • Groups that were imported from an application cannot be deleted in Okta.
  • However, you can use the Import feature to remove them.
  • Open the app instance and delete the group there.
  • The deleted group will be removed from Okta during the next scheduled (or manual) import.

Universal Security Group (USG) & Domain Local Groups

In AD, a universal security group (USG) allows for membership across all trusted forests in an AD environment. By default, USGs only exist in Okta if there is an AD agent in a domain importing users and groups. Enabling the USG option ignores domain boundaries when importing group memberships for users. This assumes that the relevant domains are connected in Okta.

Only groups from connected domains are imported as USG object in Okta:

• Deploy an AD agent for every domain in forest that contains the USG object that want to sync with Okta.
• Support USG with cross-domain membership if there is a two-way trust established between the domains.
• Each connected domain then imports its groups.
• When a user’s group memberships match any groups that were imported, Okta syncs the memberships for the user to each group.
• This option provides greater control of group imports from on-premises apps to Okta.
• USG do not support cross-forest membership.

Okta does not support Domain Local Groups:

• Okta does not support Domain Local Groups containing members from multiple domains.

Nested groups

Many directory systems and applications support the concept of nested groups (or groups in groups). Okta does not currently support nested groups.

• Okta imports all nested directories for group members and adds the user to each group in Okta.
• In the example below, the group in AD (left) has two child groups. The resultant group in Okta (right) lists members without nested groups.

Group Push & Enhanced Group Push

Group Push enables to take existing Okta groups and their memberships, and push them to provisioning-enabled, third-party applications.

• These memberships are then mastered by Okta.

• Limitation
  • Using the same Okta group for assignments and for group push is not currently supported.
  • To maintain consistent group membership between Okta and the downstream app, you need to create a separate group that is configured to push groups to the target app.

Enhanced Group Push enables you to push from Okta to existing groups in specific apps.

• Can push group with a same name that already exists in the third-party apps.
• These memberships are then mastered by Okta.
• Enhanced Group Push is available for these integrations:
  • Active Directory, Adobe CQ, Box, DocuSign, Dropbox for Business, G Suite, Jira , Jira On-Prem, Jive Software, Litmos, Org2Org, ServiceNow UD, Slack, Smartsheet, Workplace by Facebook, Zendesk.

App-Level MFA

Configure app-level MFA by itself or both org-level MFA and app-level MFA together.

MFA for groups and users

MFA can be applied to specific groups and users:

• All apps are supported except for Microsoft clients that use active mode authentication.
• Microsoft Office 365 is supported; outdated Microsoft Office thick clients are not supported.

Windows Credential Provider for MFA

• Users can use the Okta Credential Provider for Windows to prompt users for MFA when signing in to supported Windows servers with an RDP client.

Custom IdP Factor Authentication

IdP factor authentication allows admins to enable a custom SAML-MFA factor based on a configured Identity Provider.

• Once an IdP factor has been enabled and added to a factor enrollment policy, users who sign in to Okta may use it to verify their identity at sign in. 
• End users are directed to the Identity Provider in order to authenticate and then redirected to Okta once verification is successful.
• With this feature you can:

• • Add a custom IdP factor for existing IdP authentication.
  • Enable or disable the custom factor from the admin console.
  • Link an existing SAML 2.0 Identity Provider to use as the custom factor provider.

Custom TOTP Factor

Custom TOTP Factor allows admins to enroll users in a custom TOTP factor by importing a seed into Okta and authenticating users with the imported hardware token.

• Successful factor enrollment requires passing a profile ID and shared secret for each token.

Factor Sequencing

Allows an end user to sign in to their org by authenticating with a series of configured MFA factors in place of a standard password.

• Verify that the factors in at least one factor chain is marked as Required for enrollment.
• For example, by defining the following two factor sequences in your sign on policy:
  • a. SMS and Okta Verify
  • b. Okta Verify and Security Questions
• Your end users are required to enroll in the sequenced factors (a) or (b) for successful authentication to take place.

Federation Broker Mode

• Allows SSO without pre-assignment of Apps to users.
• Access is managed only by sign-on policy and the authorization rules of each app.
• This mode can improve import performance and can be especially helpful for larger-scale orgs that manage many users and/or apps.
• Only for custom SAML Wizard and OIDC apps, not for those available in the OIN.
• Supports SP-initiated flows ONLY, hence, no chiclets option in Okta Homepage
• Hidden tabs may include Provisioning, Imports, Group Push, and Mobile in AIW.
• Assignments tab of an app no longer lists user assignments, as it is no longer subject to individual assignments.
• No audit reporting.
• No provisioning.
• Disable this mode after implementation, can restore previously user assignments.

Network Zone

• A network zone is a security perimeter used to limit or restrict access to a network based on a single IP address, one or more IP address ranges, or a list of geolocations.
• Network zones may be incorporated into:
  • Policies
  • Application sign-on rules
  • VPN Notifications
  • Integrated Windows Authentication (IWA).

Zone Types

1. IP Zones: A type of zone where the network perimeter is defined by IP addresses.
2. Dynamic Zones: A type of zone where the network perimeter is defined by one or more of the following:

• • Geolocation
  • Autonomous System Number (ASN)
  • IP Type
• ASN (Autonomous System Numbers) are used to uniquely identify network on the Internet.
  • ISPs can apply to obtain one or multiple ASNs assigned to them.
  • While an ISP name can change, their assigned ASN is reserved and immutable.
• IP Types setting checks and determines if a client uses a proxy and the type of proxy.
  • Any: Ignores all proxy types. If selected, at least one of the following must be defined:
    • Locations
    • ISP ASNs
  • Any proxy: Considers clients that use a Tor anonymizer proxy or a non-Tor anonymizer proxy type.
  • Tor anonymizer proxy: Considers clients that use a Tor anonymizer proxy.
  • Not Tor anonymizer proxy: Considers clients that use non-Tor proxy types.

{
  "type": "IP",
  "id": "nzouagptWUz5DlLfM0g3",
  "name": "newNetworkZone",
  "status": "ACTIVE",
  "created": "2017-01-24T19:52:34.000Z",
  "lastUpdated": "2017-01-24T19:52:34.000Z",
  "system": false,
  "gateways": [
    {
      "type": "CIDR",
      "value": "1.2.3.4/24"
    },
    {
      "type": "RANGE",
      "value": "2.3.4.5-2.3.4.15"
    }
  ],
  "proxies": [
    {
      "type": "CIDR",
      "value": "2.2.3.4/24"
    },
    {
      "type": "RANGE",
      "value": "3.3.4.5-3.3.4.15"
    }
  ]
}

{
    "type": "DYNAMIC",
    "id": "nzowc1U5Jh5xuAK0o0g3",
    "name": "test",
    "status": "ACTIVE",
    "created": "2019-05-17T18:44:31.000Z",
    "lastUpdated": "2019-05-21T13:50:49.000Z",
    "system": false,
    "locations": [{
        "country": "AX",
        "region": null
    },
    {
        "country": "AF",
        "region": "AF-BGL"
    }],
    "proxyType": "Any",
    "asns": ["23457"]
}

Behavior Security Detection

• Deciding when to require a second MFA factor is a common challenge for admins.
• Prompting user to authenticate with an additional factor for every sign-in attempt can frustrate the users; however, having a less restrictive policy increases the risk of account compromise.
• With this feature, admins can configure the system so that individual end users are only prompted for an additional MFA factor when change in user-behavior that the admin defines.

There are two components of security behavior detection:

1. Define the behavior to track.
2. Define an action to take if there is a change in trackable behavior for an end user.

Examples of trackable behaviors	Sign in from a new country, state, or city Sign in from a new location more than a specified distance from previous successful sign ins Sign in from a new device Sign in from a new IP address Sign in from a location deemed unfeasible for a user to travel to across two successive sign-in attempts.
Examples of actions to take	Permit access Require the end user to validate with an additional MFA Set the session lifetime

Trusted App Flows

System Log lists behavior that is evaluated for any sign-in attempts.

• For user.session.start and policy.evaluate.sign_on events.
• Possible values:

• • POSITIVE: Behavior is detected. POSITIVE results in the policy rule matching – if MFA is configured for the rule, Okta prompts for MFA.
  • NEGATIVE: Behavior is not detected. NEGATIVE results in the policy rule not matching – if MFA is configured for the rule, Okta does not prompt for MFA.
  • UNKNOWN: Not enough history to detect behavior. UNKNOWN results in the policy rule matching – if MFA is configured for the rule, Okta prompts for MFA.
  • BAD_REQUEST: Not enough information from the sign-in attempt to detect behavior. For example, if the cookies and device fingerprint are missing, Okta treats it as a BAD_REQUEST, which results in the policy rule matching – if MFA is configured for the rule, Okta prompts for MFA.

Risk Scoring

• Based on a machine-learning risk engine, that determines the likelihood of an anomalous sign-in event.
• First set to high risk for new users initially — over time the risk level is low as more information is gathered.
• Risk Scoring is designed to complement automation detection and does not account for the following scenarios:
  • Substitute for bot management or automation detection
  • Replacement for Web Application Firewalls (WAFs)
  • Assistance with any type of security compliance

Browser flow for new devices

1. An Okta security image cookie in the browser.
2. A browser fingerprint collected by the Okta Sign-in widget.

Enable strong MFA factors in factor enrollment policies

• Security Questions: Do not use as a second factor.
• SMS/Email/Voice: Avoid using as a second factor.
• Okta Verify with Push Notifications: Enable if available for org, If not available, use Okta Verify or Google Authenticator.
• WebAuthn factors (includes Yubikey devices): Enable if available for your org.
• Okta also recommends blacklisting any IPs that are identified as a Tor Anonymizer Proxy.

Events & System Log API

• Events API’s (/api/v1/events) representation is the Event object.
  • action.objectType attribute denotes the event type.
• System Log API’s (/api/v1/logs) representation is the LogEvent object.
  • More structure and a much richer set of data elements than Event.
  • eventType attribute represents the event type.
  • LogEvent’s legacyEventType attribute identifies the equivalent Event action.objectType value.
• Event Type Mapping section of this guide provides a static mapping of Events API event types to System Log API event types.
• System Log API expands and enriches the data model to support storing message values as atomic, independent attributes.
  • Context objects, such as the AuthenticationContext Objects and  GeographicalContext objects, provide attributes that are common across event types.
  • DebugContext object houses event-type-specific attributes.

Inline Hooks

• Inline hooks are synchronous calls to external service.

• JSON payload of response external service sends can contain a commands object, in which service send commands to Okta that affect the course of the Okta process flow.
  • The commands available vary depending on the type of Inline Hook.
• Header-based authentication with customer issued API Key.
• Default timeout of 3 seconds.
  • Okta will attempt at most one retry.
• A request is not retried if the customer endpoint returns a 4xx HTTP error code.
• Any 2xx code is considered successful and not retried.
• No redirects from external service endpoint.
• JSON Payload Objects to Okta by external service:
  • commands
    • commands to Okta to affect the process flow being executed and to modify values within Okta objects.
  • error
    • return error messages to Okta.
  • debugContext
    • specify additional information to make available in the System Log in connection with the call to your hook.
• 10 max inline hooks.

User Import Inline Hook

Request Objects: The outbound call from Okta to external service will include the following objects in its JSON payload:

1. data.appUser.profile: Provides the name-value pairs of the attributes contained in the app user profile of the user who is being imported.
2. data.user: Provides information on the user profile currently set to be used for the user who is being imported.
   • data.user.profile contains the name-value pairs of the attributes in the user profile. If the user has been matched to an existing Okta user, a data.user.id object will be included, containing the unique identifier of the Okta user profile.
3. data.action.result:The current default action that Okta will take in the case of the user being imported. The two possible values are:
   • CREATE_USER: A new Okta user profile will be created for the user.
   • LINK_USER: The user will be treated as a match for the existing Okta user identified by the value of data.user.id.
4. data.context: This object contains a number of sub-objects, each of which provides some type of contextual information. You cannot affect these objects by means of the commands you return. The following sub-objects are included:

• • data.context.conflicts: List of user profile attributes that are in conflict.
  • data.context.application: Details of the app from which the user is being imported.
  • data.context.job: Details of the import job being run.
  • data.context.matches: List of Okta users currently matched to the app user based on import matching. There can be more than one match.
  • data.context.policy: List of any Policies that apply to the import matching.

Response Objects

Sample JSON Payload of Request from Okta to External Service

{
   "source":"cal7eyxOsnb20oWbZ0g4",
   "eventId":"JUGOUiYZTaKPmH6db0nDag",
   "eventTime":"2019-02-27T20:59:04.000Z",
   "eventTypeVersion":"1.0",
   "cloudEventVersion":"0.1",
   "eventType":"com.okta.import.transform",
   "contentType":"application/json",

   "data":{
      "context":{
         "conflicts":[
            "login"
         ],
         "application":{
            "name":"test_app",
            "id":"0oa7ey7aLRuBvcYUD0g4",
            "label":"app7ey6eU5coTOO5v0g4",
            "status":"ACTIVE"
         },
         "job":{
            "id":"ij17ez2AWtMZRfCZ60g4",
            "type":"import:users"
         },
         "matches":[
         ],
         "policy":[
            "EMAIL",
            "FIRST_AND_LAST_NAME"
         ]
      },

      "action":{
         "result":"CREATE_USER"
      },

      "appUser":{
         "profile":{
            "firstName":"Sally2",
            "lastName":"Admin2",
            "mobilePhone":null,
            "accountType":"PRO",
            "secondEmail":null,
            "failProvisioning":null,
            "failDeprovisioning":null,
            "externalId":"user221",
            "groups":[
               "everyone@clouditude.net",
               "tech@clouditude.net"
            ],
            "userName":"administrator2",
            "email":"sally.admin@clouditude.net"
         }
      },

      "user":{
         "profile":{
            "lastName":"Admin2",
            "zipCode":null,
            "city":null,
            "secondEmail":null,
            "postAddress":null,
            "login":"sally.admin@clouditude.net",
            "firstName":"Sally2",
            "primaryPhone":null,
            "mobilePhone":null,
            "streetAddress":null,
            "countryCode":null,
            "typeId":null,
            "state":null,
            "email":"sally.admin@clouditude.net"
         }
      }
   }
}

Sample JSON Payloads of Responses from External Service to Okta

{
  "commands": [{
    "type": "com.okta.action.update",
    "value": {
      "result": "LINK_USER"
    }
  }, {
    "type": "com.okta.user.update",
    "value": {
      "id": "00garwpuyxHaWOkdV0g4"
    }
  }]
}

{
  "commands": [{
    "type": "com.okta.user.profile.update",
    "value": {
      "firstName": "Stan"
    }
  }]
}

{
  "commands": [{
    "type": "com.okta.user.profile.update",
    "value": {
      "firstName": "Stan"
    }
  }]
}

{
  "commands": [{
    "type": "com.okta.appUser.profile.update",
    "value": {
      "firstName": "Stan",
      "lastName": "Lee"
    }
  }]
}

Event Hooks

• Event hooks are outbound calls from Okta that trigger process flows within your own software systems.
• They are sent when specific events occur in your org, and they deliver information about the event.
• Unlike inline hooks, event hooks are asynchronous and do not offer a way to execute the Okta process flow.
• After sending the call, the Okta process flow continues without waiting for a response from the called service.
• Implement a web service with an Internet-accessible endpoint.
• Concept of webhooks.
• Before the introduction of Event Hooks, polling the System Log API was the only method your external software systems could use to detect the occurrence of specific events in your Okta org.
• Event Hooks provide an Okta-initiated push notification.
• Event Types
• Steps:
  • Add an event hook
  • Verify external endpoint

Access Request Workflow

• 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.
• 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.
• Use Access Request Workflow to:
  • Designate group or individual approvers
  • Create customize notifications
  • Add comments and notes
  • Configure customizable timeout rules

Automations

• Similar to batch job.
• Enable to quickly prepare and respond to situations that occur during the lifecycle of end users who are assigned to an Okta group.
• For example, automation sends inactivity lockouts notification in advance to end-users to advance.
  • If a user has been inactive for a set number of days and is on the verge of being locked out, automation can alert the inactive user in advance.
• Conditions — The criteria that triggers Okta to perform actions upon a group of end users. Conditions can be scheduled to run once or to recur daily. The following conditions are currently available:
  • User inactivity in Okta
  • User password expiration in Okta
• Actions — The actions that Okta to perform when the scheduled conditions are true. The following actions are currently available:
  • Send email to the user

Workflows

• Similar to Zapier (automated integration workflows)
• Workflows is interface-driven no-code-required design console that facilitates the implementation of automated business processes, especially for identity-related use cases.
• A key component of the product is integration with a wide range of third-party apps and functions.
• A Workflow, or Flow, is a sequence of steps that represent the events, logic, and actions in a use case.

With Okta Workflows, you can:

• Provision and deprovision app accounts: Use Case: Provision and Deprovision.
• Sequence actions with logic and timing. Okta Workflows can create deactivated accounts in all apps one week before a new employee’s start date, and then activate them on their first day. When an employee leaves your company, Okta Workflows can remove access to all apps except payroll, and then remove that access after one year. Use Case: Change time- and context-based identity entitlement.
• Resolve identity creation conflicts. Okta Workflows can host logic that detects username conflicts and generates unique usernames. See Use Case: Resolve identity conflicts.
• Respond to security incidents. When Okta detects a suspicious sign-in, Okta Workflows can notify your security team through PagerDuty or create a ticket in ServiceNow. See Use Case: Send notifications for lifecycle activity.
• Log and share lifecycle events. Okta Workflows can query Okta APIs and syslog events, run logic, and compile data into a CSV file. Then, Okta Workflows can email that file to your teams. See Use Case: Report lifecycle activity.

Flow cards

• Event – What has to happen for your Flow to begin? The first card in any Flow is an Event.
• Action – What should happen if the application event occurs? Action cards instruct your Flow to send commands to applications.
• Function – Use cases aren’t always linear. How should action cards account for different scenarios? Function cards let you act on the data from a card or branch into another logical flow.

How does it work?

• Connector – Which applications are involved in your Flow? Connectors enable you to interact with them without setting up APIs.
• Connection – A connection is unique level of access to the connected app (for example, admin or end user).
• Input – Input fields determine how an action or function card proceeds. For example, the input field of the Search for User action card above is User Details.
• Output – Output fields contain the results that are generated by the event, action, or function card. In the example Flow above, the User Unassigned from Application event card produces output values like Date and Time, Message, Event ID, Event Type, and Event Time.
• Mapping – The movement of data between cards is referred to as mapping. To map data between cards, drag and drop the output field of one card to the input field of another card. Be sure that the format of the fields match (text, number, true/false, date & time, object, or list).

Key rotation

Org Authorization Server

• Configure and perform key rollover/rotation at the client level (if you need to use own key).
• For security purposes, Okta automatically rotates keys used to sign the ID token (for Okta APIs, Okta owns the key).
  • Can’t manually rotate the Org Authorization Server’s signing keys.
• Okta doesn’t expose the public keys used to sign the access token minted by the Org Authorization Server. (for Okta APIs, Okta owns the key).
  • Use the /introspect endpoint to validate the access token.
• Pin that specific client to a specific key by generating a key credential and updating the application to use it for signing.

Custom Authorization Servers

• Configure and perform key rollover/rotation at the Authorization Server level.
• For security purposes, Okta automatically rotates keys used to sign tokens.
  • In case of an emergency, Okta can rotate keys as needed.
• Okta always publishes keys to jwks_uri.
• To save the network round trip, app should cache the jwks_uri response locally.
  • HTTP caching headers are used and should be respected.
• You can switch the Authorization Server key rotation mode by updating the Authorization Server’s rotationMode property (manual or automatic).
• Pin that specific client to a specific key by generating a key credential and updating the application to use it for signing.
  • This overrides the Custom AS rollover/pinning behavior for that client.

Authentication API vs OAuth 2.0 vs OpenID Connect

• Authentication API and OAuth/ OIDC API
• Okta API using OAuth-Scoped AT

There are three major kinds of authentication that you can perform with Okta:

• Authentication API controls access to Okta org and applications.
  • Provides operations to user authentication, MFA ops, recovery (forgotten passwords, unlock accounts).
  • Use this to work with Okta API and control user access to Okta.
• OAuth 2.0 protocol controls authorization to access a protected resource, like web app, native app, or API service.
  • Use this in controlling access to your own application.
• OpenID Connect protocol is built on the OAuth 2.0 protocol and helps authenticate users and convey information about them.
  • Use this in controlling access to your own application.

OAuth

Okta Organizations

• An Okta organization (org) is a root object and a container for all other Okta objects.
• Contains resources such as users, groups, and applications, as well as policy and configurations for Okta environment.
• Mandatory items: users and applications.
  • Users can be created in Okta, imported through directory integrations, or imported through application integrations.
  • Applications are connections to public apps (such as Office 365) or proprietary applications (such as your own apps).

Administrators

• Administrator can be assigned to Users or Groups.
• Role Types are Super Admin, Org Admins, ..
• Permissions are individual capability that Administrator can do.
• Permission are categorized as follows:

1. 1. Org-wide Settings
   2. Okta Sign-On
   3. User Management
   4. Group Management
   5. Application Management
   6. MFA
   7. Mobile Policies
   8. Mobile Devices
   9. Event and Inline Hooks
   10. OpenID Connect End-to-End Scenario
   11. API Tokens
   12. OMM – Applications
   13. OMM – Wifi (EA)

• Super admin is the only role that can manage users or groups with admin privileges.
• Group admins lose their permissions if their group is assigned admin privileges.
• Admin roles can’t be assigned to groups with more than 5,000 members.
• Group rules don’t work with admin groups.
  • This prevents delegated admins from erroneously increasing their or other user’s administrative privileges.
• Admins lose their permissions when they are deactivated.
  • If you reactivate a former admin, you also need to reassign privileges to them.

Role Target

• Define permissions for admin roles into a smaller subset of Groups or Apps within org.
• Targets limit an admin’s permissions to a targeted area of the org.
• Define admin roles to target Groups, Applications, and Application Instances.
  1. Group targets
     • Grant an admin permission to manage only a specified Group.
     • For example, an admin role may be assigned to manage only the IT Group.
  2. App targets
     • Grant an admin permission to manage all instances of specified Apps. Target Apps are Okta catalog Apps.
     • For example, there can be multiple configurations of an Okta catalog App, such as Salesforce or Facebook. When you add a Salesforce or Facebook App as a target, that grants the admin permission to manage all instances of those Apps and create new instances of them.
  3. App Instance targets
     • Grant an admin permission to manage an instance of an App or instances of multiple Apps. App Instances are specific Apps that admins have created in their org.
     • For example, there may be a Salesforce App configured differently for each sales region of a company. When you create an App Instance target, an admin may be assigned to manage only two instances of the configured Salesforce Apps and perhaps assigned to manage an instance of another configured App, such as Workday.

 Group membership admin role Vs. Group admin role

Group membership admin role: Grants permission to view all users in an org and manage the membership of groups.

• The group membership admin role can be a standalone assignment for admins who need to add and remove existing in a group, or it can be combined with a role like group admin or help desk admin for broader user management permissions.

Group admin role: While this role performs mainly user-related tasks (create users, deactivate users, reset passwords), 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.

• Uses for this role might be a franchise, where each location needs to silo and control their location-specific teams.
• Each franchise would need to create and manage their own data without affecting or being affecting by the others.

Third-party admins

• The parent organization may create a custom portal for administrator functions, so that third-party admins do not even see the Okta interface.
  • One use case for this feature is if Support services are outsourced to third parties. These third parties act on behalf of the organization managing users needs but do not actually see the Okta user interface.
  • Another use case is in a B2B2C scenario where a “hub-and-spoke model” is set up with end customers (external users) created as admins so they can run their own Okta org, often with a custom portal created with Okta APIs so these external users aren’t aware that they are admins in Okta.
• In both these scenarios, because the external users are given admin roles within Okta, they receive the default Okta admin emails: welcome emails, admin email alerts and Okta customer notifications.
• By introducing the concept of a third-party admin in Okta, we are able to treat these admins differently than the typical Okta admins who interact directly with the Okta Admin Console.

API Token

• API token are generated with the permissions of the user that created the token.
  • If a user’s permissions changes, then so does that of the token.
• Okta recommends generating API tokens from a service account with permissions that do not change.
• API tokens are valid for 30 days and automatically renew every time they are used with an API request.
  • When a token has been inactive for more than 30 days it is revoked and cannot be used again.
  • Tokens are also only valid if the user who created the token is active.
  • If the user is reactivated, the API token is accepted
• Okta Agents uses API tokens during installation which they use to access org.
  • While these tokens are similar to the standard API token, they are managed by Okta.
  • Agent tokens are usually managed when you activate, deactivate, or reactivate an agent.
  • Some agents such as the Okta AD Agent automatically revoke their tokens when agent deactivates.
• The following color codes are used to show the token status.
  • Green – the token has been used within last three days.
  • Gray – the token has not used between last three days, and today is at least seven days before its expiration date.
  • Red – the token is within seven days of expiring.
  • Yellow – the token is suspicious.
    • A suspicious token is associated with an agent that is not registered in Okta.
    • Normal agent deployments do not create suspicious tokens.

Trusted Origins

• All cross-origin web requests and redirects from Okta to organization’s websites must be explicitly whitelisted.
• Use the Trusted Origins tab to grant access to websites that you control and trust to access Okta org through the Okta API.
• An Origin is a security-based concept that combines the URI scheme, hostname, and port number of a page.

Rate Limiting

Requests that hit the rate limits return a “429 Too Many Requests” HTTP status code.

4 types:

1. Org-wide rate limits or Default Rate Limits
   • Limits the # of API requests within any given second.
   • Basically for CRUD of /api/v1/…
2. Concurrent Rate Limits
   • Limits the # of ACTIVE requests/ LIVE threads at any given time.
   • For concurrent rate limits, traffic is measured in three different areas:
     • Agent traffic
     • Microsoft Office 365 traffic,
     • All other traffic, including API requests.
   • Counts in one area are not included in counts for the other two areas.
     • For agent traffic, Okta measured each org’s traffic and set the limit at above the highest usage in the last four weeks.
     • For Office 365 traffic, the limit is 75 concurrent transactions per org.
     • For all other traffic including API requests, the limit is 75 concurrent transactions per org.
   • The first request to exceed the concurrent limit returns an HTTP 429 error, and the first error every sixty seconds is written to the log. Reporting concurrent rate limits once a minute keeps log volume manageable.
3. End-User Rate Limit
   • # of requests from Okta user interface to 40 requests/ user / 10 sec / API endpoint.
4. Okta-Generated Email Message Rate Limits that vary by email type.
   • Okta enforces rate limits on the number of Okta-generated email messages that are sent to customers and customer users.
   • For example, if the number of emails sent to a given user exceeds the per-minute limit for a given email type, subsequent emails of that type are dropped for that user until that minute elapses.

DynamicScale Rate Limits

• Example: MLB Baseball games.
• If your needs exceed Okta’s default rate limits for the base product subscriptions (e.g. One App, Enterprise or IT Products) you’ve already purchased, you can purchase a “DynamicScale” add-on service which will grant you higher rate limits for the endpoints listed below.
• DynamicScale will increase your default rate limits by 3x to 1000x, depending on the tier multiplier you purchase.
• Customers can purchase this add-on annually for a Production tenant or temporarily for testing in a Sandbox tenant.

HTTP/1.1 200 OK
X-Rate-Limit-Limit: 10000
X-Rate-Limit-Remaining: 9999
X-Rate-Limit-Reset: 1516307596

Policy

• Policies contains “settings“
• Rules contains “actions” or “conditions”

Group Password Policies

• Allows to define password policies and associated rules to enforce password settings on the group and authentication-provider level.
• Group Password Policies are enforced only for Okta and AD-mastered users.
  • For AD-mastered users, ensure that AD password policies don’t conflict with the Okta policies.
  • Passwords for AD-mastered users are still managed by the directory service.
• Some applications, such as Office 365 and Google G Suite, check an Okta password policy when provisioning a user to ensure that the Okta policy meets application’s password requirements.

Password Policy Types

1. Default Policy
   • All Okta-mastered users are subject to the Default Policy unless another policy applies.
   • The Default Policy cannot be deactivated or deleted, and always holds the lowest ranking within the policy list.
2. Legacy Policy
   • A Legacy Policy is automatically created for Okta-mastered users.
   • For orgs that were created before Group Password Policy was enabled, the Legacy policy and associated Legacy rules are preserved.
     • Existing password policy settings for an org are copied to the Legacy Policy.
     • All Legacy policy and rule settings are configurable.
   • This is present only if you have already configured MFA.
     • This policy reflects the MFA settings that were in place when you enabled sign-on policy, and ensures that no changes in MFA behavior occur unless you modify your policy.
     • If needed, you can delete it.
3. Active Directory Policy
   • If currently have one or more AD integrations, an AD policy is automatically created for you.
   • You can customize the elements of the policy and its rules.

Pre-Auth Sign-On Evaluation Policy

• End users that sign in using the AuthN API will have their sign on policies evaluated first before their password or other factor is verified.
• This evaluation helps to reduce the number of account lockouts that occur across an org.
• If the sign on policy is set to deny, the user’s sign on attempt is rejected and prompted with the following generic error: Authentication failed.
• In this scenario, the counter for failed logins is not incremented but instead, an event indicating a pre-auth sign-on policy evaluation is triggered.

Rules

Actions Objects

Specify actions to be taken, or operations that may be allowed, if the rule conditions are satisfied.

"actions": {
    "signon": {
      "access": "ALLOW",
      "requireFactor": true,
      "factorPromptMode": "SESSION",
      "rememberDeviceByDefault": false,
      "factorLifetime": 15,
      "session": {
        "usePersistentCookie": false,
        "maxSessionIdleMinutes": 120,
        "maxSessionLifetimeMinutes": 0
      }
    }
  }

Conditions object

• Conditions object(s) specify the conditions that must be met during policy evaluation in order to apply the rule in question.
• All policy conditions, as well as conditions for at least one rule must be met in order to apply the settings specified in the policy and the associated rule. Policies and rules may contain different conditions depending on the policy type.
• Conditions object work against following objects:

• • People Condition object
    • User Condition object
    • Group Condition object

    • "people": {
          "users": {
            "exclude": [
              "00uo7dIiN4jizvY6q0g3"
            ]
          },
          "groups": {
            "include": [
              "00go6lU1wxnmPisNp0g3"
            ]
          }
        }

  • AuthContext Condition object  (Any or RADIUS)
  • Network Condition object
  • Authentication Provider Condition object
  • User Identifier Condition object
  • Patterns object (Matches/ EL)
  • Application/ App Instance Condition object
  • Platform Condition object

Add Sign On policies for applications

Okta’s Client Access Policies (CAPs)

• Allow to manage access to enterprise apps based on the client type & device platform.
• CAPs evaluate information included in the User-Agent request header sent from the users’ browser.
• Because the User-Agent can be spoofed by a malicious actor, you should consider using a whitelist approach when create CAPs and require MFA or Device Trust as described in the following best practices:
  • Implement a whitelist consisting of one or more rules that specify the client type(s) + device platform(s) + trust posture combinations that will be allowed to access the app.
  • Require Device Trust or MFA for app access.
  • Include a final catch-all rule that denies access to anything that does not match any of the CAPs preceding rules.

IdP Discovery Policy

• IdP Discovery Policy determines where to route users when they are attempting to log in to org.
• Users can be routed to a variety of identity providers (SAML2, IWA, AgentlessDSSO, X509, FACEBOOK, GOOGLE, LINKEDIN, MICROSOFT, OIDC) based on multiple conditions listed below.
• All Okta orgs contain one and only one IdP Discovery Policy in immutable default rule routing to org’s login page.

WebFinger

WebFinger interface is to allow a client application to determine the Identity Provider that a given username (or identifier) should be routed to based on your organization’s Identity Provider Routing Rules (IdP Discovery Policy).

Request Example

curl -v -X GET \
-H "Accept: application/jrd+json" \
-H "Content-Type: application/json" \
"https://${yourOktaDomain}/.well-known/webfinger?resource=okta:acct:joe.stormtrooper%40example.com"

Response Example

In this example, there is a rule configured that has a user identifier condition which says that users with the domain example.com should be routed to a configured SAML IdP:

{
    "subject": "okta:acct:joe.stormtrooper@example.com",
    "links": [
        {
            "rel": "okta:idp",
            "href": "https://${yourOktaDomain}/sso/idps/0oas562BigqDJl70T0g3",
            "titles": {
                "und": "MySamlIdp"
            },
            "properties": {
                "okta:idp:metadata": "https://${yourOktaDomain}/api/v1/idps/0oas562BigqDJl70T0g3/metadata.xml",
                "okta:idp:type": "SAML2",
                "okta:idp:id": "0oas562BigqDJl70T0g3"
            }
        }
    ]
}

Request Example

curl -v -X GET \
-H "Accept: application/jrd+json" \
-H "Content-Type: application/json" \
"https://${yourOktaDomain}/.well-known/webfinger?resource=okta:acct:joe.stormtrooper%example.com&rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer"

Response Example

In this example, there is already a rule configured that has a user identifier condition which says that users with the domain example.com should be routed to a configured SAML IdP. However, we supplied a rel parameter of http://openid.net/specs/connect/1.0/issuer that limited the result to Okta:

{
    "subject": "okta:acct:joe.stormtrooper@example.com",
    "links": [
        {
            "rel": "https://openid.net/specs/connect/1.0/issuer",
            "href": "https://${yourOktaDomain}/sso/idps/OKTA",
            "titles": {
                "und": "{subdomain}"
            },
            "properties": {
                "okta:idp:type": "OKTA"
            }
        }
    ]
}

Session Token

• A session token is a one-time bearer token that provides proof of authentication and may be redeemed for an interactive SSO session in a user agent.
• Session tokens can only be used once to establish a session for a user and are revoked when the token expires.
• Okta provides a very rich Authentication API to validate a user’s primary credentials and secondary MFA factor.

Session Cookie

• Okta utilizes a HTTP session cookie to provide access to Okta organization and applications across web requests for an interactive user agent such as a web browser.
• Session cookies have an expiration configurable by an administrator for the organization and are valid until the cookie expires or the user closes the session (logout) or browser application.
• A session token is returned after successful authentication which can be later exchanged for a session cookie using one of the following flows:
  • Retrieving a session cookie by visiting the OIDC Authorization Endpoint
    • https://your-app.example.com?id_token=S4sx3uixdsalasd &state=Af0ifjslDkj&nonce=n-0S6_WzA2Mj
  • Retrieving a session cookie by visiting a session redirect link
    • https://${OktaDomain}/login/sessionCookieRedirect?token=S4sx3uixdsa &redirectUrl={redirectUrl}
  • Retrieving a session cookie by visiting an application embed link
    • https://your-subdomain/app/google/go1013td3mXAQOJCHEHQ/mail?sessionToken=S4sx3uixdsa

Users States

 

StatusCauseStagedAccounts become staged when they are first created, before the activation flow is initiated or if there is some administration action pending.Pending user actionAccounts that are pending user action have been provisioned, but the end user has not provided verification by clicking through the activation email or providing a password.ActiveAccounts become active when

• You add a user (Add Person) in the Manage users page and you set the user password without requiring email verification.
• An end user self-registers into your custom app or the Okta Homepage and email verification is not required.
• You explicitly Activate and deactivate users

Password ResetAccounts are in a password reset state when

• The account requires a password to be set for the first time.
• End users request a password reset or you initiate one on their behalf.

Note: Password Reset is considered an Active state.

Locked outAccounts become locked out when they exceed the configured number of login attempts which are set when you configure password policies.

Note: Locked out is considered an Active state.

SuspendedAccounts are in this state when you explicitly Suspend and unsuspend users.

Note: Suspended is considered an Inactive state.

DeactivatedAccounts are deactivated when you explicitly Activate and deactivate users.

Note: Deactivated is considered an Inactive state.

Administrator Dashboard

Tasks Page

• Tasks Page provides detail about the tasks listed in the Status section of the Dashboard page.
• If you have a large number of deprovisioning tasks, timeouts might occur when you try to load the Tasks page.
  • Make sure you regularly mark these tasks as completed.
  • You can either select Mark All Complete on the Tasks page or select the Application accounts need deprovisioning link and mark specified tasks as complete.
  • If you do not want deprovisioning task alerts to appear on this page, select Don’t create deprovisioning tasks on the Tasks page.
• Tasks are created during group app assignments and individual app assignments.
  • Convert a group assignment task -> individual assignment;
    • However, the conversion is permanent, as you cannot convert an individual assignment to a group assignment.
  • This conversion is useful if you make a change to the task that a future change to the group could override.
• Marking tasks complete processes the tasks on the jobapp servers, so if processing a large number, we recommend doing so during off-peak hours.
• If a user is missing a required attribute that is needed for an application to be assigned, the application will not be assigned at all.
  • If a provisioning error occurs for an application, the application is still assigned to users, but an error task/warning is displayed in the application list in the User Profile page.
  • In this case the application will not show up in the application in the User Profile page and a task is created on the dashboard.

Support

• Customer Support Ticket Severity / Priority Definition
• Trust
• Okta Product Roadmap

HealthInsight

• HealthInsight audits an organization’s security settings and suggests recommended tasks to improve security posture.
• These security recommendations are intended primarily for admins that manage employees within their organization.
• Security tasks and recommendations

ThreatInsight

• ThreatInsight aggregates data across the Okta customer base and uses this data to detect malicious IP addresses that attempt credential-based attacks.
• Note: The Okta Model for threat detection is based on a continuous evaluation of the latest data available.
• If Okta incorrectly identifies any trusted IP addresses as suspicious, you may exempt them from ThreatInsight as needed.
• Refer to Exempt Zones for more details.

---

RADIUS Integration

Okta Device Trust Solutions

• Devices
• Okta Device Trust contextual access management solutions enable organizations to protect their sensitive corporate resources by allowing only end users with managed devices to access Okta-integrated applications.

1. Part Ⓐ — In Okta: Enable the global Device Trust setting for your org
2. Part Ⓑ — On Admin’s computer: Modify the Okta Device Registration Task
3. Part Ⓒ — In Jamf Pro: Add the modified Okta Device Registration Task to Jamf Pro and distribute it to macOS devices
4. Part Ⓓ — In Okta: Configure app Sign On policy rules in Okta
5. Part Ⓔ — In Okta: Revoke and remove Device Trust certificates
6. Part Ⓕ — In Jamf Pro and on macOS computers: View certificate enrollment logs (optional)
7. Part Ⓖ — In Jamf Pro: Modify the app whitelist (optional)

Linked Objects API

Represent user relationships.

• Create a linked object definition such as Manager:Subordinate. These pairs are represented by a primary attribute and an associated attribute.

For each relationship:

• A user has at most one primary link (a user has a single manager) but can have many associated links (a user can have many subordinates).
• A user can be the primary in one relationship and the associated in another.
• A user can be both the primary and associated in the same relationship.

WiFi Profiles and Policies

• This allows end users to join an established WiFi network without having to enter any security information.
• Allows you to create multiple WiFi profiles and assign them to OMM-enrolled mobile devices so that users are no longer limited to just one WiFi profile per device.
• Supports the WPA/WPA2 Enterprise protocol to enable the following:
  • Username and password authentication with a RADIUS server (no longer limited to shared key authentication)
  • The option to add one or more server certificates needed to establish a secure connection to the WiFi network
  • The shared key is currently unmasked.
  • Authentication with user credentials is not supported.
  • Certificate-based authentication is not supported.
  • Connection to hidden networks is not supported on Android devices.
  • WiFi Policies feature supports only one WiFi policy on a device at one time. To support multiple WiFi profiles on a device, see Configure a WiFi profile.