Forum Discussion

johnd_45683's avatar
johnd_45683
Icon for Nimbostratus rankNimbostratus
Jun 06, 2014
Solved

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.

     

7 Replies

  • How 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_45683's avatar
      johnd_45683
      Icon for Nimbostratus rankNimbostratus
      I 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_Koyfma1's avatar
      Michael_Koyfma1
      Icon for Cirrus rankCirrus
      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.
  • 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_45683's avatar
      johnd_45683
      Icon for Nimbostratus rankNimbostratus
      I 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_Koyfman's avatar
      Michael_Koyfman
      Icon for Cirrocumulus rankCirrocumulus
      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.