Set up advanced settings for an application
Enterprise Application Access (EAA) allows you to configure advanced settings that apply to your applications. These configurations are generally optional. In Enterprise Center 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. For more information, see: Configure SAML single log out
-
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
andapp2.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. To get more information, see Server load balancing for applications .
-
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. To get more information, see Server load balancing for 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 . 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 themax-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. 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.
Cross-Origin Resource Sharing (CORS)
CORS allows an HTTP application secured by EAA to make calls to other applications.
-
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).
Limitation
If the administrator enables CORS but keeps the 'Allowed Hosts, Allowed headers and Allowed methods' to 'unbounded', then EAA will respond to the preflight request with a '204 No content' response. If valid values are configured for these settings, EAA responds accordingly.
As a work-around to bypass the 204 response, you can disable CORS. In this case, the OPTIONS call request is forwarded to the origin server.
-
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.
-
TCP/Tunnel Client-access application idle timeout. You can configure the idle time out for TCP-type client-access applications and tunnel-type client-access applications in seconds. The maximum value is 15 minutes or 900 seconds. Only update this value under the guidance of support.
-
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.
Configure SAML single log out (SLO)
A standard protocol for enabling single sign-on (SSO) is SAML. SAML contains a feature called single log out (SLO), which is a protocol that allows a user to terminate all server sessions established by the SAML SSO by initiating the log out process once. SLO can be initiated by the identity provider (IdP) or the service provider (SP). See Single sign-on (SSO) authentication and SAML.
In Enterprise Application Access, SLO can be enabled for applications with the application profile of SAML. For each SAML application, enable the setting both in the Enterprise Application Access application's SAML Settings and outside of Enterprise Application Access within the native application itself.
-
Log in to Enterprise Center.
-
In the Enterprise Center navigation menu, select Application Access > Applications > Applications.
-
Select your application to open it.
-
In Advanced > Authentication enter SSO logout URL.
-
Click Save and Deploy.
Updated about 1 month ago