Forum Discussion
APM Gating Criteria sub-routines
Does anyone have real-world examples of using the new per-request policies in APM 12.1?
The docs are terse on how the gating criteria work, is there anything that I need to perform in the main access policy?
- James_HuEmployee
Subroutine in a nutshell
A subroutine should be thought of as a sub-policy, which has its own associated sub-session. If a subroutine has an established sub-session, subroutine execution is skipped. This is analogous to skipping APM's access policy once the APM session is established. A subroutine is therefore useful for use cases that require user interaction (such as a confirmation dialogue or a step-up authentication), since it allows skipping that interaction in a subsequent access.
There are primarily two ways that subroutine gating criteria can be used. One is as a way to control fanout of the per-request policy when a sub-session is required. Another is as a way to trigger an interaction when conditions change.
Controlling fanout
The subroutine gating criteria is a way to simplify policy writing in the per-request policy. For example, if you wanted to use a subroutine to present a dialogue box that requested the user to acknowledge they are visiting a site category that requires manager approval (but the approval is based on the honor system), then a possible subroutine policy might look like:
And the subroutine could show up in the per-request policy like this:
Since the effective category is being used as the gating criteria, each different effective category value results in a different sub-session. This means each different effective category will be presented with its own prompt. If the same effective category is encountered again, then the subsequent access will not be prompted until the sub-session expires.
Without this mechanism, to achieve the equivalent behavior would require a separate branch for each category that required its own confirmation. You would have to imagine the SWG macro having multiple Confirm branches, one for each category that needed confirmation, and then a separate instance of the Confirm subroutine attached to each of those branches. Note that a different subroutine has to be authored for each branch, otherwise every branch would share the same subsession. The gating criteria is a mechanism that can be used to prevent this fanout.
Trigger an interaction
Another way to use the gating criteria is to trigger the subroutine to execute when conditions change. An example of conditions changing could be detecting the use of a different browser. The SWG macro could apply a variable assignment (available in APM 13.0) to assign a value to the custom perflow variable that combines the user agent string with the SWG category.
Then, that variable can be used for the gating criteria.
Now, if the user switches browsers, the confirmations will be re-prompted.
In APM 14.0, the variable assignment agent can be removed, because the gating criteria was enhanced to allow an expression in addition to perflow variables.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com