Enterprise Application Access (EAA) allows you to configure advanced settings that apply to your applications. These configurations are generally optional. In EAA Management Portal select your application and go to the Advanced tab. The advanced settings available for an application vary based on application type (Web, SSH, RDP, VNC, client-access application) and other configured services. After you enable any of these settings, you should deploy the application.

Related Applications

Rewrite group (optional). Select this to assign rewrite groups for groups of applications. To get more information see URL rewrite services and create application groups for rewrite rules.

Authentication

Authentication token login URL (optional). If your application needs authentication tokens, enter the login URL. Enterprise Application Access generates tokens for the URL.
SSO logout URL (optional). Enter the single-sign out URL that is triggered when a user logs out of an SSO application.
User-facing Authentication Mechanism (mandatory). Select the option to use when authenticating users on the front end. This option only applies when the directories configured for this application are AD/LDAP or the Cloud Directory.
Application-facing authentication mechanism (optional). Select the authentication mechanism in use by the application servers. If the application expects custom headers with HTTP requests for SSO, you can use the Custom Headers feature. For more information, see: Enable single sign-on auto-login for RDP applications.
HTTP-only Cookie (optional). Select this to indicate whether or not cookies created for this application are only used for HTTP content. For example, if your application uses a Java applet, you may want to disable this option.
Use Post-binding Authentication (optional). Select this if your application is unable to handle a HTTP-302 redirect to validate whether the logged-in user's session is still valid. You may also enable this option if this application may be presented to the user within an iFrame inside the browser.
SSO Cookie Domain (optional). If your application uses iFrames, it may make sense to use a common domain for SSO. For example, if your apps are named app1.company.com and app2.company.com, and they use iFrames, you might consider configuring the SSO domain as company.com.
App authentication domain (optional). When an application supports Kerberos protocol, it has a unique identity called service principal name (SPN) and a service account in the active directory domain or Kerberos Realm with which the SPN is associated. The application authentication domain specifies the active directory domain where the service account was created. If your service uses a computer account in the domain, then specify the domain name of the computer account here. To get more information see:
Service Principal Name (optional). Kerberos protocol end points identify services using a unique service principal name (SPN). Microsoft recommends a specific naming format for SPN based on service type, host name, service port, and service domain. We use this to generate the service principal name based on your application parameters. If your application uses a different service principal name, edit this field to specify the configuration suitable for your application. To learn more, see Forward Kerberos ticket-granting ticket to application
Perform Kerberos Only on Login URL (optional). Enable this feature if your application is required to perform Kerberos authentication only on the login URL.
Forward Ticket Granting Ticket To App (optional). To get more information see Forward Kerberos ticket-granting ticket to application.

Server Load balancing

Metric (optional). Select round-robin or ip-hash policy from the menu to determine how traffic is distributed across origin servers associated with the application.
Enable session stickiness (optional). Use this feature to ensure that a given session always traverses the same connector when interacting with the application. With this option, the application always sees the same IP address for the session, which is required for state maintenance for some applications.

Configure TLS Cipher Suite

Cipher suite configuration - Default (mandatory). Enterprise Application Access provides a default cipher suite which consists of TLS1.2 strong ciphers, and is used to secure TLS between the client and the server. To get more information see Configure TLS Cipher Suite for applications.
Cipher suite configuration - Custom. You can select a cipher suite from the predefined list provided. If you select a weak cipher, a warning is provided recommending the admin to select a stronger cipher for secure a network connection that uses TLS 1.1 or higher version between the client and the server. To learn more, see Configure TLS Cipher Suite for applications

Health check configuration

Type. Specify the type of health check to carry out against all the associated servers to verify service availability.
Not checked for tunnel-type client-access applications since it is a domain and can have many hosts and port ranges.
Rise. Specify the number of consecutive successful heartbeats that connector (or connectors) must receive before considering an application server to be healthy. The default is two.
It is not checked for tunnel-type client-access applications since it is a domain and can have many hosts and port ranges.
Fall. Specify the number of consecutive missed heartbeats before the connector (or connectors) considers an application server to be unreachable.
Not checked for tunnel-type client-access applications since it is a domain and can have many hosts and port ranges.
Timeout. Specify the time that connector (or connectors) must wait before considering a heartbeat attempt to have failed.
It is not checked for tunnel-type client-access applications since it is a domain and can have many hosts and port ranges.
Interval. Specify the interval between successive heartbeats.
Not checked for tunnel-type client-access applications since it is a domain and can have many hosts and port ranges.

Custom HTTP headers

Custom header 1. Use this option to specify the specific headers to insert and forward to the origin application. If your Identity Provider (IdP) includes custom attributes for users to post authentication, select custom from the menu to map attributes provided by the IdP to those supported by the application. To get more information, see Configure custom HTTP headers.

Enterprise connectivity parameters

Floor. Only update this value under the guidance of support.
Floor specifies the minimum number of TLS sessions pre-created by a given connector to enable user access to enterprise applications.
Ceiling. Only update this value under the guidance of support.
Ceiling specifies the maximum number of TLS sessions pre-created by a given connector to enable user access to enterprise applications.
Step. Only update this value under the guidance of support.
Step specifies the incremental number of TLS sessions that is launched by a given connector to enable user access to enterprise applications.
Idle Connection Timeout. Only update this value under the guidance of support.
This value governs when an idle TLS session launched by a given Connector is timed out and restarted.
Application server read timeout. Only update this value under the guidance of support.
This value governs the maximum time that an application server may need to fulfill a user request. By default, the field is set to 60 seconds. Change this to a longer period to avoid receiving 504 error messages while loading the application. The maximum value is 300 seconds (5 minutes).
HTTP Strict Transport Security (HSTS). Configure the lifetime for HSTS policy enforcement on the client browser. The HTTP strict transport security (HSTS) web security policy mechanism helps to protect websites against attacks by forcing users to communicate with servers through HTTPS only. When users send HTTP requests to the server, it responds with a Strict-Transport-Security response header for a length of time specified in seconds. In the response header this length of time is depicted as the max-age attribute.

CDN

All of these options in this section allow you to integrate Enterprise Application Access with Kona Site Defender (KSD) and Akamai Ion to enhance application security and performance.

CDN enabled. You can integrate Enterprise Application Access with Kona Site Defender (KSD) and Akamai Ion to enhance application security and performance. Select this option if the application is being used as a front end by the EAA Cloud service as well as a Content Delivery Network (CDN). When enabled, your traffic is delivered from the CDN instead of the Enterprise Application Access Data POP. When you select CDN enabled additional options appear. To complete this integration and the necessary setup that is required in KSD and Ion, contact support.
Akamai Performance Package. This field appears only if you have enabled CDN enabled. You can integrate Enterprise Application Access with Kona Site Defender (KSD) and Akamai Ion to enhance application security and performance. Select this option if the application is being used as a front end by the EAA Cloud service as well as a Content Delivery Network (CDN). When enabled, your traffic is delivered from the CDN instead of the Enterprise Application Access Data POP. When you select CDN enabled additional options appear. To complete this integration and the necessary setup that is required in KSD and Ion, contact support.
Edge Cookie Encryption Key. This field appears only if you have enabled Akamai Performance Package.
Select this auto-generated key to encrypt the token generated by the Akamai edge node. It helps the Akamai edge validate the user session for caching purposes. Use this as the encryption key within your cookie authorization rule in your Akamai ION configuration. To complete this integration and the necessary setup that is required in KSD and Ion contact support.
SureRoute Test Object. This field appears only if you have enabled Akamai Performance Package.
This auto-generated URL is the test object URL for SureRoute. Copy the URL and paste it to your SureRoute Test Object configuration in Akamai ION. To complete this integration and the necessary setup that is required in KSD and Ion contact support.
Akamai Edge Enforcement. This field appears only if you have enabled CDN enabled.
When you integrate Enterprise Application Access with Kona Site Defender (KSD), Ion, or Dynamic Site Accelerator (DSA) with Enterprise Application Access, your traffic is delivered from the CDN instead of an Enterprise Application Access Data POP. You must grant permission for Enterprise Application Access to see the real client IP and verify the Edge signature. Enable this feature to only authorize traffic from your CDN web properties with an Edge signature and to pass the real client IP on to Enterprise Application Access. To complete this integration and the necessary setup that is required in KSD and Ion contact support.
G2O key. This field appears only if you have enabled Akamai Edge Enforcement.
This auto-generated Ghost to Origin (G2O) key is for use in your Kona Site Defender (KSD), Ion, or Dynamic Site Accelerator (DSA) integration. To complete this integration and the necessary setup that is required in KSD and Ion contact support.
G2O nonce. This field appears only if you have enabled Akamai Edge Enforcement.
This auto-generated Ghost to Origin (G2O) nonce is for use in your Kona Site Defender (KSD), Ion, or Dynamic Site Accelerator (DSA) integration. To complete this integration and the necessary setup that is required in KSD and Ion contact support.

Miscellaneous

Proxy buffer size. Only update this configuration under the guidance of support.
The proxy buffer size denotes the maximum request size that our service expects to receive for this application. This settings sets new "proxy_buffers" and "proxy_buffer_size" directives, which controls how large a response Enterprise Application Access accepts from the proxied upstream server. There are separate directives which control the maximum request header size which are not exposed through the UI but can be set by support on the backend.
Enable CORS. Select this option to let HTTP applications secured by the Enterprise Application Access service make Cross-Origin Resource Sharing (CORS) calls to other applications.
Allowed Hosts. If the Cross-Origin Resource Sharing (CORS) option is enabled, you can provide a space-delimited list of hosts that can access this HTTP application, for example, http://external_site.company.com https://other_site.company2.com.
Allowed headers. If the Cross-Origin Resource Sharing (CORS) option is enabled, you can control which headers may be sent to the protection application by providing a space delimited list, for example, Accept Accept-Language Content-Language Content-Type.
Allowed methods. If the CORS option is enabled, you can control which HTTP methods may be sent to the protection application by providing a space-delimited list, for example, GET POST.
Allow credentials in request. If the Cross-Origin Resource Sharing (CORS) option is enabled, you can use this option to allow for requests that are being made with credentials.
Max Age for Pre-flight Request. Use this option to specify the duration (in seconds) for which an allowed host's pre-flight request is cached and trust is maintained by the secured application. The default is 24 hours (86,400 seconds).
Enable Websocket Support. Select this option to indicate that this application uses WebSockets for HTTP transport. For more information, see Mozilla product documentation.
Use SSLv3. Select this option to indicate that the application can interact with the EAA connector using SSLv3 or not.
Log Access Events. Select this option to indicate that you want Akamai to track access activity of all users connecting to configured applications.
Hide Application from Login Portal. Select this option to indicate that you want to hide this application from the user EAA Login Portal. Users cannot see it.
Forward Proxy. Select this option if your organization uses a forward proxy for Internet-bound traffic.
Dynamic IP For Application Server. Select this option if your application server's IP address may change periodically. When this option is enabled, the connector resolves the IP address for the application server prior to every request.
Use Sticky Cookies For Connectors. Select this option to ensure that requests always get routed to the same connector.
Offload on-premise traffic. When the user is connected to public IPs specified in the on premise subnets of the Advanced settings of the IdP, Enterprise Application Access can recognize that the user is on the network (on-net). Enterprise Application Access can offload any web application traffic directly through the internal hostname of the application. This avoids routing the web application traffic through the EAA Cloud. It is allowed only for access applications. To learn more see: Add public IP gateways to an IdP and Enable on premise users to web access applications bypassing the EAA Cloud.

User-facing authentication mechanism for applications

Define how users authenticate to an application.

Enterprise Application Access (EAA) offers the following authentication options:

Form. Users enter their username and password through the EAA Login Portal page. This is the default authentication option and it can be combined with multi-factor authentication (MFA). Additionally, cookies are used to maintain the user's login state.
Basic. Users are prompted to enter their username and password in a browser dialog. Unlike the Form option, Basic does not support multi-factor authentication and does not use cookies to maintain the user's login state.
Basic+Cookie. Like the Basic option, this option prompts users to enter their username and password in a browser dialog. The Basic+Cookie option, however, uses cookies to maintain the user's login state.
Certificate Only. This option is available when certificate-based authentication is enabled. With this option, no login credentials are required. Users are authenticated with the certificate that is stored on their machine or device.

Select one of these options in the User-facing Authentication Mechanism setting in the Advanced Settings of an application configuration. These authentication options or mechanisms only apply if the application is assigned to an identity provider (IdP) with an Active Directory (AD), Lightweight Directory Access Protocol Directory (LDAP) or Active Directory Lightweight Directory Services (AD LDS).

Configure the user-facing authentication mechanism

To define how a user authenticates to an application, you must configure an application with one of the following directories:

Active Directory (AD)
Lightweight Directory Access Protocol (LDAP)
Active Directory Lightweight Directory Services (AD LDS)

If certificate authentication is enabled, you also have the option to select Certificate Only as a user-facing authentication mechanism. For more information on certificate-based authentication, see Certificate-based authentication in the IdP.

If you are creating a new application, see Add an application to EAA. If you are modifying an existing application, continue to step 2.
Log in to the EAA Management Portal.
In the EAA Management Portal navigation menu, select Applications.
On the application card, click Settings, and select AUTHENTICATION.
If there is no identity provider assigned, assign an identity provider:
1. Click Assign Identity Provider and select an identity provider from the list.
2. Click Save & go to Services.
In ADVANCED SETTINGS > Authentication > User-facing Authentication Mechanism select one of the following:
- form
- basic
- basic+cookie
- certificate only
Click Save & Exit.
Deploy the application.

Server load balancing for applications and connectors

Load balancing efficiently distributes network traffic across a group of back end servers. A load balancer is piece of hardware (or virtual hardware) that distributes network and application traffic across different servers. It's used to increase the concurrent user capacity and overall reliability of applications. Enterprise Application Access can balance traffic load across a group of servers, monitor the health of each application server, and apply a variety of load balancing policies. Enterprise Application Access uses these advanced application settings to configure server load balancing:

Metric. Enterprise Application Access distributes traffic across origin servers by either round-robin or IP hash metrics. For round-robin balancing, traffic is distributed across all available servers. For IP hash balancing, EAA takes a hash from a specified server and serves the session content from there. The default metric is round-robin.
Enable session stickiness for applications. Session stickiness makes sure that a session uses the same connector when interacting with the application. When this is enabled, Enterprise Application Access uses sticky cookies which stay in place and do not change in order to maintain the same IP address for the session. In this way, the application always sees the same IP address for the session. This feature is needed for state maintenance of some applications.
Refresh sticky cookies. Enterprise Application Access can refresh a sticky cookie to make sure that the content goes to the same connector (server) to prevent session lag or content loss in a session. Even after the session length has passed, the session does not go to a new connector. This feature is only available when you enable session stickiness.
Use sticky cookies for connectors. Server redundancy balances the load on servers and provides a backup or fail-over contingency for your traffic. You can prevent server redundancy by using sticky cookies for connectors. This feature, disabled by default, ensures that requests get routed to the same server, also referred to as a connector, instead of a backup server. Enable this to ensure that requests always route to the same connector when multiple connectors are deployed for a single application, and the user connection goes to the same connector each time. This feature is available even if you do not enable session stickiness.

Configure server load balancing for applications and connectors

Log in to the EAA Management Portal.
In the EAA Management Portal navigation menu, select Applications.
On the application card, click Settings, and select ADVANCED SETTINGS.
In Server load balancing, select one of the Metric parameters:
- Round-robin (default)
- IP hash
Optionally, to enable sticky cookies, select Enable Session Stickiness.
1. Choose either to Specify cookie age and enter a cookie age in seconds or Derive the age from the server cookie if you prefer to use the cookie lifetime set by the origin server. If you choose to derive the age from the server, type the server cookie name into the field.
2. Select Refresh sticky cookie.
Optionally, to use sticky cookies for connectors, go to the advanced settings Miscellaneous and select Use sticky cookies for connectors.
Click Save and go to Deployment.
Deploy the application.

Enable load balancing for several application servers

Configure an application for load balancing using two or more application servers.

Log in to the EAA Management Portal.
In the EAA Management Portal navigation menu, select Applications.
On the application card, click Settings, and select ADVANCED SETTINGS > Server load balancing.
In Application server IP/FQDN enter the IP address or FQDN and port number for an application server.
Click Add more to add additional servers.
In ADVANCED SETTINGS, select one of the Metric parameters:
- round-robin (default)
- IP hash
To enable sticky cookies, select Enable Session Stickiness.
Choose either to Specify cookie age and enter a cookie age in seconds or Derive the age from the server cookie if you prefer to use the cookie lifetime set by the origin server. If you choose to derive the age from the server, type the server cookie name into the field.
Select Refresh sticky cookie.
To use sticky cookies for connectors, go to the advanced settings Server load balancing, and select Use sticky cookies for connectors.
Click Save and go to Deployment.