Add access control rules

Access Control Types

In Enterprise Center for Enterprise Application Access you can create an access control rule to block or deny access to an application based on the criteria listed in the below table.

Creating rules with ACL

For every rule you create, you select the access control type, an operator, and then define the values for the selected type. You can choose whether an operator is or is not is restricted as a control type.

These conditions also apply to rules:

• By default, access control rules are disabled for an application. You must enable the feature and then configure the rules and the criteria you require.
• A rule can contain one criterion or multiple criteria. The criteria you provide in a rule are combined with an AND operator. For example, with the following criteria, the conditions are combined to block User A from accessing the application from 1am to 2 am on a Saturday.

• If multiple rules are created for an application, these rules are combined with the OR operator. This allows you to use the same control types in multiple expressions and ensure there is no conflict.

For example, as shown in the Figure, if User A attempts to access the application between 1 am and 2 am or 11 pm and 12 am EST on a Saturday, they are denied access.

After you save the rules, the combined rule appears as:

• The criteria you create in a rule are combined with an AND operator. This means that all conditions are applied to deny access. If you configure multiple rules, the rules are applied with an OR operator to ensure that if any of the conditions in a rule apply, access to an application is denied.
• Access control rules are not applied to an application until you deploy the application. If you make changes to the access control rules, after an application is deployed, you must re-deploy the application for the new rules to apply.

When a user is denied access as a result of an access control rule, by default, an HTTP 403 Forbidden error message appears. See Application response codes, login events, and errors.

Exact matching and substring matching using ACLs

When you use Access Control Rules (ACL) with EAA Applications, exact match is used for Access Control types of Group, User, Method, Country, App Host, and App Protocol. In earlier releases, substring matching was used. This change ensures a more precise and predictable access control behavior. However, URL criteria will continue to use substring matching.

See the examples below for understanding the difference between exact matching and substring matching for different Access Control Types.

Group Access Control Type

For example, if you want to deny access to members of ERP group, you must specify the deny rule as below:

Note: If you have other related groups like ERP-Dev, ERP-QA (which are substrings of “ERP”), they will still be allowed access.

But, if you wish to deny access to members of all ERP, ERP-Dev, ERP-QA groups, you must specify a complex deny rule as below:

URL Access Control Type

In the URL Access Control type, you can configure the path value that you may use in your application URL. If you are using an URL criteria as the Access Control Type for creating your deny rules, substring match is used by default.

Let’s look at some examples to understand this behavior:

1. If we create a deny rule as:

When you access the following application with these paths you will see this behavior:

2. If you wanted to match www.google.com, www.google.com/docs, and www.google.com/gmail, you would create a URL path rule as below:

Since substring matching is allowed by default for URL path, this rule would deny access to all three paths: www.google.com, www.google.com/docs, www.google.com/gmail, and any other subdomains of www.google.com. But it would not deny access to sheets.google.com, since it is not a matching substring of www.google.com.

Note: To deny access to only www.google.com/gmail, you would specify the deny rule as:

However, this rule will not deny access to www.google.com/docs or www.google.com and the user is allowed access, since they are not substrings of www.google.com/gmail.

Redirect to custom URL page or custom Access Denied page

If you want to redirect the user to a custom URL page when access to an application is denied due to an ACL (excluding Device Posture tiers, tags, or versions) , you can configure authorization failure redirect options in the advanced settings of the IdP. Or, if you redirect the user to a custom EAA Access Denied Page, when access to an application is denied due to an ACL, you can configure a custom EAA access denied page in the advanced settings of the IdP.

📘

Note

1. Using ACL with custom URL or custom access denied page, is not supported if you use Device Posture Risk Tier or Risk Tag in your ACL.
2. Using ACL with custom URL or custom access denied page, only works with Akamai IdP. It is not supported on third party IdP.

📘

Note:

You can add access control rules for an Application.

Or alternatively,

You can also try out adding Access Ruleset to Application Access Groups. For more information, see our Beta feature, Connector Pools, Application Access Groups (AAG).

1. Log in to Enterprise Center.
2. In the Enterprise Center navigation menu, select Application Access > Applications > Applications.
3. Locate the application you want to configure ACL for.
4. Click Access tab, enable Access option.

a. To create a new rule, click Add Rule (+).

b. To edit an existing rule, click Edit Rule.
A modal window appears.

5. Enter a name for the rule and click Add.

6. Select a Type for the ACL. See Access Control Type table above.

7. In Operator select either isor is not.

8. In Value enter the value if applicable or select the value for the access control type.

   a. Click Time to configure the time-based settings.

   b. In Start Time and End Time enter a time in hh:mm, AM-PM format.

   c. In time zone select a timezone.

   d. Select the days of the week that you want to deny access.

   e. Click Save Rule (✓).
   The rule appears as Access Control in the Services column.

9. To add another criterion to the rule click Add Criteria (+), and repeat the above steps.

10. To delete the rule, click the Delete Rule (trash icon), and click Delete.

11. To edit the rule, click the Edit Rule (pencil icon), and make the edits, and click Save Rule.

12. Click Back to Configuration Services, and save these changes.

13. Click Save and Deploy, to make these changes to go into effect.

14. (optional) If you want to set up a custom EAA Access Denied Page for access denied due to ACL, you can configure a custom EAA access denied page in the advanced settings of the IdP.

15. (optional) If you want to redirect the user to a custom URL page when access to an application is denied due to an ACL, you can configure authorization failure redirect options in the advanced settings of the IdP.

Note: If you do not configure 14, 15, when the user is denied access to the application due to ACL, they will see HTTP 403 Forbidden message.