APM Sharepoint authentication

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