Find, edit, and share device-specific resources with the Access module of BIG-IQ® Centralized Management.
In BIG-IQ® Centralized Management, you can associate various local traffic objects without manually configuring the objects in individual BIG-IP® devices before deploying the Access configuration on these devices. You must create these objects in either the BIG-IQ local traffic component or in BIG-IP local traffic. :
For more information about configuring BIG-IQ local traffic objects, refer to the online help, and to the guide, F5 BIG-IQ Centralized Management: Local Traffic & Network.
This table describes the relationship between local traffic objects and APM objects. Specifically, this explains which local traffic objects are used in which Access objects.
|LTM Object||Access Object|
|Server SSL Profile||
|Net Tunnels Fec||
In an access policy, you define the criteria for granting access to various servers, applications, and other resources on your network. An access policy can be either a per-session policy or a per-request policy. You create an access policy by creating an access profile, which automatically creates a blank access policy. Every access profile has an access policy associated with it. You configure that access policy through the access profile, using the Visual Policy Editor.
Access in BIG-IQ® Centralized Management provides two types of policies.
One per-session policy and one per-request policy are specified in a virtual server.
These actions can't be undone and also can't be undone if there are any pending diagram changes.
Undo returns you to the access policy before your most recent change.
Redo allows you to redo an action you have undone.
Revert returns the access diagram to the state before you made any changes to the diagram.
During an editing session, if you remain inactive for a prolonged period of time, the session times out. Other times, the browser might freeze. In either case, you might have to prematurely terminate an editing session without a chance to save your changes. However, regardless of why you had to terminate a session, BIG-IQ® Centralized Management saves a draft of the policy and saves any unsaved macro when you make a modification. The next time you log in, locate the policy, and open the editing screen. The system notifies you that an unsaved draft exists, and prompts you to select whether you want to continue editing the draft or start over.
The system saves the change history in the draft, so actions such as Undo and Redo work for all changes you make before the session was interrupted. Lastly, if someone else was the previous editor, you can see the user and the time of the last edit. This allows you to choose whether or not to resume that person's editing session.
The table summarizes per-session policy and per-request policy similarities and differences.
|Feature||Per-Session policy||Per-request policy|
|Requires that users click an Apply Access Policy link to go into effect.||Yes||No|
|When run||At session start.||After session is created, on every request.|
|Policy ending types||Allow, Deny, Redirect; endings apply to the session.||Allow, Redirect, Reject; endings apply to URL requests processed in the per-request policy. A Reject ending triggers the Deny ending in the access policy.|
|Supports variables||Creates session variables that are available throughout a session.||Reads available session variables. Creates per-flow variables that are available only while the per-request policy runs.|
An ending provides a result for an access policy branch. An ending for an access policy branch is one of three types.
A terminal is a sub-policy ending in an access policy. Differing from a policy ending, terminals do not have types and you can re-order them. The order of a terminal in a sub-policy determines the order of the branches in the macro-calls. Similar to policy endings, you can't create, change, or delete a terminal if there are pending changes in the policy.
A macro is a sub-policy with a beginning, one or more policy items, and one or more endings. You can create or edit a macro as you would a policy. In a policy, a macro-call in the workflow represents the macro. When you insert a macro-call in a policy or another macro, it displays as a node in the workflow diagram. Typically, you use a macro in multiple branches of the workflow.
Macros are specific to an access policy. You cannot create a macro if there are pending changes to the access policy. You can also create special macros. These have the same workflow as the base macro type. However, you can only use subroutines in per-request policies and subroutine macros in subroutines.
You can compare two snapshots, or compare a snapshot to the configuration on the BIG-IQ Centralized Management system to view their differences.