When working in a highly secure environment, you may have to deal with the requirement of allowing only one active logon session. This basically means each end user is not allowed to have multiple logon session. Another logon is denied until end users sign out to terminate the session. The native Windows NTLM is challenge-response authentication method which does not control logon session.
To achieve the requirement, Forms-based authentication is required to work against Active Directory. The reason is that we need to build a custom dictionary whose key is the username passed by session object. In order to well manipulate the session and construct the dictionary, a custom login and logout form is necessary since Windows authentication cannot achieve that. This approach needs to come along with ASP.NET Session State. This one is fully supported in SharePoint 2010 and 2013. Each user after successfully logged in, will have a unique session ID automatically created. This session ID is stored to a custom dictionary or a custom database in SQL Server. There is also a database or cache storing user information with login status (e.g IsOnline) flag. If the same account found with different session ID, deny the login with a custom message. The flow below would give you an idea:
If you work with FBA in SharePoint, you have been surely bear in mind the following considerations:
- Require FBA knowledge and management (almost via web.config file)
- Require web.config and securitytokenserviceapplication’s web.config file. If a SharePoint service needs to be provisioned, the parent SharePoint web service would automatically be provisioned. This would clear FBA configuration value in the securitytokenserviceapplication’s web.config file
- Require the customization of People Picker because it only performs username and email. Group search doesn’t support wildcard format.
- Require a custom crawl rule to crawl FBA-based enable web application.
- Require manually map and correct synced user profile.
For the session management specifically with FBA, there are some caveats
- Huge impact to SharePoint performance because there is always a session validation back to database. If the number of users is not high, performance shouldn’t be a problem.
- If user’s computer crashes before session expiration, chances are the user has to wait until the session is expired.
- Require additional configuration in browser and Logout functionality to clear session cookie
- Session Management in SharePoint might not be well supported with Windows Integrated Authentication.
- Different windows but the same browsers can use the same session cookie.