Thursday, 20 August 2015

Non Functional Testing for SharePoint

Work in Progess...

Overview:  Functional Requirements are the business requirements that the business define for the application being built.  Non-functional testing is concerned with performance, reliability, scalability, recovery, load,  security and usability testing.  For SharePoint it is a good idea to test this at a platform level and then verify the individual application non functional testing is appropriate.

A nice diagram explaining the various testing caucus's (Source Guru 99):

SharePoint Non Functional Testing:
All of these test should be performed against your various SharePoint platforms and will dictate the SLA's offered to the business using SharePoint as a service.  Baseline testing is a good idea as the differences can be used to determine the efficiency of the individual application being created.

Fiddler is my favorite (other tools for capturing web traffic Charles, BurpSuite, WireShark and you can use the developer tools shipped with the browsers).
Use Fiddler to:

  • Observe traffic (http/https requests, headers,..)
  • Replay sessions, 
  • Evaluate performance,
  • Set break point


Sunday, 16 August 2015

FedAuth Notes for Problem Solving

Overview:  These are my notes on FedAuth relating to SharePoint 2013.
SharePoint (SP) 2013 uses Claim Based Authentication (CBA).  In this example I am looking at SiteMinder (a CA product) as the Federation Service (this is the equivalent to ADFS (Active Directory Federation Service) as the Identity Provider (IdP)). 
Basic Flow of SP CBA Authentication:
  1. SP looks for a FedAuth cookie, it is does not have a FedAuth cookie for the users, it shall redirect the user to login via the IdP (SiteMinder/ADFS). 
  2. The IdP returns a valid SAML token to SharePoint's STS.
  3. The STS generated a FEDAUTH cookie for the user to hold the current users session lifespan state (to keep the user log in).  User holds the STS token not the SAML token.  The FedAuth in is a pointer to the SAML token held in the SharePoint Token Cache.
The default behavior of SharePoint is to store the FEDAUTH cookie on the user’s disk, with fixed expiration date. The expiration of the FEDAUTH cooking can be for a fixed time or a sliding session (if the user interacts with SP, the SP session is extended).  FedAuth can be stored on the Disk (default or in memory (not persisted between browser close downs). 

Note:  Changing where the cookie is stored affects the way the user shall login and effects Office application login such as Word.  Test thoroughly before changing)

Note:  Watch the IdP providers expiration policy vs what you setup in SP.  As an example, you could remove a user from the IdP, however the session is still persisted and the user can still interact with SharePoint.   From MSDN "Make sure that the value of the LogonTokenCacheExpirationWindow property is always less than the SAML token lifetime; otherwise, you'll see a loop whenever a user tries to access your SharePoint web application and keeps being redirected back to the token issuer." 

Note: Closing a browser window with the FEDAuth stored to Disk does not invalidate the SharePoint session.  So it shall persist closing down IE however, by session the FedAuth Lifetime to be relatively short (think less than an hour) your security is better.
Note: Change from FedAuth to session based sessions should taken lightly, Office products need to be thoroughly tested and generally won't work seamlessly.

SharePoint Authentication and Session Management
Remote Authentication for SharePoint Online (RTFA)
Why IE and Office work together in SP
Adding, removing SP claims and managing security using claims  and NB! also
Logout of SharePoint
Check Cookie TimeOut; set by formula:
FedAuth LifeTime = IdP endpoint SAML token lifetime Duration - STS LogonTokenCacheExpirationWindow

Update 04 Feb 2016: screenshot for clarity:

My blog post on changing from FedAuth to session based cookies.  The post also shows how to examine the cookies for Internet Explorer (IE).

Sunday, 9 August 2015

Request Management

I hate Request Management (RM) and I believe it is going away in SP 2016.

Issue I have seen with RM enabled:
  • Tenant Admin API can't provision Site Collections (point to the WFE's and it works)
  • Workflow sometimes don't start
  • Removing RM improved performance on an Extranet
  • Distributed Cache - One client had Distributed Cache intermittent issues.  User had to re-authenticate using STS.  As the RM was hit 1st and using distributed cache and then picking 1 of several WFE's, the issue was twice as likely to occur.  Used the NLB to direct traffic to the WFE's and the number of re-auths halved.