Forum Discussion
APM Policies not enforced after initial login
We are working on implementing per path access restrictions with the BigIP/APM. The restrictions are grouped into the following categories:
1) Public - no login required 2) Restricted - login required 3) Secured - login and LDAP user attribute value required
Public paths are enforced by an iRule that disables the APM for selected paths. Secured paths are enforced by Branch Rules on LDAP Query Actions in an APM Access Policy.
The problem we have encountered is that the APM is not called after the user logs in and has their session cookie. As a result, the secure path restrictions in the Access Policy are bypassed. Is this normal? Do we need to use iRules to enforce per path restrictions? Does anyone have examples of this?
Yes, this is normal. Today, once the session is established, the access policy is not evaluated for the duration of the session. So, if you started a session for Restricted URIs and then need to enforce security for the Secured ones, you need to do
set an session variable in the VPE indicating whether user performed secured or restricted authentication an iRule that will check the paths for secured - if path is secured, it will check the APM session variable to see how the user authenticated - if they authenticated just for Restricted, kill the APM session and redirect them to the same path they tried to go to(secured) - and the policy execution should kick in and force you to do proper authentication then.
- blwavg_10621NimbostratusHow are the different paths identified? Also APM is used for user authentication. You have the user go through the flow and the endpoint should provide access to the resource. Are you trying to use APM as a "container" for users?
Yes, this is normal. Today, once the session is established, the access policy is not evaluated for the duration of the session. So, if you started a session for Restricted URIs and then need to enforce security for the Secured ones, you need to do
set an session variable in the VPE indicating whether user performed secured or restricted authentication an iRule that will check the paths for secured - if path is secured, it will check the APM session variable to see how the user authenticated - if they authenticated just for Restricted, kill the APM session and redirect them to the same path they tried to go to(secured) - and the policy execution should kick in and force you to do proper authentication then.
- johnd_45683NimbostratusI won't be able to force re-authentications like that... I am envisioning creating an iRule that will check for attr values on each request. Are the LDAP Query results available in the LTM iRules as long as the session is open? My biggest concern about this model is that it can potentially create a mess with hard to detect holes. It will also create large iRules. We have some apps that will require dozens of rules and there are dozens of apps. Is there a possibility of running into CPU problems on the BigIP when processing a lot of iRules?
- John, Actually, I have to take it back - I misread the original requirements and for some reason thought you needed step-up authentication here. It sounds like all you want is to allow access to certain URIs based upon LDAP attribute value. You can easily achieve that by doing LDAP query in the VPE and then creating and assigning L7 ACLs to the policy as appropriate. I would suggest an approach of assigning a DENY ACL for the secured URI paths to all the users and then branching out from the LDAP Query and not assigning any ACLs to the users that contain proper LDAP attribute, which means they'll have full access.
- Michael_KoyfmanCirrocumulus
Yes, this is normal. Today, once the session is established, the access policy is not evaluated for the duration of the session. So, if you started a session for Restricted URIs and then need to enforce security for the Secured ones, you need to do
set an session variable in the VPE indicating whether user performed secured or restricted authentication an iRule that will check the paths for secured - if path is secured, it will check the APM session variable to see how the user authenticated - if they authenticated just for Restricted, kill the APM session and redirect them to the same path they tried to go to(secured) - and the policy execution should kick in and force you to do proper authentication then.
- johnd_45683NimbostratusI won't be able to force re-authentications like that... I am envisioning creating an iRule that will check for attr values on each request. Are the LDAP Query results available in the LTM iRules as long as the session is open? My biggest concern about this model is that it can potentially create a mess with hard to detect holes. It will also create large iRules. We have some apps that will require dozens of rules and there are dozens of apps. Is there a possibility of running into CPU problems on the BigIP when processing a lot of iRules?
- Michael_KoyfmanCirrocumulusJohn, Actually, I have to take it back - I misread the original requirements and for some reason thought you needed step-up authentication here. It sounds like all you want is to allow access to certain URIs based upon LDAP attribute value. You can easily achieve that by doing LDAP query in the VPE and then creating and assigning L7 ACLs to the policy as appropriate. I would suggest an approach of assigning a DENY ACL for the secured URI paths to all the users and then branching out from the LDAP Query and not assigning any ACLs to the users that contain proper LDAP attribute, which means they'll have full access.
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