Applies To:

Show Versions Show Versions

Archived Manual Chapter: Understanding Secure Access Policies
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.

In an access policy, you define the criteria for granting access to various servers, applications, and other resources on your network.
Using an access policy, you can define a sequence of checks to enforce the required level of security on a users system, before the user is granted access to servers, applications, and other resources on your network.
An access policy can also include authentication checks, to authenticate a user before the user is granted access to the network resources.
Collect information about the client system
You can use the access policy to collect and evaluate information about client computers. For example, you can check that the user is operating from a company-issued computer, what antivirus software is present on the machine, what operating system the computer is running, and other aspects of the client configuration. This is accomplished using client-side checks and server-side checks in the access policy.
Use the authentication action to verify client security against external authentication servers
The access policy allows you to check and evaluate authentication against an external authentication database or a certificate, to make sure the client system recognizes the user.
Retrieve users rights and attributes
You can use the access policy to retrieve extended information from authentication servers including LDAP or Microsoft Active Directory® attributes, and use the information retrieved to assign different resources.
Grant access to resources
With the access policy, you assign a network access resource after the client is authenticated.
You start all access policies with a start point, and every access policy has at least one rule branch. All access policies have one or more endings.
The simplest successful access policy you can configure has a start point connected to a properly configured resource assign action, which is then connected directly to a webtop ending. When a user connects with this access policy, the user is assigned a network resource by the resource assign action. The user then goes to the webtop policy ending, and the network access resource is assigned to the user.
However, typical access policies include more than a start point, resource assign action, and end point. Typically, an access policy contains one or more client-side checks, such as an antivirus, firewall, or operating system check, logon and authentication actions, and a resource assignment action, followed by at least one successful ending (webtop), and failure endings (logon denied) for non-successful rule branches.
The basic access policy in Figure 4.1 includes actions that have successful and fallback rule branches (Antivirus Check, Firewall Check, Active Directory), and actions that have single rule branches (Logon Page and Resource Assign).
Every access policy begins at a start point. This is a green rectangle with an angled right side, labeled Start, that has one fallback branch connected to it. You build the access policy starting on this fallback branch.
An action performs a specific function in an access policy. These functions include client checks, authentication checks, and other access policy functions.
In the visual policy editor, the action appears as a rectangle surrounded by a single line in the access policy, with one branch entering it on the left, and one or more branches exiting on the right. If the action requires configuration, a red asterisk appears to the left of the action, and the name of the action appears in italics. In Figure 4.3, the RADIUS action is properly configured, and the resource assign action requires configuration.
The Secure Access Manager includes a number of pre-defined actions. You can see the available actions in the visual policy editor when you click the Add Item button , which is activated by positioning the cursor along the actions rule branch. The Add Item popup screen opens as a floating popup screen on top of the visual policy editor, as shown in Figure 4.4.
Table 4.1 describes all the actions available in Secure Access Manager.
Adds a logon page to the access policy. You can customize the messages and link text on the logon page, and create custom messages for different languages.
Assigns an ACL, a resource group, or both to the access policy. A resource group includes network access resources, which can include traffic settings, a lease pool, and ACL, DNS and host settings, drive mappings, and applications to launch.
If the Client SSL profile is configured to request the client certificate during the SSL handshake, checks the client certificate received during the SSL handshake.
Cleans and removes browser cache, and optionally cleans form entries, passwords, dial-up entries, and forces the webtop to close or timeout under some conditions.
Detects the browser of client type the client is using. This provides three rule branches in your access policy.
Full Browser
The rule branch the access policy takes if the client is using a web browser, or the standalone client in Web Browser mode.
Standalone Client
The rule branch the access policy takes if the client is using a standalone (installed) SSL VPN client. This rule branch is used only if the standalone client is running in Legacy Mode. If the standalone client is used, but the client is not running in legacy mode, the Full Browser rule branch is used.
The rule branch the access policy takes if the client is not using one of the listed clients. See Preparing for clients that cannot use client checks.
Detects the operating system of the remote client. Secure Access Manager detects this using information from the HTTP header.
A rule evaluates the result of an access policy action, findings about a client system, or other access policy item. The outcome of the evaluation of a rule grants or denies access, or continues on to the next action. The order of rules in an access policy determines the flow of action.
In an access policy, you use actions for which a set of rules are already defined. You can add rules to an action, or create new rules to test for a specific condition. You can use empty actions to create custom actions, and add your own rules to them. The ending is the last rule applied. Figure 4.5, shows the flow of a rule-checking operation.
By default, if the users system does not meet the access policy requirements, the Secure Access Manager denies the user access. You can change this outcome by changing the access policy ending, and by modifying rules to check for different criteria.
When you create a new action, the visual policy editor automatically creates a set of rules. The last rule in this set is the fallback rule. It cannot be moved. It governs all cases that do not satisfy a preceding rule.
Figure 4.5 shows the internal process of an action.
To view a predefined rule, you must first add an action to the access policy. The following example describes how to add a predefined action (client cert result) to an access policy, then how to view the underlying rule.
On the Main tab of the navigation pane, expand Access Control, then click Access Profiles.
The Access Profiles screen opens.
In the profile list, find the access policy you want to edit, then click Edit in the Access Policy column.
The visual policy editor opens in a new window or new tab, depending on your browser settings.
If the Authentication category is not expanded, click the plus sign () to expand it.
Select Client Cert Result and click Add Item to add the action to the access policy.
The Client Cert Result action popup screen opens.
Click the Rules tab.
Under the Name Successful, you see the text
Expression: Client Certificate is valid, and then a link to change the expression.
Click change.
The Expression popup screen opens.
Click the Advanced tab.
Predefined rules are created when you configure actions. To further refine or customize a rule, you can use the expression builder to build a rule from a list of agents and conditions.
You can edit a rule by going to the Rules tab and clicking change. Rules can be edited in a rule builder on the Simple tab. You use this rule builder to choose from a simplified set of rules and automatically compile the Tcl syntax. You can also go to the Advanced tab and edit the rule directly, using Tcl. The two editing methods are shown in Figure 4.7.
In the visual policy editor, you connect access policy items to other items with branches. A branch represents one of following three things:
The result of the evaluation of an access policy rule
Most actions have branches that represent the evaluation of rules. These branches might be called Successful, or they might have a more descriptive name. In many cases, a rule branch is a positive result to the evaluation of an action (for example, Active Directory authentication has passed). A rule branch can also be an informational response to the evaluation of an action (for example, client operating system is Windows Vista®).
An outgoing terminal from an access policy macro
When you configure an access policy macro, the rule branches inside the access policy macro have endings called terminals. These terminals do not function like access policy endings, but instead, become branches in the access policy to which the macrocall is added.
A fallback rule
A fallback rule is typically a negative response, if the action has successful branches. Some fallback rules are the result of the action returning no match or a failure for the access policy check. Fallback rules are also the result of actions that have no positive and negative result. For example, the logon page action has no positive or negative result, because it sends only a logon page to the client, so the result branch of a logon page is always a fallback rule branch.
A macro is a collection of actions that you can configure to provide common access policy functions. You can create a macro for any action or series of actions in an access policy. You can also create macros that contain macrocalls to other macros (nested macros).
After you create a macro, you place it in the access policy by adding an item called a macrocall to your policy. A macrocall is an action that performs the functions defined in a macro. In the visual policy editor, a macrocall appears in an access policy, or in a macro definition, as a single rectangular item, surrounded by a double line, with one or more outgoing macro terminal branches, called terminals.
Macro definitions, macro terminals, and macrocalls are defined for each access policy. Macros you create in one policy do not appear, and cannot be used, in another access policy.
Unlike other access policy actions, when you click a macrocall in the access policy, the macro definition is displayed below the access policy in the macros section, and not in a popup screen.
The BIG-IP® Secure Access Manager includes several predefined macro templates. For example, BIG-IP Secure Access Manager includes macro templates for the three authentication methods, and for a Windows antivirus and firewall check. For the definitions and configuration information for these included macro templates, see Configuring macros.
Note: You can make changes to the actions in a macro after you have added the macrocall to an access policy. However, you cannot delete terminals after a macrocall has been added to an access policy or another macro. For this reason, we recommend that you configure the macro terminals before you add it to the access policy.
Terminals are the macro branches that are the result of the actions you add to the macro. Terminals are made available to the access policy after you insert the macro into an access policy. A macro can have many terminals.
To make macros easier to use, you can assign the macro terminals descriptive names and specific colors. When you add a macro to your access policy, the terminals from the macro become branches, and the branches take the names of their terminals.
After you add the macrocall to your access policy, the macrocall appears as a single access policy item, with four terminals that appear as four branches, named for the terminals. See the following figure.
Access policy endings indicate the final outcome of a branch of the access policy. The Secure Access Manager provides the following endings: Webtop, Logon Denied, and Redirect. In the visual policy editor, endings appear as a rectangle with a cut-out left edge.
In an access policy, the webtop ending is a successful ending that connects a user to the assigned network access resource. This is done by presenting the network access webtop to the user. Configure your access policies so only users who meet your security criteria reach a webtop ending.
In an access policy, the logon denied ending denies the user access to the network access resource, and ends the users session. After the user reaches a logon denied ending, all the session information collected during access policy operation is deleted from the client. You can use this ending at the ends of failed rule branches. When a user reaches a logon denied ending, the user sees an access denied error message web page.
In an access policy, the redirect ending sends the user to a URL that you specify. Use this ending when the result of a certain access policy outcome does not result in a webtop ending, but you want to send the user to another internal or external URL. For example, you might send a user to the web site for an antivirus vendor, if an antivirus action determines that the users virus definitions are older than the access policy allows.
The rules in access policies use the values that the actions return in session variables. During access policy operation, the Secure Access Manager collects various information about the system that is attempting access. This information is organized in a hierarchical arrangement and is stored as the users session data.
Session variables are variables that allow the access policy to access users session data. The name of a session variable consists of multiple hierarchical nodes separated by periods (.).<username>.queryresult = query result (0 = failed, 1=passed)<username>.authresult = authentication result (0 = failed, 1=passed)<username>.attr.<attr_name> = the name of an attribute retrieved during the Active Directory query. Each retrieved attribute is converted to a separate session variable. Note that attributes assigned to a user on the AAA server are specific to that server, and not to Secure Access Manager.
The Figure 4.13 shows how a session variable is named.
You can use session variables to customize access rules or to define your own access policy rules. You can assign users specific resources based on session variables, using the resource assign action.
You can use session variables to configure rules in access policies. You can use the values of session variables to provide different outcomes for policies. For more information on how to use session variables, see Assigning variables, and Using advanced access policy rules. For a complete listing of available session variables, see Appendix C, Session Variables.
You can view all session variables for a session at Reports > Current Sessions. Click a session name to view the session variables for the session.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?

NOTE: Please do not provide personal information.

Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)