Prerequisites for Deploying Access Gateway

This section outlines the required information that must be completed prior to installation of Okta Access Gateway in a customer environment.

Underlying Hardware

Okta Access Gateway was built to use the SSE4.2 extensions to the x64 instruction set, which were made available with the Intel® Nehalem and AMD Bulldozer microarchitectures. The server that runs Access Gateway must, at a minimum, support that instruction set.

Okta org

The Access Gateway configuration process requires a super adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. account to configure your tenant as the identity provider. See Configure your Okta tenant as an Identity Provider for details of configuring your Okta tenant as the idPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta. for Access Gateway.

Firewall Rules

Access Gateway requires various ports and protocols be open for use.
The following table describes all required access.

Description Inbound/
Protocol Port


Okta Tenant API access Outbound TCP/HTTPS 443


Access Gateway Updates Outbound TCP/HTTPS 443


Integrated applications Outbound TCP/HTTPS 443


Access Gateway Admin UI and Apps.




All end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. must to be able to access Access Gateway directly using port 443 if it's acting as an internet-facing reverse proxy or deployed in the DMZ.

SSH Management, Configuration Replication




SSH is only used between instances of Access Gateway and to access the Access Gateway command line. It is highly discouraged to open port 22 to general internet traffic.

Support connection







Syslog TCP

Customer supplied


Depending on applications Access Gateway may require the following access:

Description Inbound/
Protocol Port
Access Gateway to the Key Distribution Center (KDC) Outbound TCP/UDP 88
Access Gateway to DNS Outbound TCP/UDP 53

Access Gateway to Data store


LDAPLightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directory services, specifically X.500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services./ODBC

Customer supplied (For example:. 389/636)

Oracle E-Business Rapid SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones.



Customer supplied (For example:. 1521)

Appliance Virtual Hardware Specifications

This section outlines the suggested virtual hardware specifications allocated for the Access Gateway. Each sub-section details different specifications depending on the use case and requirements for the Access Gateway.

To help with sizing, the following details should be gathered for each protected application and discussed with your deployment partner to help determine the proper appliance size.

  • Estimated number of users per day
  • Estimated total number of users
  • Estimated average authentication requests per day
  • Estimated peak authentication requests per day
  • Estimated average session duration
  • Is there a time of year when usage peaks?
    If yes, when and approximately how many authentications per hour?

Capacity Planning and Sizing

When calculating sizing we consider the following areas:

  • Cores - Total number of cpus/cores.
  • RAM - Typical memory requirements.
  • Storage - How much disk space is required? Primarily for logging purposes.
  • NIC - What are throughput requirements?


Terms and definitions:




A reference to an application as defined by the Access Gateway UI and listed on the Applications page.


Authentication, or AuthN, is the process of establishing identity. Authentication occurs the first time a user accessing a given application within Access Gateway. Authentication may also occur at other times when accessing application resources.


Authorization, of AuthZ, is the process of determining access rights to a given page or resource. Authorization occurs every time a user attempts to access an application resource such as a page


Access Gateway Session, or simple Session, refers to the information maintained and used by Access Gateway. Typically this includes all the information in a traditional HTTP(s) session as well as Access Gateway specific session data such as attributes and possibly KerberosKerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. tickets(when in use).



Memory Sizing

Access Gateway appliance memory use is divided into:

  • OS, Access Gateway engine, and micro-services, with 1.5GB considered the minimum for production environments.
  • Cached Sessions: 128MB minimum.

Since OS, core Access Gateway and micro-services memory is fixed, determining memory requirements is primarily focused on cache session sizing.

To determine memory size examine:

  • Total sessions - the maximum number of in memory sessions at any given time.
  • Average session size - the average expected size of any given session.

Total sessions can are calculated using:

  • Number of users
  • Percentage of user logins per day
  • Applications accessed
  • or

  • Total sessions = #users x % login per day x application accessed

Session size is a function of:

  • Application session and application attributes, with default size of ~1024b
  • and

  • Kerberos tickets (where applicable), ~1024b, but are often larger based on number of IIS applications accessed

Session cache then becomes

  • Session cache = Total sessions * (average session size * 2)

For example:

Web Application - Session Cache
Users Percentage Login/Day

Applications Accessed

Total Sessions(Users % logins/day * applications accessed)

Session Size

Session Cache

5,000 50%

















Kerberos, when used, adds additional caching requirements:

Kerberos Apps - Reserved
Users Percentage Login/Day

IIS Applications accessed

Total Sessions(Users * logins/day * applications accessed)

Session Size

Session Cache







Total application memory should then include, at a minimum, 1.5GB for fixed requirements and session cache plus Kerberos requirements.




Session considerations:

  • Sessions are cleared using a Least Recently Used, or LRU, algorithm .
    When cache is full and new sessions are created, the oldest idle session is removed.
  • Session Monitoring logger will raise alerts for cache near full and full conditions.
    Statistics can be found in the management console.
    Consider increasing appliance memory to reduce cache full situations.
  • Always consider peak session usage situations and plan accordingly.
    Consider peak conditions and size for those conditions. For example consider load such as the time of year when employees are enrolled, or mornings &after lunch logins and similar situations.

Hard Disk Sizing


Access Gateway requires hard disk for software, system logs/log archives, and backups.
Disk use is comprised of:

  • Software, including operating system, and Access Gateway.
  • Backups, performed nightly, and retained for 30 days.
  • System log output, spooled to local disk, and including Audit, Access and All Log files.
  • Log archives, maintained for 30 days, rolled and compressed.

Software and backup size requirements are typically small making the primary consideration log sizes.

Log Entries

Log entries primarily contain session information, AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect. (AuthN) and Authorization (AuthZ) content. Typically one entry per HTTP(s) request.
In order to correctly size disk the number and size of these entries over a given time period must determined.
To determine the size of log entries we must consider the number of system users, and the count of time users access applications (AuthN entries) and the number of subsequent page views for that application (AuthZ events).

Overall the composition of a log entries are based on:

  • Session - Each log entry includes Access Gateway session information.
  • AuthN - Authentication audit and logging information.
  • AuthZ - Authorization log information, including resource accessed and policy rules.

From a disk use perspective the size of each of these is the other important question.


Let's look at an example.
If a given user base is 10,000 users, of which 75% access the system per day, and each user accesses, on average, 10 applications. then we can determine average daily accesses as:

  • Active Users = total users * access percentage, or 10,000 * 75% or 7500 active users.

Each user accessing 10 applications:

  • Accesses Per Day = Actice Users * applications accessed, or 7500 * 10 = 75,000 accesses per day.

If we assume that each access requires a session + authentication and authorization we can then determine an estimate of the size of each log entry as:

  • Log entry size = Access Gateway Session size + AuthN size + AuthZ size + plus some small formatting overhead.

For more realistic example, let's assume Access Gateway Sessions, AuthZ and AuthN sizes are roughly the same and ~1024B each. Then each access would require approximately 3K bytes.

Assuming access is roughly evenly distributed over the course of 24 hours, we see approximately 75,000/24 or 3125 accesses per hour.

If each access was 3K bytes then the hourly growth of a log becomes 3k*3125 or or 9.6MB/hour or approximately 230mb a day. Assuming a consistent access pattern we would expect to need ~7,000MB of disk/month for log and log related content..

A reasonable rule is to allocate twice expected consumption plus additional overhead space for software updates, configuration and backups. In the example given we would then consider as a disk requirement of approximately 14GB plus 10-20% or roughly 17-20GB/month.



Hard Disk considerations:

  • Monitor logger alerts on low disk - runs hourly. 70% warning, 90% alerts.
    To avoid low disk warning size for maximum or peak requests.
  • Every HTTP request results in audit and access logs.
  • Faster disk IO will improve throughput.
  • Session size will affect audit logging with authorization and audit logs contain session contents.
  • Don’t be conservative in Hard Disk sizing, allocate 2x estimated disk requirements to avoid burst and large page requests resulting in low disk warnings.

CPU Sizing

The Access Gateway engine autoscales across CPUs, which results in an worker per CPU. Each additional core results in an additional thread allowing for additional processing.



CPU considerations

  • More CPU/Cores will improve capacity.

  • Network throughput is typically the bottleneck.

Throughput Sizing

Throughput is a direct function of AuthN, AuthZ and return content.

Assuming (see logs for actual values):

AuthN Bytes AuthZ Bytes Returned Data
1024B 1024B 2048B

Network throughput becomes a function of:

  • Login/second * AuthN size
  • AuthZ requests/second
  • Average returned data size.

Total network throughput then becomes a function of:

  • Login/sec * (AuthN + AuthZ/sec + returned data size).

Assuming that the dominant factor in network access is the amount of data returned per request, and an average response is~20KB. For 500 requests the result becomes 20KB * 500 or 10 MB/s.


  • Average network bandwidth = Average response size * Average request arrival rate.


Network Requirements
Requests/ second AuthN Size

AuthZ Size

Returned Data









Exact timing information can be found in the AuthN and All logs. Total time to perform a request and return data is also tracked.

Instance Sizing

Consider the following table when sizing instances.

Use Physical/virtual hardware AWS Equivalent

Proof Of Concept

1 instance of
2 cores at
2G memory, 220G(default) HD, each with single 1 Gbps NIC each


Small 2 instances of
2 cores at
4G memory, 220G HD, each with single 1 Gbps NIC each
Medium 3 instances of
2 cores, at
8G memory, 500G HD, each with single 1 Gbps NIC
Large 3 instances of
4 cores, 16G memory, 500G HD each with single 1 Gbps NIC

See AWS Instance Types for more information.

Load Balancer

If the Access Gateway is being installed in a high availability configuration, your organization must provide a load balancer. The load balancer can balance traffic via Source Network Address Translation (SNAT) or Dynamic Network Address Transation (DNAT) and should be configured to balance through a hash of the source port and IP address. Also see Example Architecture.