Okta Workforce Identity

IAM Challenges

1. User Password Fatigue
2. Failure-Prone Manual Provisioning & De-Provisioning Process
3. Compliance Visibility: Who Has Access to What?
4. Siloed User Directories for Each Application
5. Managing Access across an Explosion of Browsers and Devices
6. Keeping Application Integrations Up to Date
7. Different Administration Models for Different Applications
8. Sub-Optimal Utilization, and Lack of Insight into Best Practices

How do companies currently manage their user identities?

1. IT-Managed Lifecycle Management
2. HR-Managed Lifecycle Management

Universal Directory

UD has following profiles:

1. Okta User Profiles
   • Every kind of account, no matter how they are mastered, has an Okta user profile.
   • The base Okta user profile has about 31 attributes by default which cannot be removed, but can add as many custom attributes.
2. Directory Profiles
   • If your accounts are mastered by AD, we can map the AD profile attributes to the Okta user profile attributes as needed.
   • Schema Discovery to get AD attributes to Okta.
   • When you set up an integration with AD, you see that Okta has pre-selected several of the most common attributes in AD to bring into Okta. This is done when setting up the directory user profile during Step 3 of the Active Directory integration process.
   • Supports custom attribute as well.
3. Application Profiles
   • Box has 4 attributes in its user profile.
   • Google has over 200 attributes in its user profile.
   • Salesforce, which has a custom schema, can have all different kinds of attributes.
   • So these application user profiles can really look drastically different than say the Okta user profile because the information they need will vary depending upon the application.
   • Application User Profiles that are UD Enabled will have the ability to perform schema discovery, enabling Okta to read the attributes in the application profile and connect them to Okta.
4. Identity Providers Profiles
   • There may be profiles you see for IdPs such as in a Business to Consumer (B2C) scenario where we want to let our users login with an application like Facebook.
   • Facebook can become the IdP thru the notion of social authentication.
   • Okta becomes the Service Provider, offering an enterprise grade solution around this scenario.

Profile Mappings, Profile Masters, Profile Editor

• Profile Mappings -> Mapping between source and target and vice-versa.
  • Schema Discovery discovers attribute-metadata from source or target apps.
  • Expression language useful to transform the attribute in and out of Okta.
• Profile Editor -> Helps to add/ edit/ delete custom attributes and edit regular attributes.
• Profile Masters -> Tells which is a user source of truth for user profile attributes in Okta. eg: Okta, Directory or App.
  • Currently, if more than one profile master exists on the Profile Masters page, they can be prioritized so that end users can be mastered by different systems, based on their assignments.
  • At any given time, there can only be one profile master that masters a user’s entire profile.
    • A user can only be mastered by a single application or directory at any one time.

Attribute Mappings

Profile mappings allow administrators to precisely control the attributes exchanged during provisioning processes. The two chief use-cases that UD facilitates are:

App to Okta

• In this use-case, organizations typically use a source-of-truth app such as a directory or HRMS.
• Some organizations might have several sources of truth.
• Mappings define how attributes from these various sources are imported into the Okta user profile.

Okta to App

• In this use-case, organizations want to propagate the data in Okta to other applications to provision accounts and update accounts with rich data.
• This is possible if the Okta user profile has rich attributes and the app in Okta is UD-upgraded.

 

Attribute-Level Mastering

• Attribute Level Mastering (ALM) delivers finer-grain control over how profiles are mastered by letting you specify different profile masters for individual attributes.
• Without it, all of a user’s attributes are mastered by a single profile master.
• Setting up ALM:
  1. Enable Profile Mastering
  2. Prioritized profile masters on the Profile Masters page
     • 
     • From the Directory drop-down menu, select Profile Editor.
       • From the Master priority drop-down list, select one of the following:
         • Inherit from profile master: Picks up the default profile master for the entire profile, as shown in the Profile master priority field.
         • Inherit from Okta: Picks up this particular attribute value from Okta. This attribute value can be edited in three ways: via the user’s Profile tab, the Okta API or, if appropriate for end-user modification, by the end user.
         • Override profile master: Overrides the default profile master. Click the Add Master drop-down menu to choose another available profile master. Note that this option does not generally disable the app as a master.

         

  3. Desired mappings are specified through UD mapping
     • The optional third step of setting up ALM is to map the attribute through UD. If you changed an attribute’s Master priority to Override profile master, for example, the attribute now has a null value and must be mapped. To map the attribute, do the following:
     • 

Example Profile Master Set
Profile master: Default master for the entire profile.	Workday, Active Directory
Attribute master: Alternative master for a particular attribute.	3rd attribute: mobile phone = Active Directory All other attributes: Workday
Example Attributes
First name	Workday
Last name	Workday
Mobile phone	Active Directory
Work phone	Workday

Enable both Profile Master and Push

• App (master) <-> Okta <-> App or Okta (master) <-> App <-> Okta 
• Enabling Profile Master and Update User Attributes for the same application allows to push Okta to App profile mappings to your highest priority profile master.
• This is beneficial when you want to sync attributes from downstream applications back to the profile master, like an email address and phone number from an app back to the master Workday profile.
• However, you may lose data if an app that you designate as profile master can also receive profile updates from Okta.
• Caution: Enabling both Profile Master and Update User Attributes for the same app may result in:
  • Unwanted profile pushes – Okta updates can overwrite the values of unmapped attributes in an app, even if that app is the highest priority profile master. For example, if the cn attribute is not mapped from Active Directory to Okta, and you’ve configured Active Directory for Profile Master and Update User Attributes, Okta will apply a default mapping to cn.
  • Overwritten IdP-mastered attributes – Okta to App updates can overwrite attributes that are mastered by another identity source. There’s no partial push option.
  • Race conditions – Okta can overwrite an updated attribute in an identity source before other updates are pushed back to Okta.
    • For example, consider a scenario in which a user’s first name and last name are imported into Okta from a directory, but the user’s email address is imported into Okta from an app. If the user’s last name changes in the directory before the applicable email address update is made in the app, Okta could push the new name and the old email address to App.

Username Overrides

• Username override can also be used with Selective Attribute Push to continuously update app user names as user profile information changes.
• For example, if a user gets assigned to an app with a username of email, and that email subsequently changes, Okta can automatically update the app username to the new email.
• Prior to this enhancement, an Okta admin had to manually change a user’s app username by unassigning the user and reassigning him to the app.
• This enhancement applies to all apps and is not limited to only apps with provisioning capabilities.

Overriding the App username

• For the Okta to App flow, you can no longer override username mappings in Profile Editor.

• The username mapping displayed in the app’s Sign On tab will be the source of truth for the Okta To App flow.
• Updating the username mapping on Create only or Create and Update will also be managed from the app’s Sign On tab.

Overriding an Okta username

Exclude username updates during provisioning

People

There are 3 types of people or user accounts that can exist within Okta:

1. Okta-Mastered people
2. Directory-Mastered people
3. Application-Mastered people

1. Okta-Mastered People can only be added to Okta groups (groups created in Okta), as opposed to groups that have been imported from an external directory service such as Active Directory Groups or LDAP groups.

1. • Login via Okta Password policy and they are governed by the Okta User Profile, which is to say that the primary source of truth for the user’s attributes is the Okta User Profile.
   • Any active user can be assigned an Okta Administrator role (both Okta-Mastered and Directory-Mastered people, are eligible for admin role assignment).
   • Okta Super Admin and Org-Admin are in charge of managing the password policy for Okta-Mastered accounts.
   • When importing people records via the CSV template, you cannot import more than 10k records per file, and the file size cannot exceed more than 10MB.
   • As a best practice, you will need to create at least two Okta Admin Service Accounts and assign Super Admin rights to the accounts.
2. Directory-Mastered people log into Okta using the same credentials they would use to log into their on-premise workstation.

• • Directory-Mastered people are governed by the Directory user profile—management of user attributes must be done in the directory service.
  • By default, Directory-Mastered people cannot change their directory-linked password within Okta.
    • However, an Okta Super Administrator can configure the Directory Password policy in Okta to enable this ability.
  • Directory-Mastered people can be associated with both Okta groups and Directory groups.
  • AD app user profile schema requires both the first and last name.
  • You can create an Okta mastered user without a first or last name, but you cannot import an AD user into Okta without a first and last name.
  • Delegated authentication and Just-in-Time provisioning will automatically be enabled as part of your AD/ LDAP installations.
  • System Requirements 
    • Windows server must be running Windows Server 2008 R2 or newer and have at least 256 MB of RAM available.
    • The host server of the agent must also be a member of the same domain as the Active Directory users.
    • The Windows server where the agent resides must be on at all times. In other words, don’t install it on your own desktop or laptop. The agent host server must have a continuous connection to the internet so it can communicate with Okta.
    • Best practice: ensure high availability and provide a failover if need be, you should install at least 2 Okta Active Directory agents on two different servers connected by any one domain.
      • That is to say 2 agents for every domain. You can either install the Okta Active Directory agent on domain controller and/or any two active servers connected to domains.
  • OUs
    • Organize people and groups into AD OUs.
    • Okta will only import users accounts and groups within OUs.
  • User Accounts for AD agent
    • A local AD domain administrator account to run the Active Directory agent installer; this is only required for the installation.
    • An Okta Super Admin account.
    • An Okta-AD service account which is created via the integration wizard and becomes a service account that the service runs after installation.
      • This account serves as the liaison between AD and Okta, and by default has read only access to AD.
      • It is the AD Agent that will pull information from AD into Okta and keep that information synchronized.
  • User Accounts for LDAP agent
    • A local LDAP service account which will be created during the installation process of the LDAP agent.
    • An Okta administrator account which will be used to connect Okta to the LDAP agent.
    • A LDAP user which must have the ability to look up users and groups or roles within the Directory Information Tree.

 

JIT

• JIT account creation and activation only works for end users not already 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 activated or not-activated are not eligible for JIT activation.
  • When JIT is enabled, users do not receive activation emails.
• If delegated authentication is enabled, NO need to import users from AD first for JIT provisioning to create Okta accounts.
• If NO delegated authentication enabled, MUST import the AD accounts first, and they must appear on the imported users list for JIT provisioning to create Okta accounts.

• JIT automatically:
  • Confirms and activates the account.
  • Updates any attributes for accounts already activated, when the person next logs into Okta.

Schedule import allows how often you want to run scheduled imports of people records from Active Directory into Okta.

• With each import:
  • Any user attributes that may have changed in AD will be updated.
  • Any new user accounts created in AD since last import will be imported.
• Always manually initiate the importing process from the Import tab.

Import Matching Rules has two steps:

1. Matching the imported users:
   • Exact match:
     • username
     • email
     • attribute (base or custom)
     • attribute combination
   • Partial match:
     • Partial matching of:
       • firstName
       • lastName
     • No match of:
       • username and/or
       • email
2. Confirm the imported users:
   • Confirm matched users: Select to automate the confirmation or activation of existing users.
     • Unchecked, matches are confirmed manually.
   • Confirm new users: Select to automate the confirmation or activation of a newly imported user.
     • If this option is selected, you can uncheck it during import confirmation.
     • Note that this feature does not apply for users who already exist in Okta.
   • If activated JIT, no need to confirm or activate the users. Users are activated during signin.

Profile & Lifecycle Mastering

App to profile master Okta users.

Once enabled, the app appears in the list of profile masters on the Profile Masters page.

• Allow <app> to master Okta users: Determine what happens when a user is deactivated or reactivated in an app.
  • Only the highest priority profile master can deactivate or suspend an Okta user.
• When a user is deactivated in the app: Choose to: 
  • Deactivate
  • Suspend
  • Do nothing:
    • App controls user cycle but allows profile master of attributes and mappings.
• When a user is reactivated in the app: Choose whether reactivation in the app applies to suspended or deactivated Okta users.
  • Reactivated in the app, the user profile must be an exact match to the Okta profile.
  • Otherwise, after importing the reactivated users, they appear in Pending Activation state.

Clearing unconfirmed users

Allows admins to clear all unconfirmed users within an import queue.

• Impossible to select and remove specific users at this time.
  • The only option is to clear all users.
• If an admin mistakenly clears all users from the queue, they can rerun a full import to restore the queue back to its prior state.
  • To restore the import queue, an incremental import will not suffice—a full import is required.
• Also note that, if an existing (scheduled or manual) import is actively running, admins cannot clear users. The Clear Unconfirmed Users button is unavailable until that previous import is complete.
• If a scheduled or manual import is started during a clearing process, it is queued up to begin as soon as the previous operation completes.

 

Import Users from App

Directory

• Directory Integration for All Cloud Apps
  • UD is made available to all Cloud Apps
  • For AD integration, Okta provides three lightweight and secure onpremises components:
    • Okta Active Directory Agent: A lightweight agent that can be installed on any Windows Server and is used to connect to on-premises Active Directory for user provisioning, deprovisioning, and authentication requests.
    • Okta Integrated Windows Authentication (IWA) Web Application: A lightweight web application that is installed on an IIS and is used to authenticate domain users via Integrated Windows Authentication.
    • Okta Active Directory Password Sync Agent: A lightweight agent installed on your domain controllers that will automatically synchronize AD password changes, send to Okta, and keep your user’s AD passwords in sync with the apps they use.
  • For LDAP integration, Okta provides a single lightweight and secure on-premises component:
    • Okta LDAP Agent: A lightweight agent that can be installed on any Windows Server and is used to connect to on-premises LDAP user stores for provisioning, de-provisioning, and authentication requests.
• Simple and Secure Setup and Configuration
  • DelAuth, and JIT are turned on by default.
    • Users can immediately JIT in without any previous import (because of DelAuth)
  • On every DelAuth or JIT request, Group memberships are also imported.
  • Users are fully updated on every login and asynchronously.
  • Admins can change OUs, user profile and group information in AD and users will be fully updated in Okta.
• Real Time Synchronization
  • Sync when authN.
  • Group memberships are imported in addition to the full User profile.
• JIT User Provisioning
  • Possible of automatic user account creation in Okta the first time a user authenticates with:
    • Active Directory (AD) Delegated Authentication
    • Desktop SSO
    • Inbound SAML
  • 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 JIT activation.
  • When JIT is enabled, users do not receive activation emails.
  • If delegated authentication is enabled,
    • Yes, no need to import users from AD first for JIT provisioning to create Okta accounts.
    • No, then must import the AD accounts first, and they must appear on the imported users list for JIT provisioning to create Okta accounts.
• Delegated Authentication
  • AuthN at AD and it says YES or NO response for authN request.
• Desktop Single Sign-On
• Self Service Password Reset Support
  • Updates both AD and Okta password for a user.
• Security Group (SG) –Driven Provisioning
  • Bulk provisioning/ deprovisioning possible.
• Deprovisioning
• SSO for Authenticated Apps resides inside On-prem
  • SSO to local AD apps using SWA after authN with Okta (IdP-init)

AD config in Okta

By default Okta uses the Okta user profile user name during delegated authentication. For example, if the AD app-user user name is samAccountName (domain\jdoe) and the Okta user profile user name (login field) is UPN, then Okta use UPN (jdoe@domain.com) to log in the user.

Okta username format  — The username format you select must match the format you used when you first imported users. Changing the value can cause errors for existing users. Choose one of the following options:

• Custom  — Select this option to use a custom user name to sign in to Okta. Enter the Okta expression language to define the Okta user name format. To validate your mapping expression, enter a user name and click the view icon.
• Email address  — Select this option to use an email address for the Okta user name.
• SAM Account name  — Select this option to combine the SAM Account Name and the AD domain to generate the Okta username. For example, if the SAM Account Name is jdoe and the AD domain is mycompany.okta.com, then the Okta username is jdoe@mycompany.okta.com.
• SAM Account name + Configurable Suffix  — Select this option to combine the SAM Account Name and a configurable suffix to create the Okta user name. When using this option, do not include the @ character before the Configurable Domain.
• User Principal Name (UPN)  — Select this option to use the UPN from AD to create the Okta user name.

Note: All Okta users can sign in by entering the alias part of their user names as long as it maps to a single user in your organization. For example, jdoe@mycompany.okta.com could sign in using jdoe.

USG support  — Select Universal Security Group Support to ignore domain boundaries when importing group memberships for your end users. This assumes that the relevant domains are connected in Okta. You must also deploy an AD agent for every domain in your forest that contains the USG object that you want to sync with Okta. Each connected domain then imports its groups. When a user’s group memberships match any groups that were imported (from any connected domain in the forest), Okta syncs the memberships for the user to each group.  Only groups from connected domains are imported. This setting requires JIT provisioning.

Max Import Unassignment  — Click edit to modify the value that the number of app unassignments stops. The default is 20%. This action prevents accidental loss of user accounts. This setting affects all apps with imports enabled. See Import safeguards.

Desktop Single Sign-On (DSSO)

Allow users to log in to their AD-connected computer and extend that Single Sign-On (SSO) experience through to Okta.

• This means that logging into a user’s Windows machine gives them direct access to their Okta-configured applications, and reduces the number of logins needed to access both company and cloud-based applications to one.
• The AD-version of this is also known as Integrated Windows Authentication (IWA).
• Download and install Okta’s IWA web application, configure the relevant IP ranges, and the setup is complete.
• DSSO is not supported for LDAP.

Two methodologies are available for DSSO implementation:

• Agentless (recommended)
• IWA web agent running on premises

Agentless Desktop Single Sign-on – uses Kerberos

• You have an Active Directory domain (or multiple domains) integrated with your Okta org.
• In order for Okta to negotiate Kerberos authentication for agentless DSSO, you need to create a new service account and set a Service Principal Name (SPN) for that service account. This will delegate Kerberos authentication to external service, rather internal Windows Kerberos authentication.

setspn -S HTTP/<myorg>.kerberos.<okta|oktapreview|okta-emea>.com <ServiceAccountName>>

• Where HTTP/<myorg>.kerberos.okta.com is the SPN. <ServiceAccountName> is the value you used when configuring the Early Access version of Agentless DSSO and <oktaorg> is your Okta org (either oktapreview, okta-emea or okta). For example, setspn -S HTTP/atko.kerberos.oktapreview.com atkospnadmin.

Okta IWA Web agent for Desktop Single Sign-on

Flow 1:

Flow 2:

In simple steps:

1. User navigates to https://mycompany.okta.com.
2. The user is redirected to the locally installed IWA web application.
3. The IWA web application transparently authenticates the user via Integrated Windows Authentication (Kerberos).
4. The user is redirected back to the Okta login page with cryptographically signed assertions containing his AD user identity.
5. The Okta service validates the signed assertions and sends the user directly to his Okta home page.

DSSO-JIT

• For agentless DSSO, the web browser sends the Kerberos ticket to Okta, and relies on the AD agent to look up the UPN. Kerberos validation is done in Okta cloud.
• For on–premises DSSO, IWA sends Okta an UPN. Okta uses the UPN to locate a user. Okta does not perform user authentication because Kerberos validation is done on the IIS side.

When a user signs in using DSSO:

• If their information is already imported and active in Okta: Okta uses the UPN to look up the user. If Okta finds the user, the profile reloads from Active Directory (AD) and the user signs in successfully.
• If their information has been imported but is not yet active in Okta: Okta uses the UPN to look up the user. If Okta finds the user, the user profile loads from AD, the user is activated, and the user signs in successfully.
• If their information has not been imported into Okta and JIT is enabled: Okta can only validate the user by the UPN. So the Okta user name format must be the UPN in order for the user to be successfully imported with JIT enabled. If the user name format is something other than the UPN, for example the email address or SamAccountName, the search cannot locate the user.
• If the their information has not been imported into Okta and JIT is off: Sign in fails.

MFA

• https://webauthn.singularkey.com/
• https://www.okta.com/security-blog/2019/04/the-ultimate-guide-to-fido2-and-webauthn-terminology/

1. Knowledge factors based on something the user knows: Passwords
2. Possession factors based on something the user has: Yubikey
3. Biometric factors based on something the user is: Fingerprint

Factor Types

Okta’s Multi-Factor Authentication can be divided into 4 categories of 2FA types:

1. Security Question
2. Soft-Based Token
   1. Okta Verify
   2. Google Authenticator (Time-based One-time Password Algorithm-TOTP)
3. Phone
   1. SMS Authentication
   2. Voice Call Authentication
4. Third Party
   1. Symantec VIP
   2. RSA SecurID
   3. Duo Security
   4. Yubikey
   5. U2F (2FA-open standard by FIDO Alliance)
   6. WebAuthn (2FA-web standard by FIDO Alliance)
   7. Windows Hello (by MSFT)

• Push verification such as Okta Verify Push is more effective than OTP against traditional phishing.
• However, for stronger resistance, use FIDO-based factors such as U2F, Windows Hello, or WebAuthn.

Factor Enrollment

• MFA Policy allows to use which 2FA (optional, required) to be used for which groups?
  • It is always best practice to never change a Default Policy in Okta.
  • This is strongly encouraged mainly because the Default Policy will always be the least restrictive, ensuring that you, as an admin, will never lock yourself out of your Okta org.

• MFA Rule allows to exclude users, allow particular conditions like IP address (N/w Zones) and then allow this particular factor for 1st time enrollment or every time.
• Okta Sign-On Policy controls the manner in which a user is allowed to sign on to Okta, including whether they are challenged for MFA and how long they are allowed to remain signed in before re-authenticating.
• Application Sign-On Policy can configure MFA at the application level. By adding MFA to an app, you provide an additional layer of security for specific apps.

SSO Categories

• SAML/ WS-Fed
• OIDC
• SWA

• • Uses Okta browser plugins to securely pass credentials into web forms on behalf of the authenticated Okta User.
  • SWA was created by Okta to provide single sign-on for applications that don’t support proprietary federated sign-on methods or SAML.
  • SWA applications are typically used to connect consumer type applications such as LinkedIn or Facebook.

Provisioning

Possible via:

1. Agent-based Provisioning 
   • Active Directory
   • LDAP
   • On Premise Provisioning
     • This agent is generic and intended to connect to any On-Prem resource that can use the SCIM.
   • This is a good, robust strategy. However, it is limited to on-premise applications.
2. API-based Provisioning
   • The Okta app connector has been integrated to the Application’s Provisioning API
   • Typically these provisioning APIs are proprietary and they use the REST model
   • Available functionality from the CRUD feature set is limited to functions published in the App’s API.  For example, some API’s may allow Create and Update, but not Deprovision.
   • This is the best, most extensible strategy.
3. SAML JIT
   • This permits Creation and Updates of downstream users.
   • This does NOT permit Imports or Deprovisioning of downstream users
   • The triggering action is a user’s login attempt, rather than the Administrator’s assignment action.
     • This limits the flexibility of the timing of account creation, as accounts in the application cannot be created proactively using this method.
     • This strategy can be leveraged to feed the Okta Profile itself via UD mappings.
     • Common use case is for customers who have an existing, on-prem IDP (ADFS, for example) but still want to use cloud apps through Okta.
       • Configured using SAML JIT with an Inbound SAML connection
   • This is the most restricted, inflexible strategy. However, it can be a lifesaver for the initial deployment of legacy applications.

On-Premises Provisioning

• Okta provisioning agent polls Okta for any provisioning event.

Office 365

With regards to Office 365, Okta can do 2 very important things for you:

1. Federate (or SSO) using WS-Federation.
2. Provision users, a key part of the User Lifecycle Management flow (uses SCIM).

Provisioning Types

1. Profile Sync, also referred to as Version 0, synchronizes only the basic profile in Office 365, consisting of 5 attributes.
   • In order to create an Okta/ Cloud-mastered user, you are required to provide 4 attributes: last name, first name, username, and primary email address.
   • Profile Sync synchronizes these 4 required attributes, plus the Display Name attribute. When using Profile Sync, Okta is leveraging the SOAP APIs.
2. User Sync, also referred to as Version 1, will synchronize a user’s full profile in Office 365, consisting of over 20 attributes.
   • This is the option which is used for provisioning any Okta/ Cloud-mastered accounts you have.
   • When deploying User Sync, Okta leverages the Graph APIs and is also able to assign licenses and roles to users.
3. Universal Sync, also referred to as Version 2, should be selected when you have Active Directory-mastered users.
   • This provisioning option will synchronize over a 100+ user attributes in Office 365 + directory objects, such as Contact and Distribution Lists.
4. License or Role Management only, this option will be used by those organizations that will be using the Microsoft Provisioning option Azure Active Directory Connect or Azure AD Connect.
   • This will be the case for organizations which use an on-premise Exchange Server creating a “hybrid” or “write-back” scenario.
   • Note that Microsoft provisioning cannot assign licenses to users so, in such a scenario, you can use Microsoft provisioning to provision your Directory-mastered users and then leverage Okta’s license/role management provisioning to assign Office 365 licenses to users.

Notes

• User Sync and Universal Sync cannot be used with DirSync, Azure Active Directory Sync, or Azure Active Directory Connect.
• Once you select User Sync or Universal Sync, you can not modify your selection back to Profile Sync.

Requirements

1. Register your company’s public domain with your Office365 tenant. This is true for all implementations. True for all implementations:
2. Set default domain correctly. True for all implementations.
3. Prepare your directory for either: Microsoft provisioning or Okta provisioning. And, if you’re using Okta provisioning, which Okta provisioning option is best for you?
   1. Microsoft Provisioning: Cloud Exchange server write back to On-premise server.
      • 
   2. Okta Provisioning
      1. User Sync : Okta-mastered users (cloud-based users) -> O365
         • Configure the Office 365 application in Okta and select the Okta provisioning option of User Sync.
         • This option will sync the Okta user’s full profile, consisting of 20+ attributes depending on whether you have added any custom attributes, into Office 365.
         • 
      2. Universal Sync: Active Directory-mastered users -> O365.
         • Configure the Office 365 app in your Okta org and select Universal Sync as the Okta Provisioning option.
         • Transform data within Okta to meet Office 365 requirements—such as username and email address—and verify that your company domain name is correct.
         • Execute a PowerShell script to turn on federation (SSO) at which point all users will be required to authenticate through Okta to access Office 365.

NOTE: First, use SWA sign-in option (just a place-holder) to make sure provisioning users works and then enable WS-Fed sign-in option (if provisioning works). This is because, provisioning of user must happen first in O365 and then user federation, because federation requires user present in O365.

Data Transformation

1. Email Address: Change in Profile Mappings of Universal Directory using Expression language.
   • Eg: alice@oktaice.com (source.mail) -> alice@oktaedu007.com (Mail)
   • String.substringBefore(source.email, “@”) + oktaedu007.com
   • Preview function is available.
2. Application Username
   • Change in O365 App -> Sign-on tab -> CREDENTIAL DETAILS -> Application Username Format -> Custom using Expression language.
   • Same example as above.

Test Provisioning

• Test users are synced from Okta-> O365.

Setting Up WS-Federation

• Configure WS-Federation yourself using PowerShell or let Okta configure WS-Federation automatically (provide O365 Admin cred).

Best Practices

1. A default domain cannot be federated.
2. Create an In-Cloud Global Administrator account in Office 365 so that you can always have a side door into your tenant.
3. Create an Okta-Mastered Super Administrator in Okta to set up the Microsoft Office 365 integration.
4. Verify that your Okta provisioning is working before you federate to ensure that you have your accounts set up properly inside Office 365.
5. Never delete the Office 365 app in Okta once federated.
6. For O365 use either: SWA and WS-Fed authentication type.
7. Okta removes the domain federation in the following cases:
   • If you switch from WS-Fed to SWA
   • If you delete the app instance

Okta Mobile

• Okta Mobile Management (OMM) – > is a Mobile Device Management (MDM).
  • Manage and take complete control of user devices remotely.
  • Requires corporate certificate to Install-Profile by user by forcing.
• Okta Mobile App -> Okta App
• Okta Mobile Connect (OMC) -> SSO to native apps.
• Box for EMM (Enterprise Mobile Management)
• Mobile Policy to allow/ disallow particular devices (disallow Android devices)
• Mobile App Store -> Corporate mobile app store contains list of allowed native apps that user is allowed to install and make use of Okta SSO.
• Device Lifecycle Management is easy administration of mobile devices that corporate own devices using Okta.
  • It can deprovision device, wipe data, lock device, etc.
• MAM: 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.

Security Policies

• Policies are the first line of defense in keeping an organization secure.
• Okta policies allow control of various elements of security, including:
  • end-user passwords (PASSWORD-POLICY)
  • authentication challenges a user receives (SIGN-ON POLICY)
  • devices they can use (DEVICE POLICY)
  • places they use them from (MFA POLICY)
• A policy can be based on a variety of factors, such as location, group definitions, and authentication type.
• The default password policy is applied when a user is created.
• Ensure that any restrictive rules are placed at the top of the Priority list.
  • If “Everyone” were on top, special conditions would not apply and a policy evaluation would be unnecessary.
• If multiple rules are present and the conditions of the first rule are not satisfied, Okta skips this rule and evaluates the following one.
• Password Policy Types:
  • 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.
  • 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.
  • Active Directory Policy
    • If you currently have one or more Active Directory (AD) integrations, an AD policy is automatically created for you.
    • Customize the elements of the policy and its rules.
• Rules are used to define under which circumstances the policy applies.

Various policies are:

1. Sign-On Policy
   • Okta Sign On Policy controls the manner in which a user is allowed to sign on to Okta, including whether they are challenged for MFA and how long they are allowed to remain signed in before re-authenticating.
   • Okta Sign On Policy is different from application sign-on policy, which determines the extra levels of authentication (if any) which must be performed before a specific Okta application can be invoked.
     • Specify any number of policies and the order in which they are executed.
     • There is one required policy named Default – CANNOT be deleted.
     • By definition, the default policy applies to all users.
     • Legacy policy that is present only if you have already configured MFA.
       • This policy reflects the MFA settings that were in place when you enabled your sign-on policy, and ensures that no changes in MFA behavior occur unless you modify your policy.
       • If needed, you can delete it.

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

2. Group Password policy
   • Enforce password settings on the group and authentication-provider level.
   • Enforced only for Okta and AD-mastered users (make sure not conflict with AD password policy).
   • Complexity requirements are evaluated at the point in time when the password is set.
   • Password expiration is evaluated based on the current policy and when the user last set their password, unless the user’s password is already expired in which case it remains expired.
   • Lock-out and recovery strategy.
   • For AD-mastered users, the AD complexity requirements should reflect the AD instance.There are three general guidelines for password policy evaluation.

   • {
         "type": "OKTA_SIGN_ON",
         "id": "00pmez6igjv4TYOLl0g3",
         "status": "ACTIVE",
         "name": "Sales Policy",
         "description": "Policy for Sales Department",
         "priority": 1,
         "system": false,
         "conditions": {
           "people": {
             "groups": {
               "include": [
                 "00gmexWGbl9VauvTP0g3"
               ]
             }
           }
         },
         "created": "2017-01-11T18:53:00.000Z",
         "lastUpdated": "2017-01-11T18:53:00.000Z",
         "_links": {
           "self": {
             "href": "http://ed.okta1.com:1802/api/v1/policies/00pmez6igjv4TYOLl0g3",
             "hints": {
               "allow": [
                 "GET",
                 "PUT",
                 "DELETE"
               ]
             }
           },
           "deactivate": {
             "href": "http://ed.okta1.com:1802/api/v1/policies/00pmez6igjv4TYOLl0g3/lifecycle/deactivate",
             "hints": {
               "allow": [
                 "POST"
               ]
             }
           },
           "rules": {
             "href": "http://ed.okta1.com:1802/api/v1/policies/00pmez6igjv4TYOLl0g3/rules",
             "hints": {
               "allow": [
                 "GET",
                 "POST"
               ]
             }
           }
         }
       }

   • "settings": {
          "password": {
            "complexity": {
              "minLength": 8,
              "minLowerCase": 1,
              "minUpperCase": 1,
              "minNumber": 1,
              "minSymbol": 0,
              "excludeUsername": true
            },
            "age": {
              "maxAgeDays": 0,
              "expireWarnDays": 0,
              "minAgeMinutes": 0,
              "historyCount": 0
            },
            "lockout": {
              "maxAttempts": 10,
              "autoUnlockMinutes": 0,
              "showLockoutFailures": false
            }
          },
          "recovery": {
            "factors": {
              "recovery_question": {
                "status": "ACTIVE",
                "properties": {
                  "complexity": {
                    "minLength": 4
                  }
                }
              },
              "okta_email": {
                "status": "ACTIVE",
                "properties": {
                  "recoveryToken": {
                    "tokenLifetimeMinutes": 60
                  }
                }
              },
              "okta_sms": {
                "status": "INACTIVE"
              },
              "okta_call": {
                "status": "INACTIVE"
              }
            }
          },
          "delegation": {
            "options": {
              "skipUnlock": false
            }
          }
        }

3. MFA Enrollment Policy

   • "settings": {
          "factors": {
            "okta_question": {
              "enroll": {
                "self": "OPTIONAL"
              },
              "consent": {
                "type": "NONE"
              }
            },
            "okta_sms": {
              "enroll": {
                "self": "REQUIRED"
              },
              "consent": {
                "type": "NONE"
              }
            }
          }
        }

4. IdP Discovery Policy 

   • The IdP Discovery Policy determines where to route users when they are attempting to log in to your org.
   • Users can be routed to a variety of identity providers (SAML2, IWA, AgentlessDSSO, X509, FACEBOOK, GOOGLE, LINKEDIN, MICROSOFT, OIDC) based on multiple conditions.

   • "actions": {
         "idp": {
           "providers": [ //only supports one value
             {
               "type": "SAML2",
               "id": "0oaoz0zUsohjfrWZ80g3"
             }
           ]
         }
       }

Administrators

1. Super admin role
2. Org admin role
3. Group admin role
4. Group Membership Admin
5. App admin role
6. Read-Only Admin
7. Mobile Admin
8. Help desk admin role
9. Report admin role
10. API Access Management Admin

Customizations

• When making changes to any of the org settings in the User Account section, if it has been more than 15 minutes since you last entered your password, you are prompted to reauthenticate. If multifactor authentication is configured, you are prompted for MFA verification as well.
• Due to a lack of broad support across various browsers, do not use X-Frame-Options to host the custom personal information or change password flows that you configure in this section, as Okta loads these flows as iframes.
• Custom sign-in page is available to end users only when they sign in to Okta through custom URL domain.
  • To learn more, see Customize the Okta URL domain.
• How display language is determined:
  • New end users (not activated) — The Welcome email that Okta sends to new end users is localized in the language in users’ locale property (if specified) instead of the display language configured for your org (if different).
  • Existing end-users (activated) — Okta evaluates these sources in the following order to determine which supported language is displayed to activated end users in their Okta instance:
    • End user’s Display Language setting. 
    • Cookie that holds the web browser’s current language setting.
      • Relevant in a shared-terminal scenario where multiple operators use the same browser.
    • Language configured in the browser settings.
    • Value of the user’s locale property.
    • Org-wide display language is displayed to all users unless overridden by any of the preceding sources.

Reports

Categories:

1. Activity Reports
2. Security Reports
3. System Log Queries
4. Reports

As of September 30, 2019, all reports and System Log events are retained for 3 months (90 days)

1. Activity Reports
   • Activity reports provide you with data that helps you understand how/ usage your end-users are using Okta and the applications and services configured for your Okta environment. Unless otherwise noted, activity reports can be run for all users, an individual user, or groups of users.
     • Okta Usage Report
     • Application Usage Report
     • MFA Usage Report
     • YubiKey Report
     • SMS Usage Report
2. Security Reports
   • Security reports provide you with data that helps you detect potential security risks.
     • Okta Password Health Report
     • App Password Health Report
     • SAML Capable Apps Report
     • Current Assignments Report
     • Recent Assignments Report
     • Proxy IP Report
     • Suspicious Activity Report
     • Deprovision Details Report
3. System Log Queries
   • Auth Troubleshooting section provide links to predefined queries in System Log about the following authentication events:
     • Okta Logins (Total, Failed)
     • SSO Attempts
     • Auths Via AD Agent (Total, Failed)

System Log

• Based on Event Types.
• The System Log displays all events for the last 7 days with default filters.
• A System Log panel on the main Reports page provides links to the System Log with pre-defined filters.
  • For example, clicking on the Agent Activity link will open the System Log displaying only data about Agent Activity events.

 

---

Advanced Server Access (Zero Trust)

• Zero Trust has emerged as the right architecture for the modern cloud (AWS, GCP, Azure).
• This changes the access model significantly, shifting controls from the network layer to the application layer.
• ASA is an application that manages SSH and RDP access to Linux and Windows servers.
• Using Okta as its source of truth, ASA reconciles with your internal servers to provide Zero Trust software that you can use to secure them.
• Team is a named group of users who can authenticate with Okta.
  • A team is an ASA tenant, which is similar to an Okta tenant.
  • All configurations and resources in ASA are scoped to a team.
• Project is like AWS account.
  • Each Project contains resources like EC2, Redis server, etc.
  • Dynamic Credentials: Think of Projects as programmable Certificate Authorities which issue ephemeral certificates in accordance with your RBAC configurations.
  • Each of these certificates contains at least the following information:
    • Project for which the certificate was issued
    • Time at which the certificate expires
    • Username to be used on the server of the ASA user to whom the certificate was issued
  • Since Advanced Server Access credentials are short-lived, and scoped to a project, even if a credential is compromised by an attacker, the attacker has a very limited window of time to use the certificate before it expires, and it is only of use against resources in that project.
• Services
  • Services allow you to authenticate and login to servers using a service user. This enables you to leverage the security of ephemeral certificates when building automation that requires access to remote servers.

Unifying your policies around identity sets the foundation to extend smarter access controls.

• Identity sets foundation -> so that Policies can be clearly attributed and audited towards users/ roles.
• Identity drives security -> so that it provides centralized access control heterogeneous envs (on-prem, clouds).
• Identity defines experience -> so that it automates the lifecycle of identity from end-to-end.

ASA is identity-first access management for servers.

• Uses Ephemeral Credential mechanism that fully eliminates the burden of having to track and manage admin credentials, mitigating risk with much less overhead.
• Client application is installed on users’ workstations to interact with their local SSH tools and communicate with Okta service.
  • Comes with CLI (is stf – ScaleFT) option to perform operations like signin to Okta-ASA, list servers to login to particular server, server/ device-info etc).
• Server Agent enrolled with Okta that manages the local users, groups, and entitlements and also captures all login events for audit purposes.
  • Administrators manages collection of servers associated to RBAC as Projects.
  • Projects is an authorization scope of who can access which servers and what tasks within servers they can perform.
    • Each Project is a dedicated CA (Certificate Authority) minting Ephemeral certificates.
  • Users (UID) and Groups (GID) can assign to Projects to grant access to the servers.
    • Groups can have pseudo access (r-w-x).
    • These are visual representation of user/ group in actual servers.
  • Entitlement is a whitelist of specific commands/ tasks that Users in Group can perform. (eg : web-team group can only run restart-apache, but not restart the DB).
  • Comes with CLI (is stfd):
    • /etc/passwd -> user-group accounts data
    • /etc/sudoers -> admin accounts data
    • /etc/sudoers.d -> entitlement data
  • Server agents is regularly interacts with Okta servers for any update to user status, group membership or entitlements.
    • If user is inactive in Okta, Server agent will update the status in local server and disable the account locally as well.
  • Server Agent is deployed using Terraform script along with other necessary steps in deploying servers (EC2 instance) in IAAS cloud.
    • Enrollment Token is needed to to install/ enroll the Server Agent to communicate to Okta.
    • Once enrollment finishes, Server Agent will bring users, groups, entitlements to provision these locally in the servers.
    • Finally, configure the SSH-server to locally trust the client-certificate (Ephemeral cert) issued by Project as a CA (specific to defined ASA Project)

1. A user logs into a server directly from their local SSH tools, which is integrated with the SSH Client Application.
2. Every login is independently authenticated via Okta, subject to the Sign-On policies you specify and then authorized against the role based access associated with the target server.
3. When access is granted, Project mints a short-lived client certificate scoped to the user, device, and project the server belongs to.
4. This certificate is delivered to the SSH Client Application, which uses it to initiate a secure session with the target server via SSH.
5. The Server Agent captures the login event and delivers to the backend for auditing purposes, or you can stream to your own logging service.

Ephemeral Credential is:

• Given only authenticated/ authorized for independent login request
• On-demand
• Tightly scoped
• Expires in minutes
• Self revoke after single use

While other products and practices focus so much of their effort on “protecting the keys,” this is the best way to mitigate the risk of credential theft is to render them useless.

With a solid identity foundation in Okta, you can support a wide range of access management use cases. Advanced Server Access brings seamless controls to the infrastructure layer in an elegant manner.

• Team-level, project-level, and realized attributes
• Concepts
• SSH Architecture

WAM

There are three main ways to secure enterprise web apps:

1. Standalone security
2. Kerberos
3. WAM
   • In WAM, it was determined that most application requests passed through routing and balancing in the multi-tier architecture.
   • So, a decision was made to take advantage of that fact and enforce authentication and authorization at this level to validate access.

WAM Responsibilities

1. Authentication
2. Authorization
3. Session Management

WAM Integration Patterns

In order to authenticate and authorize an app, WAM solutions must be integrated with the app they secure:

1. Header-Based Authentication
   • Applications are protected by an HTTP server with a WAM Policy Enforcement Point agent, or PEP agent that sits in between the user and the app.
   • After the user is authenticated, the WAM agent injects information about the user on the request (HTTP Header Variable).
     • This is the most common standard used in WAM.
     • For example, 95% of Oracle Access Manager apps are protected using this standard by Oracle WebGate.
   • Header-based auth typically utilizes an enforcement point to examine all the traffic coming to the HTTP server either by utilizing.
     • App server plugin (Agent)
       • Users access the application directly. The server that hosts the application will talk directly to the WAM server to validate the user access before granting access to the application.
       • This model is usually available on Java application servers such as WebLogic and WebSphere.
     • HTTP Server or (Agent)
       • The HTTP Plugin sits on the Routing and Balancing layer in the DMZ on the web server itself.
       • Examples of some web servers are OHS, Apache, IIS, and NGINX.
     • Parallel gateway or Reverse proxy engine 
       • Instead of using an agent plugin on each web application, many WAM solutions deploy gateway servers to intercept and inspect requests to the web application.
       • The gateway can then insert identity headers into the request for the application to read. This is the architecture of the Okta Access Gateway. This is similar to Oracle Webgates.
   • 
2. Kerberos
   • This type of integration relies on tickets granted by a Kerberos Ticket Granting Service in order to allow traffic.
   • This pattern is typically used in Windows environments, apps hosted on IIS, and on-prem SharePoint.
3. Secure Form Fill
   • Applications are protected by an HTTP server that sits in between the user and the app (similar to header-based authentication).
   • However, after the user is authenticated, the WAM solution will automatically sign into the enterprise application using a login and password.
   • This is similar to what we have with Okta’s Secure Web Authentication  (SWA).
   • However, the password manipulation happens on the server side.
   • Okta supports both client and server sides.
4. SAML / WS-Fed / OIDC
   • This is the same model used in Okta for authentication into cloud apps.
   • The major difference between Okta and WAM, is that configuring federation in WAM can be super complex.
5. SDK
   • Proprietary vendor toolkit that enables ISVs to build their own integrations.
     

Flow:

1. User accesses a web application. A Load Balancer routes the request to the proper server.
2. A plugin or agent integrated to the app or HTTP server (also known as Policy Enforcement Point – PEP) intercepts the request and validates the access with the SSO Server (also known as Policy Decision Point, or PDP) using a proprietary protocol (dotted green lines).
3. The SSO Server validates the user session and the resource (URL) requested. During authentication, it also validates the user credentials against an LDAP server.
4. Upon the SSO Server approval, the Agent complements the request context with information about the logged user – i.e., the user login – for the enterprise application. Agents embedded within the application pass the user information in session while agents used with HTTP servers send this information through HTTP Headers.
5. The enterprise application extracts the user information from the HTTP headers or the session, process the request, and returns a response to the end user.

Components:

• Load Balancer: Balances traffic between Applications and HTTP Servers.
  • Examples: Big-IP F5, Apache with mod_proxy and mod_proxy_balancer, and Cisco ACE.
• Policy Enforcement Point (PEP): Agent or plugin that implements authentication on enterprise applications. Includes:
  • Application/ERP/Custom Agents: These PEPs are installed directly in Application Servers, ERPs/CRMs, and as proprietary SDKs for direct use in applications.
    • Examples: Oracle OAM Access SDK, Oracle AccessGate for eBusiness Suite, Oracle OSSO Plugin, OAM Authenticator Provider for WebLogic, CA Application Server Agent for Tomcat, WebSphere, JBoss, and WebLogic, SiteMinder Agent SDK, SiteMinder ERP Agents for SAP, PeopleSoft, Siebel, and Tivoli Manager for WebSphere.
  • Web Agents or Web Gateways: These PEPs are provided as software appliances or as plugins for HTTP Servers such as Apache and IIS.
    • Examples: Oracle WebGate, IBM WebSeal, Tivoli Apache Plugin, CA SSO Apache Plugin, CA SiteMinder Gateway, Novell Access Gateway
• HTTP Server(s): Serves HTTP requests.
  • Examples: OHS, Apache, IIS, and NGINX.
• SSO Server or Policy Decision Point (PDP): The SSO Server validates users, URLs, and URIs to authenticate and authorize access.
  • Examples: CA SiteMinder, Oracle Access Manager (OAM), Tivoli Access Manager (TAM), and Novell Access Manager (NAM).
• User Directory Store (LDAP): A directory containing user credentials for authentication.
  • Examples: Oracle Directories (OID, OUD, and OVD), Sun Directory Server (Sun DS or ODSEE), Tivoli Directory Manager, OpenLDAP, and Novell eDirectory
• Firewalls: Network solutions used for segmenting traffic between WAM components. The network segmentation is required to avoid unauthorized access to enterprise apps and to avoid traffic sniffing or spoofing.
• Enterprise Applications: Applications protected by the IdM solution. Enterprise apps receive requests with the user information as session arguments or via HTTP headers.

Okta Access Gateway

• Okta Access Gateway is a reverse proxy solution that is designed to secure web applications that do not natively support SAML or OIDC. 
• Access Gateway integrates with legacy applications through the use of:
  • HTTP Headers
  • URL-based authorization
  • Kerberos Tokens
• Access Gateway allows you to seamlessy integrate your legacy web based applications with Okta’s Cloud SSO Capabilities.
• Access Gateway is an ideal solution for any Okta customer where:
  • Enterprise wants to unify all IAM under an Okta platform, but requires integration with web applications that do not support federation (SAML, WS-Fed).
  • Vendors, customers, or partners must access your internal business web applications (such as SharePoint, Oracle E-Business Suite, and others) from the internet.
  • Must restrict unauthorized network access to your web applications.
  • Enterprise has web applications that lack a native authentication mechanism.
  • Company is looking for a cost-effective replacement for your on-premise WAM solution.
• Supports Web (HTTP/HTTPS) based applications ONLY.
• Supports both SP and IdP-init SSO (from Okta dashboard). No IdP-init SSO in WAM.

Modern (Cloud and Mobile) applications flow

• A. User accesses a cloud or mobile application.
• B. The app validates the session. If there’s no session, it redirects the user for a federated authentication in Okta.
• C. Okta authenticates the user using the native identity functions: Single Sign-On, User Directory Store, Adaptive MFA, and Federation.
• D. Upon access approval, the user is redirected back to the Cloud of Mobile App. The app completes the federation process, establishes the user session, and responds to the user request.

Enterprise Applications flow

1. User accesses web application via HTTPS.
2. The Access Gateway intercepts the user request. If the session is invalid, it redirects the user for a federated authentication on Okta.
3. Okta authenticates the user. All the identity functions (Single Sign-On, User Directory Store, Adaptive MFA, and Federation) are built natively into the Identity Platform.
4. Upon access approval, the user is redirected back to the Access Gateway that completes the federation. Because the gateway is capable of working with different kinds of applications, it doesn’t require native integration.
5. The enterprise app captures the user information, process, and responds to the request.

Components

• Okta: Okta provides Single Sign-On, Adaptive Multi-Factor Authentication, API Authorization, User Directory, Account Provisioning, and Federation in the cloud for modern apps (via native standards-based integrations) and enterprise apps (via Access Gateway).
• Cloud and Mobile Applications: Modern applications with direct access to the internet.
• Access Gateway: The Okta Access Gateway bridges the gap between the Identity Platform and your enterprise applications. It leverages federated authentication for Single Sign-On and Adaptive MFA and connects to your enterprise application using WAM standards (such as security headers). Because the gateway supports different types of applications, it doesn’t require native integration.
• Firewalls: Network solutions used for segmenting traffic between components. The network segmentation is still required to avoid unauthorized access to enterprise apps and to avoid traffic sniffing or spoofing.
• Enterprise applications: Applications protected by the gateway. Enterprise applications receive traffic via HTTP Server with the user information on the HTTP headers.

1. Okta Tenant
2. Virtualization Environment
3. Virtual Appliance (OAG)
4. Protected Applications

Using a reverse-proxy architecture, Okta’s Access Gateway delivers: SSO and Adaptive-MFA from the cloud to on-prem apps without changing how those apps work.

Access Gateway uses a VM deployment model, you can run either on-prem using solutions like VMWare Hypervisor or Virtual Box or even deploy on your IaaS provider of choice from RackSpace to Amazon AWS.

 

Example Architecture

Access Gateway Supported Applications

• Sample Cookie -> pass data via HTTP cookies
• Sample Header -> pass data via HTTP headers
• Sample Policy -> uses URL-based policy to restrict access to apps
• Sample Proxy -> OAG act as proxy for apps
• Header Based -> provide SSO via HTTP headers to apps
• No-auth -> reverse-proxied by OAG without any authentication
• OAM/ Orcl apps -> provide SSO via HTTP headers to Orcl apps
• Microsoft-IWA -> for MSFT Kerberos based back end applications
• SFDC -> SSO for SFDC apps

Steps:

1. Deploy Okta
2. Integrate Okta to LDAP/ AD using Agent
3. Deploy Okta login page
4. Configure SAML from Okta to WAM (OAM) for SSO
5. Move SAML Apps to Okta
6. Deploy OAG
7. Enable OAG to secure App (which uses agents directly not reverse-proxy, OHS) and remove agents
8. Repeat until all Apps are migrated
9. Remove WAM’s HTTP Server (OHS)
10. Remove Okta to WAM SAML (OAM)
11. Remove WAM (OAM)
12. Optional: Migrate users to UD and remove LDAP
13. Optional: Migrate Apps to use Okta natively