For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

APM Sharepoint authentication

Problem this snippet solves: Updated version to support Webdav with windows explorer after Nicolas's comment. APM is a great authentication service but it does it only with forms. The default be...
Published Apr 20, 2016
Version 1.0
BIG-IP Access Policy Manager (APM)
editing office documents
iRules
ms-ofba
programmability contest
security
sharepoint
Kai_Wilke's avatar
Kai_Wilke
Icon for MVP rankMVP
Sep 20, 2016

Hi Stanislas,

Line 11-13: Personally I would make the setting independent of the APM profile configuration. This would allow to distinct between regular browser and MSOFBA clients (not restricted) and clientless access (Single-IP restricted). Furthermore I would recoment to always use the Single-IP mode for clientless access to reduce the security risks associated with the 

[ACCESS::user getsid $user_key]
syntax.

Line 51: Okay, I got the intention behind. Maybe you should issue a 

if { [catch {HTTP::payload replace 0 0 {}}] } then { return }
at the beginning of the 
HTTP_REQUEST
/
HTTP_RESPONSE
events to cover every write access on already responded HTTP requests/responses.

Line 135-137: Also tested on TMOS v12.0 and it has worked like a charm for me.

Additional Note: I've identified a problem within the MSOFBA authentication. If the APM session of an MSOFBA client is removed (e.g. session timeout) the MSOFBA client will not be able to re-authenticate using MSOFBA a second time. Only a fresh persistent cookie will allow him to save pending document changes, which is unfortunately not very intuitive for the end user. I've already developed a mechanism to restore/create a minimalistic APM session on-the-fly based on selected session meta-data (e.g. Username, Language-Settings, SSO settings) utilizing an AES encrypted 

MRHSession_R
session cookie. The code already works like a charm and allows me to deploy strict APM Policy session inactivity timeouts (e.g. 900 seconds), while providing a solid backdoor for long-living MSOFBA client sessions (e.g. 1-2 day(s)) without wasting any APM concurrent user CALs. Will perform additional tests and then post my latest iRule for you...

Cheers, Kai