Authorize access to applications
Assign a directory to an application
Assign a directory to authorize user access for an application.
Prerequisites:
-
Log in to EAA Management Portal.
-
In the EAA Management Portal navigation menu, select Applications.
-
On the application card, click Settings, and select AUTHENTICATION.
-
Click Assign directory.
List of directories appears. -
Select directory you want to assign to the application.
The directory card expands to display more information and available actions. -
To authorize user access to the application, click Assign Groups.
-
Select groups you want to authorize access for.
-
Click Done.
-
Click Save and exit, or to set up services for an application, click Save and go to Services.
-
Deploy the application.
Next, to authenticate single sign-on for an application, assign identity providers to an application.
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 EAA Management Portal.
-
In the EAA Management Portal navigation menu, select Applications.
-
On the application card, click Settings, and select SAML SETTINGS.
-
Enter SSO logout URL.
-
Click Save.
-
Deploy the application.
Offload web application traffic from EAA Cloud
When the user is connected to public IPs specified in the on-premises subnets of the Advanced settings of the identity provider (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 Enterprise Application Access Cloud. It is allowed only for access applications.
Add public IP gateways to an IdP
To allow IdP to recognize public IP gateways that users are connected to, you must add these public subnets as a list in the IdP advanced settings. This enables the IdP to classify these inbound connections as on-premises traffic.
-
Log in to EAA Management Portal.
-
In the EAA Management Portal navigation menu, select Identity > Identity providers.
-
On the IdP card, click Settings, and select ADVANCED SETTINGS.
-
In On premise subnets enter an outbound web gateway IP address or subnet.
Click Add more, to add additional subnets. -
Click Save go to Deployment.
-
Deploy the IdP.
Enable on-premises users to web access applications bypassing the EAA Cloud
Allow Enterprise Application Access (EAA) to offload web application traffic directly to end users are on-premises.
-
Log in to EAA Management Portal.
-
In the EAA Management Portal navigation menu, select Applications.
-
On the access application card, click Settings, and select ADVANCED SETTINGS.
-
Select Show additional attributes.
-
In Miscellaneous, select offload on premise traffic.
-
Click Save and go to Deployment.
-
Deploy the application.
Application groups for rewrite rules
Create rewrite rules for related applications in a group. Application groups allow you to apply rewrite rules across distinct applications that are related to one another. In Enterprise Application Access each application is independently considered and rewrite rules must be independently written. However, rewrite rules may apply to multiple applications. Applying rewrite rules across multiple, related applications can be cumbersome at an individual level. Enterprise Application Access application groups allow you to apply rewrite rules to multiple applications at once.
For example, consider the Atlassian products of JIRA, Confluence, and Bitbucket. These are three different applications in the Atlassian group. In the Enterprise Application Access rewrite group, you identify the related applications and add applications links to the rewrite rule only once. When you deploy the application group, the rewrite rule applies to all of the applications in the group. The use of the application group enables you to apply the rule and deploy once instead of three separate times for each application in the group.
For Japanese language, you can use a maximum of 240 characters for the group name.
Create application groups for rewrite rules
Apply optimizations to applications groups. Application groups allow you to apply rewrite rules across distinct applications that are related to one another. To learn more about application groups for URL rewrite rules, see Access control rules.
-
Log in to EAA Management Portal.
-
In the EAA Management Portal navigation menu, select System > Application groups.
-
Click Add group.
-
Enter a group name, and click Create group and configure.
-
Click Add or remove applications.
-
Select an application from Available Applications.
The selected application appears in Assigned Applications. Repeat this step to add more applications. -
Click Done.
-
Click Save.
For next step, see URL rewrite services.
Single Host Access for access applications
Enable accessing multiple access applications using a single fully qualified domain name (FQDN). When you configure an access application provide a unique external FQDN (fully qualified domain name) for each internal hostname. For example, if you want to access these three applications app1
, app2
, and app3
using Akamai domain as the external hostname, you have to configure three unique external hostnames.
Single Host Access requires a special feature key. Please contact support.
Prerequisites (ION/DSA or Proxy):
Organizations should use ION/DSA or an equivalent proxy in front of Enterprise Application Access. The proxy need to redirect.
Application URL patterns. Organizations that have a large set of applications follow these URL patterns to identify them. They may use a FQDN-based (fully qualified domain name) or a URL path-based approach.
Most organizations use a fully qualified domain name (FQDN) to identify applications, for example:
- CRM App -
https://crm.acme.com/
- Payroll App -
https://payroll.acme.com/
- HRMS App -
https://hr.acme.com/
Other organizations use a URL path to identify applications, for example:
- CRM App -
https://acme.com/crm
- Payroll App -
https://acme.com/payroll
- HRMS App -
https://acme.com/hr
Enterprise Application Access Cloud, an identity aware proxy, was supporting the FQDN-based approach. If an organization was using a URL path-based approach, they had to re-factor all the applications, test and validate the changes, notify the users of the changes, before up-taking a migration to Enterprise Application Access Cloud to enable zero trust access. This causes additional resource, budget, and time overhead for organizations.
Enterprise Application Access supported only the FQDN-based approach. With ION/DSA and the Single Host / Multiple Apps feature which is under Controlled Availability, Enterprise Application Access also supports the URL path-based approach. This feature enables organizations to retain their existing application URL patterns, move to a modern Enterprise Application Access Cloud, without requiring IT to refactor existing applications. The combination of Enterprise Application Access and ION/DSA gives organizations a complete solution through which they can deliver a superior digital experience, optimize performance through acceleration and enable secure remote access using zero trust principles.
Internal Hostname | External Hostname |
---|---|
http://app1.yourcompany.com | http://app1-yourcompany-com.go.akamai-access.com |
http://app2.yourcompany.com | http://app2-yourcompany-com.go.akamai-access.com |
http://app3.yourcompany.com | http://app3-yourcompany-com.go.akamai-access.com |
With single host access, you can configure a single FQDN, and access all the access applications with a unique URL path for each application, after they are added to the application group. Single host access feature does not work with RDP, SSH access applications.
If the organization URL is https://yourcompany.com
, you can set yourcompany.com
as the single host access FQDN, add these three applications to a single application group, and configure the URL paths. Then you are able to access these three access applications using the modified external hostname:
Internal Hostname | URL path | Modified External Hostname |
---|---|---|
http://app1.yourcompany.com | /app1 | http://yourcompany.com/app1 |
http://app2.yourcompany.com | /app2 | http://yourcompany.com/app2 |
http://app3.yourcompany.com | /app3 | http://yourcompany.com/app3 |
This enables Enterprise Application Access to do an automatic redirect to all of the modified external hostnames, allowing the user to access all the three applications from Enterprise Application Access Cloud after you SSO to the login portal. You can expose a single host and route the users based on the URL path. This provides ease of use and improves productivity for an organization.
If you have a proxy server like ION, you need to configure the following:
-
Add the single host FQDN as the property hostname. For example,
yourcompany.com
. -
Configure rules based on path matching, for each EAA application. For example, configure these three rules:
Application Name | Rule in ION |
---|---|
app1 | If path matches /app1/* |
app2 | If path matches /app2/* |
app3 | If path matches /app3/* |
- Configure the Origin Server Hostname in the Origin Server. It is the application URL in EAA. For example, configure these three origin server hostnames:
Application Name | Origin Server Hostname in ION |
---|---|
app1 | https://app1-yourcompany-com.go.akamai-access.com |
app2 | https://app2-yourcompany-com.go.akamai-access.com |
app3 | https://app3-yourcompany-com.go.akamai-access.com |
- Set Forward Host Header to Origin Host in Origin Server.
Now, when ION receives a request from the user's browser to access an application using the modified hostname, ION knows what rules to follow, and where to forward to the Enterprise Application Access Cloud service. Enterprise Application Access rewrites URL to provide access to the correct application in the data center.
For more information, see ION documentation.
Configure single host access and application groups for accessing HTTP access applications
-
Create and configure HTTP, HTTPS access applications or web applications in Enterprise Application Access.
-
Create an application group, enable single host access, provide the single host FQDN, add the URL paths, and add the EAA applications to this application group.
-
Log in to EAA Management Portal.
-
In the EAA Management Portal navigation menu, select System > Application groups.
-
Click Add group.
-
Enter a group name, description, and click Create group and configure.
-
In Rewrite group info, select Enable Single Host Access.
-
In Single Host FQDN enter the single host fully qualified domain name for all your applications, like your organization URL.
-
Click Add or remove applications.
-
Select an application from Available Applications.
The selected application appears in Assigned Applications. Repeat this step to add more applications.
Click Select all to assign all available applications. -
Click Done.
-
Provide the URL path for each of the selected application.
-
Click Save and go to deployment.
-
Click Deploy Group.
Wait for all applications to be deployed.
App Deployed status appears for each application in this application group.
-
-
Configure proxy rules in ION/proxy to redirect all Single Host URL requests to specific EAA Application URL based on the URL path in the request. For more information, see ION documentation
Updated about 1 year ago