Showing posts with label sessions. Show all posts
Showing posts with label sessions. Show all posts

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; if  there is no FedAuth cookie for the users, it shall redirect the user to login via the IdP (AAD/SiteMinder/ADFS et al.). 
  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).  The 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 behaviour of SharePoint is to store the FEDAUTH cookie on the user’s disk, with a 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 set up 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 the FedAuth shall persist when IE is close.  However, by keeping the session lifespan/FedAuth lifetime relatively short, the  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.

Updated 11 Feb 2019: rtFA cookie
"The root Federation Authentication (rtFA) cookie is used across all of SharePoint Online and the rtFA cookie is used to authenticate the user silently without a prompt.  So when moving from OneDrive to SPO or Admin sites, the user does not get additional prompts for login.  When a user signs out of SharePoint Online, the rtFA cookie is deleted."

References:
SharePoint Authentication and Session Management
https://msdn.microsoft.com/en-us/library/hh446526.aspx
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
 NB!  http://blog.robgarrett.com/2013/05/06/sharepoint-authentication-and-session-management/
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).

Thursday 16 October 2014

Cross Cutting Concerns for SharePoint 2013

Overview:  Last week I was speaking to a smart chap and he dropped the term Cross Cutting Concern as we were discussing SharePoint Host Apps (SPHA) and JavaScript.

Problem:  When creating apps for SharePoint 2013 multiple solutions need to address cross cutting concerns.  In the past I deployed a SharePoint library with caching, logging, lazy loading and various other "Cross Cutting Concerns", now for Provider Host Apps (PHA), SPHA and JS embedded within pages and Single Page Apps (SPA) we need frameworks for clients to address common components.

Hypothesis:
Caching for Client Side Code: In JavaScript you can either cache using the client cookie which is small or in HTML 5 based browsers use the JavaScript local store. 
Caching on the Server: All the normal Caching of C# or Azure are available.  Also look at Redis.

References:
http://en.wikipedia.org/wiki/Cross-cutting_concern
Update 27/01/2015:
http://channel9.msdn.com/blogs/OfficeDevPnP/SharePoint-Apps-and-client-side-caching