Forum Discussion

Martijn_65080's avatar
Jun 27, 2013

Enable APM on SharePoint Subsite Only

Hi All,

 

I am trying to selctively enable APM policy processing on a SharePoint subsite. Basically what I want to do is authentication and OTP enforcement on a subsite of SharePoint. I created the follwing Irule, which seems to work for the initial spawning of the F5 Logon page. After log on I get a page can not be displayed. After removing the Irule I am able to logon and get the OTP working but....

 

I only want the OTP and authentication offload for a specific subsite. Removing the Irule makes all traffic go via APM. I created a Landing URI selection in the policy in which I only route traffic for the specific URI through a macro that does the authentication and OTP part. All other traffic not destined for the specific URI is allowed to go throug directly via an Allow ending.

 

The problem is that users can go to the Top Level site first and do a direct logon to SharePoint there. APM treats this traffic as allowed because of my allowed ending and sets the APM cookies. When users go to the specific subsite in the same browser session they will not be asked to enter their credentials and OTP because APM detects the cookie that was set when the user browsed the top level site. I can't block or ask OTP access to the toplevel site and all other subsites because of the nature of the sites running on that farm. I tried the follwing Irule;

 

when HTTP_REQUEST {

 

Check the requested HTTP path

 

switch -glob [string tolower [HTTP::path]] {

 

"/myuri*" {

 

Enable APM for this path

 

ACCESS::enable

 

}

 

default {

 

Disable APM all others

 

ACCESS::disable

 

}

 

}

 

}

 

 

Hopefully you all have a better and functioning way to get this right...

 

Kind regards,

 

Martijn

 

 

5 Replies

  • Hi Martijn, Could you add a check for a current session and if exists perform a "ACCESS::session remove" statement before the "ACCESS::enable" to remove the session information for that connection? The thought would be that it would kill the previous session and force you to login in again... it might be better to create a custom session variable and check that so it doesn't keep prompting you as you navigate and the irule triggers on the URI.
  • Try this:

    when HTTP_REQUEST {
        if { not ( [HTTP::uri] starts_with "/myuri" ) and not ( [HTTP::cookie exists MRHSession] ) } {
            ACCESS::disable
        } 
    }
    
  • I Finally came up with this.

     

    when HTTP_REQUEST { if { [string tolower [HTTP::path]] contains "/myury" and[ACCESS::session data get "session.logon.last.username"] eq "" and [HTTP::cookie "MRHSession"] ne ""} { Some 200 respons and hangup of session via hidden frame /vdesk/hangup.php3}

     

    Not the cleanest way of doing things but it works. Strange thing is that ACCESS:disable seems to throw "page cannot be displayed" errors when users do not browse myuri.

     

    ACCESS::session remove kills the session without notifying the end user.

     

    Many thanks for your replies guys.

     

    Martijn

     

    • Michael_Leonha1's avatar
      Michael_Leonha1
      Icon for Nimbostratus rankNimbostratus
      I thought I had the same problem, every time a uri contained /private/ I need to use APM to authenticate the user. Maybe my approach is flawed, but I created 2 irules and ordered them on the virtual server, the first irule was: when HTTP_REQUEST { ACCESS::disable} the second irule was: when HTTP_REQUEST { if { [string tolower [HTTP::path]] contains "/private/"} { ACCESS::enable}} So far things seem to be working like I want, but I am not sure what I am doing is technically the correct way or what the pitfalls of doing it that way are.
  • There really isn't an order to iRules. BIG-IP essentially compiles them into byte code and then reorganizes everything for consistency and performance. If there are two iRules applied to a VIP with the same event, then those events are combined into one. It could look like this:

     

    HTTP_REQUEST { 
        ACCESS::disable
        if { [string tolower [HTTP::path]] contains "/private/"} { 
            ACCESS::enable
        }
    }

    Or just as easily look like this:

     

    HTTP_REQUEST { 
        if { [string tolower [HTTP::path]] contains "/private/"} { 
            ACCESS::enable
        }
        ACCESS::disable
    }    

    It is, perhaps by fortune, that the commands in these events are executing in the desired order. The priority command allows you to explicitly order events. With a baseline of 500, lower numbers are higher priority. Example:

     

    when HTTP_REQUEST priority 100 {
        ...
    }