Introduction

Okta Access Gateway (Access Gateway) applications represent the protected customer web application assets. When defined within Access Gateway, these assets are referred to as Access Gateway applications, or simply applications.

The purpose of this guide is to:

  • Detail the underlying technology and organizational concepts involved with integrating Access Gateway and a Set 3rd party app long name application.

  • Detail the underlying technology and organizational concepts involved with integrating Access Gateway and a Set application type application

  • Provide a step-by-step integration plan.

The integration plan is comprised of a phased approach that details recommended tasks and decisions that must be made in order to architect the proper solution.

Target audience

This guide is intended for technical architects, consultants, and project managers who are tasked with designing, testing, and deploying an Access Gateway integration with a Set 3rd party app short name application.

The guide is intended for technical architects, consultants, and project managers who are tasked with designing, testing, and deploying an Access Gateway integration with a Set application type application.

Date of publication and change log

Date Change description

Set oringal publication date

Initial release.

 

 

Submit feedback

To comment on this document, visit our feedback form.

Learn about components and concepts

There are several core components and concepts that are relevant to the integration.

Okta Access Gateway

Okta Access Gateway (Access Gateway) enables on-prem web applications that do not support federated identity standards such as SAML, OIDC, or WS-Federation, to connect to Okta’s Single Sign-On (SSO) and Adaptive Multi-Factor Authentication (MFA) services in the cloud.

  • Access Gateway is a Linux-based virtual appliance that runs as a reverse proxy.

  • You can deploy Access Gateway on-prem, as well as to Infrastructure-as-a-Service (IaaS) provider, such as Amazon AWS, Azure, and Oracle Cloud.

  • Access Gateway integrates with an Okta tenant using SAML and REST APIs. OAG then integrates with the on-prem applications using their legacy authentication methods (header-based and Kerberos).

And because OAG is deployed behind the firewall, Access Gateway lets external users access on-premises web-based applications without the need for traditional VPNs.

Reverse proxies

Access Gateway operates as a reverse proxy server.

The following briefly describes the differences between a forward and reverse proxy server:

  • A forward proxy relays traffic from inside an organization to an external destination by applying predefined rules.

  • A reverse proxy does the opposite of a forward proxy.

    A reverse proxy intercepts user attempts to access resources behind the firewall of an organization. It acts like a gatekeeper by examining the source and destination of network traffic to determine whether to let it through and where to direct it.

The latter stops unauthorized traffic from reaching protected or internal resources inside the organization. A reverse proxy can also help to balance the computing load in a network by distributing incoming sessions between several instances of an application.

The following is a simple architectural diagram that shows Access Gateway intercepting user requests for protected applications:

DNS and Access Gateway

Access Gateway is a reverse proxy that forwards external queries to an internal server, protecting internal resources from unauthorized traffic. Access Gateway:

  • Translates public DNS requests into private DNS addresses accessible only on the company network.
  • Uses a set of reserved DNS entries to represent the name of the Access Gateway administration instance, pointing to the IP address of the Access Gateway itself.

See About Access Gateway DNS for more information.

Concept

Optional Concept A

Optional Concept B

Optional Concept N

Use Cases Covered in this Guide

Access Gateway enables on-prem web applications to connect to Okta’s Single Sign-On (SSO) and Adaptive Multi-Factor Authentication (MFA) services in the cloud.

This is different than lifecycle management, which involves onboarding and managing user identities for use in access management, which is managed the Okta On-Premises Provisioning (OPP) feature.

This guide focuses on access management and how it works with an Access Gateway and Set 3rd party app short name application integration.

This guide focuses on access management and how it works with an Access Gateway and Set application type application integration.

Access management

Users can access the Set 3rd party app short name Set application type application either by accessing Access Gateway directly or by accessing it via an Okta cloud tenant.

Either way, Access Gateway uses SAML 2.0 to authenticate the user via the Okta tenant, and then uses an HTTP header to authenticate the user with the on-premise user store of the Set 3rd party app short nameSet application type.

Lifecycle management

Lifecycle management, as described in this document, automates all aspects of the identity lifecycle. This includes the integration of applications with directories containing user information and the implementation of policies for controlling identities. It also includes reporting on user identities.

There is no dedicated lifecycle management function in OAG but integrators use a third-party connector from Okta Professional Services or Okta partners, like Aquera.

Per the Kerberos outline, this is a completely seperate discussion from the latter guides.

Integration Phases

An Access Gateway integration with a Set 3rd party app short nameSet application typeapplication is divided into distinct phases. Each phase includes:

  • Recommend tasks.

  • Decisions that must be made in order to architect the proper solution.

Phase 1: Get Ready

In this phase, you:

  • Create a project plan.
  • Identify stakeholders.
  • Verify the environment is operational.
  • Establish a customer readiness review.

Create a project plan

Create a project plan that covers the next phases (Plan through Go-live). You should include the following items in the project plan:

Project plan items
  • Completed readiness review.
  • Proposed schedule for discovery and design workshops.
  • High-level timeline for the project.
  • Cadence for post-kickoff project meetings.
  • Proposed schedule and structure for kickoff event.
  • Project objectives.

Identify stakeholders

Organize a steering committee and ensure that everyone understands the project objective and success criteria, including ROI metrics.

Internal team project stakeholders should include the following roles:

Stakeholders roles
  • Executive sponsor
  • Operations and infrastructure representatives
  • Project manager
  • Functional lead
  • Product decision maker
  • Security lead
  • Architect
  • Technical lead
  • System administrator
  • Kerberos application administrator
  • Application owners.

    For example - someone who can guide the team through the environment.

  • Active Directory administrator

Verify the environment is operational

Before you begin the integration, verify that the environment is operational.

Set application type

Do the following:

  • Confirm that the environment for the Set 3rd party app short nameSet application type application is up and running normally, independent of Access Gateway.

  • Verify that a testing and a production environment are available for the Set 3rd party app short nameSet application type application.

  • Determine if custom work is required to integrate Access Gateway with the app.

    For example, a non-Microsoft app that uses the Windows Authentication plugin.

    For example, users that have multiple identities and roles.

Access Gateway

Verify the following:

  • Access Gateway is up and running normally, independent of the Set 3rd party app short nameSet application type application.

    Access Gateway requires a separate license and must be enabled by Okta on your org.

  • The Okta tenant is configured as the identity provider (IdP).
  • You have administrative rights on the Okta tenant to assign applications to users and to create groups.

See Access Gateway deploy and configure workflow for more information.

Establish a Customer Readiness Review

This should include the following:

  • Go-live plan.
  • List of internal and executive team members.
  • Training plan for help desk, system administration, and software development employees.
  • List of the statuses of technical tasks that includes directory information, as well as application, network, and Okta org details.

Phase 2: Plan

The planning phase begins with the project kickoff event and includes a workshop to address the following:

  • Discovery questions.
  • Application inventory.

Discovery Questions

Guide the workshop with the discovery questions for the Set 3rd party app short nameSet application type application:

Discovery questions
  • What is the app used for?
  • How many full-time users will use the app?
  • What are the business use cases that will be solved by the integration?
  • How many part-time users will use the app?
  • Are there any service accounts set up for the app?
  • How many contractor users will use the app?
  • What existing authorization group(s) are used to specify access to the app?
  • How many internal (on-network) users will use the app?
  • What existing Okta security group(s) are used to specify access to the app?
  • How many external (off-network) users will use the app?
  • What internal DNS entries must be updated for the app to function properly?
  • How many users in total will use the app?
  • What is the typical file upload size.

    Default = 1 MB

  • Is there a meeting required with another partner or company that is managing or hosting the app?
  • What type of SSO integration does the app currently use? For example - SAML.

    • Is there any vendor documentation, example configurations, or assertions?
    • Is there any backdoor/sidedoor access required?
  • What is the projected/expected target date for go-live?
  • If applicable, What is current user provisioning workflow for the app?
  • Will there be end-user communication required for managing change internally?
  • Are there any special workflows?

    For example - login, logout, internal, external, or external workflows.

  • Will this solution live in a single data center? Or multiple data centers?
  • What are all the test cases we need to account for when validating the solution?
  • Will this solution require high availability?
  • What is current authentication workflow of the app?
  • Will this solution require disaster recovery?
  • Is there a separate dev/staging and production application environment?
  • What are the performance expectations/metrics to consider, if any?
  • Does the app currently have any custom processes deployed?

 

  • What are the current application server session values?

    • Idle session (default = 1 hour)
    • Mas session (default = 8 hours)

 

Application Inventory

Create an application inventory documenting the following items the Set 3rd party app short nameSet application type application:

Items for application inventory
  • Which version of the app is in use and is it supported? OAG supports version 9.2.00 or later.

  • Any calls that app makes to other applications.

  • Are there specific application headers that you must accommodate?
  • Any complex policies that the app uses to evaluate user access.

  • Is any personally identifiable information (PII) stored?
  • Any complex policies that the app uses to evaluate user access.

  • Supported authentication types?

    For example - SAML, OIDC, headers, cookies, kerberos certificates, and basic authentication.

  • App resources or locations using web sockets.

  • Is there a standard format for application username attributes?

    For example - samAccountName, email, or userPrincipalName.

    If they do not have a standard format, look into leveraging the Okta scripting language to generate the format needed or the OAG data stores for mapping.

  • App resources or locations requiring different upstream application servers.

  • Dependencies on external repositories or directories for user authentication/ authorization or profile information.

  • App resources or locations that do not require authentication or a session for access.

  • General lifecycle management.

    User onboarding and offboarding.

  • Load balancer configurations.

  • Number of authentications per day.

  • Required network access control lists and DNS records.

  • Thick clients supported by the app.

  • Which app modules are in use and which work with SSO.

  • Web services, APIs, or other applications that connect to the Set 3rd party app short nameSet application type application.

  • The number of users per Set 3rd party app short name module.

  • A matrix of supported browsers and OS platforms

 

Phase 3: Design

Application review

Determine how the application is constituted. The following table details the areas to review:

Areas to review
  • Header review.

    Review all of the attributes that should be in the header

  • Session behavior.
  • Policy review.
  • Okta rate limiting.
  • Application behavior.
  • Capacity planning.

See the following for more information:

Environment configuration

Review the configuration of the environment. The following table details the areas to review:

Area Considerations

Locations

  • High-availability
  • Disaster recovery
  • Sizing

Infrastructure

 

  • Virtualization
  • Networking
  • Firewalls
  • Load balancers
  • Data stores
  • Logging
  • Monitoring
  • DNS

Scalability planning

Create a scalability plan. The following table details the tasks associated with creating the plan.

Tasks for scalability planning
  • Investigate user authentication and session time details for each application.
  • Include rate limit planning in data migration and integration design.
  • Plan to validate rate limits.

    Identify the APIs that are used throughout a successful login sequence.

    For example - /authn, /app/{app}/{key}/sso/saml

  • If any projected surges in user and group imports and API requests are temporary then plan a temporary rate limit increase with Okta:
    • Consider the existing rate limits and plan to mitigate these in advance.
    • Review designs in detail for rate limit impacts.
    • Assess rate limits as shared across the organization, not just via the Set 3rd party app short nameSet application type application.
  • Analyze the required rate limits for key data/usage surge events such as load testing, go-live, and business-related events.
  • If projected surges are seasonal or sustained, contact your Okta Sales Representative to purchase DynamicScale add-on or other options.

    Plan for Okta's concurrent rate limit covering these types of traffic: Agent, Microsoft 365, and all others including API requests.

  • Plan separate rate limit tests for migration activity.
  • Determine how other API calls such as scripts and custom form calls affect concurrent API rate limit usage.
  • Ensure that the data and API development teams are familiar with Okta's rate limit policy.
  • Additional scalability planning considerations include:
    • Physical hardware.
    • Physical network performance.
    • Apprpriate tools for proactive monitoring.

Future-state design document

Create and share a customer-facing document that explains the future-state design of the integration.

The following table details the areas the document should cover:

Area Considerations

Current state

  • Access assignments, application configurations and integrations

  • Required changes

Future state

 

  • System components and related functionality

  • Integration requirements:

    • Efficiency

    • Expected user experience

    • Ease of maintenance

    • Security

  • Reporting and security governance requirements

  • How the latest Okta functionality maps to future state requirements

Feasibility analysis of Okta's integration with the Set 3rd party app short nameSet application type application.

 

Architecture design and development planning

  • Integration diagrams

  • How the solution design matches productivity and workflow needs.

  • Data connectivity between all of the components

  • Future scalability

  • High availability performance

System integration design

  • Physical systems design and how it maps to logical design

  • Preliminary designs, detailed designs, and system tests

  • Data flow efficiency between components

  • How the intended system integration supports business process automation

Implementation planning

  • An implementation and deployment roadmap based on integration priority, risk profile, budget, and resource availability

  • A plan to hit user experience improvement targets

Integration test and maintenance planning

  • Physical systems design and how it maps to logical design

  • Preliminary designs, detailed designs, and system tests

  • Data flow efficiency between components

  • How the intended system integration supports business process automation

Additional documentation

Accompany the future-state design document with the following:

  • Sequence diagrams showing the change from the current to future state
  • A reference architecture
  • A provisioning plan
  • An application matrix

Phase 4: Build

It is recommended that you first configure the integration using a non-production environment

Configuration steps

<Author configuration steps specific to the application.>

Additional configuration

Additional configuration steps include:

  • Configuring internal and external DNS records.
  • Setting up SSL certificate management, documenting where SSL certificates live now and where they should be located in the future.
  • Deciding on and setting application timeouts
  • Customizing Okta login pages to create a consistent OAG experience.

    This includes setting consistent URLs for logout, error, and access denial pages.

See the following for more information:

Phase 5: Test

Test the solution in your customer’s testing environment, which should include an Okta preview tenant, Access Gateway appliances, and a load balancer.

When conducting these tests, consider Access Gateway usage scenarios including:

  • SSO sessions initiated by both the IDP and the service provider (SP).
  • The use of deep-linked resources.
  • Redirection to post-login URLs.
  • The execution of custom policies.

Be sure that:

  • Access Gateway works on all nodes in a high-availability cluster.
  • Load balancer health checks are working.
  • Users work through all the modules in your EBS environment to cover all eventualities.

The following table details the areas that a test plan should cover:

Area Tasks

General

  • Confirm a test period based on master project plan.

  • Confirm test methods and tools.

  • Define the expected experience for JD Edwards users and specify acceptable issue levels by severity for the go-live process.

  • Define test issue severity and priority levels along with a triage approach.

  • Confirm test track owners and resources

  • Train testers before testing begins

Infrastructure

 

  • Configure SSL certificates.

  • Test that the Set 3rd party app short nameSet application type application is presenting the SSL certificate that you are expecting.

  • Test that the required firewall ports are open.

  • Test firewall ACLs.

  • Test Access Gateway HA node communication.

  • Test individual Access Gateway node SSO for applications and security information, and event management (SIEM) log forwarding.

  • Test that simple network management protocol (SNMP) monitoring works well for all nodes.

Unit testing

  • Confirm all uses per the configuration scope.

  • Create a unit test plan and script based on simulated user experiences for each use case.

  • Automate the testing cycle where possible.

  • Have the customer security team review unit test scripts.

  • Complete unit tests on all Set 3rd party app short name application modules.

  • Complete unit tests on all end user browsers and devices.

  • Allocate time for issue resolution and retesting.

  • Confirm each configuration unit performs its assigned function independently of the other units.

End-to-end testing

  • Have the security team review end-to-end testing scripts and outcomes.

  • Test with all Set 3rd party app short name application modules, across all supported browsers and versions; and devices; and across all geographies.

  • Conduct regression tests for any changes made after the initial tests.

User acceptance testing

  • Prepare application, use case, adn role-specific test scripts with expected test results and issue owners and procedures.

  • Include business application owners or delegate to IT, security, and functional representatives

  • Test with all Set 3rd party app short name applicaton modules, across all supported browsers and versions; and devices.

  • Include testers from different regions to ensure a consistent user experience.

Performance testing.

Conduct this testing with the Okta test tenant only.

 

  • Assess if performance testing would required higher API endpoint rate limits Okta. See Rate limiting and Rate limits overview.

  • Give Okta customer support no less than 10 business days when raising a rate limiting ticket.

  • Report significant customer activity no less than 48 hours prior to load testing when you will:

    • Exceed 10,000 users for a user import, API testing, load testing, a batch API event.
    • Enable teh SEARCH_INDEXER_FRAMEWORK feature flag for over 100K users.
  • Log a ticket with Okta customer support to address isues found during performance testing.
  • Confirm acceptance of performance testing.

Data migration testing

Conduct each round of data migration testing in your detailed data migration plan, logging a ticket with Okta customer support where necessary to address issues.

Phase 6: Go-live

Launching the integration after testing involves a go-live plan. A go-live plan includes the following stages:

Stage Tasks

Pre-go-live communication

  • Offer communication and training to end users including employees, partners, suppliers, contractors, and customer portal users.

    • Refer to Okta’s End User Adoption Toolkit for further instructions. This should include an explanation of the impacts on users and any changes they might be prepared to make.

    • Create and communicate plans for a launch-related outage as part of this process.

  • Offer relevant communication and training to:

    • Help desk operatives.

    • The customer’s Okta system administrator.

    • Any IT outsourcers or MSPs.

    • The project sponsor.

Operational readiness

 

  • Confirm Okta system administrators and put them through Okta training.

  • Activate access to the Okta Customer Support Portal.

  • Connect with an Okta Customer Success Manager for post go-live success planning and follow up.

  • Plan regular reviews of Okta’s release summary and follow-ups on project enhancement requests.

Final project scope review

  • Review your product functionality and user rollout plans and document any variances from the original plans.

  • Monitor end user adoption and review/mitigate potential hurdles.

  • Assess and report business value realization (ROI) to the steering committee.

Value realization review

  • Review your product functionality and user rollout plans and document any variances from the original plans.

  • Monitor end user adoption and review/mitigate potential hurdles.

  • Assess and report business value realization (ROI) to the steering committee.

Go-live approval and scheduleschedule

 

  • Secure final go-live approval from the steering committee.

  • Schedule the cutover window.

Data migration

  • Confirm any rate limit increase requests with Okta customer support no less than 10 days prior to import.

  • Warn Okta customer support of imports or other batch API events involving over 10,000 users at least 48 hours prior to the activity.

  • Execute detailed data migration steps (file creation, account creation, loader script, activation, and authentication validation).

Security policy, configuration, and code migration

  • Establish roll-back criteria and steps.

  • Activate the war room.

  • Execute a detailed security policy and configuration cutover plan.

  • Execute a detailed development code deployment plan.

  • Execute end-to-end testing (including global locations).

  • Switch user login from legacy to Okta.

Go-live communication

  • Communicate go-live system downtime to employees, contractors, administrators, project team, the help desk, and all external users

  • Communicate go-live completion status to affected users

  • Execute the go-live monitoring plan