IT tutorials
 
Applications Server
 

Microsoft Sharepoint 2013 Authentication (part 1) - Legacy Approach—Classic Mode Authentication

12/23/2014 8:02:24 PM
- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

SharePoint 2013 now uses Claims-Based-Authentication (CBA) for all web applications added to the farm. Using standard protocols and principles, SharePoint abstracts user authentication from user identity such that SharePoint can maintain his or her identity, regardless of the authentication mechanism.

The impact of abstracted authentication is that a user can now maintain his or her identity in a SharePoint site regardless of how the user authenticated on a given day. For example, in my SharePoint 2013 installation, my user presence goes by that of a common claim—my e-mail address—but I can authenticate via NTLM Windows credentials, SQL credentials (via a membership provider), or some other trusted domain type (via custom claims provider). As long as each authentication mechanism makes the claim that I have common claim identifier (dependent on the issuing provider type) my identity remains consistent.

Before I delve deeper into how SharePoint 2013 implements CBA principles, let me first remind you of the legacy approach—Classic Mode Authentication (CMA), which was available to you as of SharePoint 2010.

Legacy Approach—Classic Mode Authentication

I promise I shall keep this section short and not dwell too much on this legacy implementation of authentication. However, it is important to have some background knowledge on Classic Mode Authentication so you understand why CBA is so much better and why SharePoint 2013 no longer supports CMA.

Prior to SharePoint 2010, Classic Mode Authentication was the only mechanism of authenticating users. SharePoint 2007 at least included support for custom membership credentials such that we could store user credentials in SQL databases or third-party systems. Even so, authentication was still the job of SharePoint.

Let us consider a common scenario, implemented for many SharePoint 2007 solutions. Users can authenticate with their Active Directory credentials: when in the office they access the company intranet using their workstation credentials and when at home they access the intranet via a forms-based login. In both cases, the username and password is the same, just the authentication mechanism differs. In the office, users authenticate using NTLM—standard Windows challenge response protocol synonymous with workstation login. When accessing the Internet from home, users enter their credentials into an SSL-hosted form, and SharePoint authenticates these users against Active Directory using a Microsoft Membership Provider component.

Everything seems peachy, but there are a couple of major drawbacks with this implementation:

  1. SharePoint 2007 allows only one authentication mechanism per web application (a restriction because SharePoint builds on ASP.NET). Therefore, the implementation consists of a primary web application, using NTLM, and an extended web application, configured for forms authentication.
  2. The identity of the user ties to the username of the user—if accessing the site from the office the user has the username DOMAIN\username, whereas accessing the intranet via forms gives a username of Membership-Provider:username.

Perhaps we can overcome the first issue, although it does mean accessing the intranet from a URL in the office different from that outside the office because each SharePoint application requires a unique domain name or port number. I have seen some clever DNS tricks to redirect users to a different domain based on location in the network. This aside, bookmarks become a problem with different URLs because the links you saved in the office differ from those used when accessing the same document or pages at home.

The second issue is more of a deal-breaker—consider how identity mapped to username and authentication method affects services like User Profile Import. User Profile Import maps users with a given username to records in a directory, such as Active Directory or an LDAP system. If we have multiple usernames then the profile import has no way of knowing that each username is that of the same person: we effectively have multiple identities and thus multiple profiles. The problem also surfaces when tracking version history and changes to a document, since this also assumes unique username.

Fortunately for us, SharePoint 2010 introduced Claims-Based-Authentication, and made the world a better place. SharePoint 2010 still supported CMA and we had a choice when provisioning a new web application of which mode of authentication to use. With the release of SharePoint 2013, Microsoft depreciated CMA, and CBA is now the only mechanism for authentication.

Claims-Based-Authentication Approach

Claims-Based-Authentication is a new flexible and abstract approach to user authentication. CBA supports a variety of credential systems, including Active Directory, Live ID, LDAP directories, and any credential store that adopts CBA and federated authentication standards (via SAML).

CBA is composed of a number of components. These components operate in unison to authenticate users per the following high-level process:

  1. A non-authenticated user (anonymous user) attempts to access secured content in SharePoint.
  2. SharePoint determines available identity providers—CBA supports Windows (NTLM), Membership Provider, and Trusted Claims Provider types. If the application allows for multiple providers, then SharePoint presents the user with a choice to select the desired provider, otherwise SharePoint uses the only selected provider.
  3. For Windows and Membership authentication, SharePoint forwards the request to the Secure Token Service, which integrates with SharePoint 2013 on the same server. The request to STS uses the industry standard web service protocol WS-Trust. Requests destined to trusted providers route to the STS of each provider.
  4. STS looks up the username in a credential store and verifies the given password with that in the store. In the case of Windows NTLM or Membership Provider, SharePoint uses the built-in STS; in the case of Trusted Claims Provider, the STS might exist elsewhere.
  5. If successfully authenticated, the STS returns a SAML token, containing claims about the user’s identity. In the case of built-in STS, the claims returned are limited to details provided by the directory or membership provider.

SharePoint CBA uses the Windows Identity Foundation (WIF), a collection of APIs that provides for creation of claims-aware applications and federated identity.

With the theory part of CBA covered, I will now run through a series of steps for creating a new CBA web application and configuring it for multiple authentication types.

 
Others
 
- Microsoft Sharepoint 2013 : Claims-Based and Federated Authentication - Digital Identity
- Exchange Server 2013 Management and Maintenance Practices (part 7) - Weekly Maintenance, Monthly Maintenance, Quarterly Maintenance
- Exchange Server 2013 Management and Maintenance Practices (part 6) - Prioritizing and Scheduling Maintenance Best Practices
- Exchange Server 2013 Management and Maintenance Practices (part 5) - Message Tracking
- Exchange Server 2013 Management and Maintenance Practices (part 4) - SMTP Logging
- Exchange Server 2013 Management and Maintenance Practices (part 3) - Auditing the Environment
- Exchange Server 2013 Management and Maintenance Practices (part 2) - Remote Connectivity Analyzer
- Exchange Server 2013 Management and Maintenance Practices (part 1) - Maintenance Tools for Exchange Server 2013
- Microsoft Sharepoint 2013 : Administering Sharepoint with Windows Powershell - Basic PowerShell Usage (part 3) - Controlling Output
- Microsoft Sharepoint 2013 : Administering Sharepoint with Windows Powershell - Basic PowerShell Usage (part 2) - PowerShell Help , PowerShell Variables
 
Youtube channel
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
 
Popular tags
 
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS