Forum Discussion
amolari
Cirrostratus
Cirrostratusv12 APM, Profile scope
Hi
new feature in v12, the possibility to define the Access Policy Profile scope (Profile / VS / global).
Default is "profile" and is the same behaviour as in pre-12 releases. Anyone has played around with the VS+global scopes and could eventually provide concrete examples of how it does affect the behaviour?
Unfortunately, this feature is still poorly documented.
From v12 Release Notes: "From Session scope enhancement for increased security
In this release, Profile Scope, a new setting in the access profile, establishes additional criteria to ensure that a user who has established a session on one virtual server cannot use that same session to access other virtual servers and the resources behind them."
In the documentation, I've found :
From the Profile Scope list, retain the default value or select another.
- Profile: Gives a user access only to resources that are behind the same access profile. This is the default value.
- Virtual Server: Gives a user access only to resources that are behind the same virtual server.
- Global: Gives a user access to resources behind any access profile that has global scope."
But the use cases are not clear to me
Thanks
Alex
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!
Arnaud_LemaireEmployee
Hello Alex,
it means that with this feature you can share or not an active session between different profile/virtual server.
for virtual : you limit the session information to the virtual server, so if you have the same apm policy on two virtual servers (same config bu different services, imagine a reverse proxy deployement with two web applications) if the user is logged on apm on VS1, when he connect to VS2 his session is not known so he as to log again and go through the policy as it was a different equipment hosting it.
for policy : take the same usecase but this time, the user logged on VS1 is automatically known from VS2 sharing the same policy. So no need to relog and go through the policy again.
for global you go through a policy the first time you connect to a service and then you can access any virtual whatever the policy on it.
