v12 APM, Profile scope

Arnaud's answer is correct, but I wanted to attempt to address some of the questions and explain the motivation for the feature.

If you had always used the same Access profile (and thus Access policy) on all virtual servers, then the old behavior and the current default behavior would be exactly the same. The policy would be executed once per session, and the session would be valid across any virtual server that used the same Access profile.

But, the motivation for the feature was for multiple Access profiles. For example, if two external virtual servers each had a different Access profile, what was the expected behavior?

In the old behavior, APM mostly acted like there was only a single super-profile with a single super-policy. Different Access profiles were treated as a means to create a policy specific to that virtual server, and each Access policy was like a separate branch of the super-policy. The consequence of this behavior was that a session created using a different Access profile would be considered valid when presented to a different virtual that was using a different Access profile.

While this behavior is useful, it did seem to lack the flexibility to force a user to authenticate against each different Access profile.

The new behavior gives the policy writer that flexibility.

• Profile scope (which is the default) limits the validity of a session to virtual servers that have the same Access profile.
• Virtual server scope limits the validity of a session created to only the virtual server that created it.
• All Access profiles with global scope are allowed to share sessions with each other.

If you are protecting different domains with the same APM instance, this flexibility will allow those different domains to be properly protected as intended. A user would not be able to bypass security by presenting a session cookie obtained for one domain on a request to the other domain.

Since APM uses domain cookies for cookie based sessions, then using different profile scope with different Access profiles or specifying virtual server scope for different virtual servers over the same domain will not work out of the box. A workaround would be to use an iRule to modify the session cookie name when the policy completes with a name specific to the virtual name (if using virtual scope) or profile name (if using profile scope), and to rename it back when the cookie arrives back on the corresponding virtual or handled by the corresponding profile.

In the meantime, I have submitted an enhancement request to allow the session cookie name to be distinguishable according to the specified session scope. Thank you very much for the suggestion!