SharePoint Security And Authentication Part 1 – Understanding Authentication In SharePoint 2010

There are numerous authentication methods that are supported by SharePoint Server 2010. Through authentication the identity of a user can be validated. Once that occurs the process of authorization will also determine which sites, what types of content, and which of the features available a given user has authority to access. SharePoint Server 2010 can be considered a type of distributed application. There are three tiers that it is divided into which are all important to consider when determining your authentication strategy:

  • Application server
  • Back end database
  • Front end web server

Each of these tiers offers a sub-system and corresponding authentication. A user has to be authorized before they can go from one tier to the next. The provider has control over what levels of access each user has. Those providers offer various software elements that are used to support a specific method of authentication. With SharePoint 2010 you can use a classic mode of authentication or a claims based method. If you are upgrading from Microsoft Office SharePoint Server 2007 Microsoft documentation will recommended you use the classic mode, personally I think it's advisable to just go claims since you can use the identity generation service to generate Windows identities. If you plan to use a forms based authentication or one that is SAML token based you should use the claims based method. This is because the classic mode authentication will only support Windows authentication.

There are several methods of authentication that can be supported by SharePoint Server 2010. As you explore the basics of them you can decide what will work best for your organization. There are three:


This is the standard method of authentication. There are many methods that fall into this particular category. They include:

  • Anonymous This allows users to find and access resources from public areas of websites. They don’t have to provide any credentials for authentication to do so.
  • Basic This requires a user to have account credentials that have been assigned ala Windows. There is a web browser that is enabled to provide such credentials when someone makes a request. The credentials of users aren’t encrypted but sent across the network as clear-text. Therefore it isn’t recommended for the use of basic authentication to be used on any connection that isn’t secure. Always use SSL encrypting for additional security.
  • Digest This type of authentication is very similar in function to basic authentication. However, it offers a much higher level of security with it. The credentials are encrypted as they are sent across a network. The username and password can’t be deciphered along the way. Valid credentials must be given by a user that belong to the secret password string.
  • Certificates This offers an exchange of the public key certifications. The use of SSL encryption is used. These certificates are issued by a Certificate Authority. They have to fit the Public Key Infrastructure. This can be done by selecting Windows authentication in the Central Administration area. Once SSL is enabled then the configured certification can be obtained from Certificate Authority.
  • NTLM This is a requirement for any network that receives requests for authentication from client computers which don’t support Kerberos authentication. NTLM is secure and it allows for credentials of users to be encrypted before they are transmitted. Windows NT Server, Windows 2003 Server WorkGroup, and Active Directory use NTLM authentication. It may be the default and need to be disabled if you don’t want to use it.
  • Negotiate With negotiate authentication for either NTLM or Kerberos, they client has to choose one of them. The default is Kerberos. The client application has to provide a Service Principal Name and a User Principal Name for the account. When such information can’t be offered then NTLM has to be used for authentication.

Forms Based

This type of authentication offers support for management systems that need to make identifications. They aren’t based on Windows because they make it possible to work with identity management systems. These use the MembershipProvider interface. This includes:

  • Custom membership providers
  • Lightweight Directory Access Protocol
  • SQL Database

This based on ASP.NET as well as role provider authentication. With SharePoint 2010 it is only able to be used when claims based authentication is used. Forms Based Authentication can be used to be able to authenticate other user accounts too when connected to Microsoft SQL Server database. You need to register the membership provider in the Web.config file in order to use this type of authentication.

SAML Token Based

This type of authentication is claims based. It is created to support a Windows Identity Foundation. This is a set of .NET framework entities used for the implementation of claims based identity. They include:

  • 3rd Party identity providers
  • Active Directory Federation Services 2.0
  • Windows Live ID

Next, we are going to be talking about user management in this SharePoint security series.


Industry Standards for SharePoint Claims Based Authentication Cheat Sheet

Here is some quick reference material when reading through the claims stuff on the site to help with some of the terminology.

SAML Security Assertion Markup Language

The SAML is an XML based standard and it allows for the exchanges between authorizing and authenticating data that is sent from an issuer to an application. There are several functions of the SAML but the main one is to offer a way for the web browser to be used with a one time sign on process. This is acceptable because the SAML sees that the user has an identity in place and it can be authenticated.

Yet the SAML won’t be able to specifically tell you how to go about implementing these types of services. It really isn’t concerned at all about how the authentication process is implemented. Of course that isn’t the case when you are talking about the individual applications involved. Any application is going to rely on the issuer to successfully identify who the user is.

Once the user requests it, the SAML will apply the policies and rules that are in place. A decision will be made once everything has been assessed.


The purpose of the WS-Federation is to extend the WS-Trust so that the structure of the identity can be created at the core. It is also there to help separate the trust from the security for the tokens. This means that a given service model can be offered to provide security to the protocol address for the web applications and web services regardless of the types of trust relationships you are talking about.

These features are offered for direct use to the clients of SOAP and web services. The WS-Federation is where the syntax for the WS-Trust protocol and the WS-Federation extensions take place in the browser use environment.

There is also the WS-Federation Passive Requestor Profile that is a web based service that works directly with the WS Federation. The details of it show how applications are able to make requests. This includes the use of web browsers which are often referred to as passive due to the way in which they go about making such a request.


WS-Security offers a method of communication so that the security can be successfully put into motion. It was originally designed through the joint efforts of VeriSign, IBM, and Microsoft. Today there is a committee called the Oasis Open that oversees it. This protocol is very important as it helps to get the rules followed for the confidentiality to be enforced. This includes the use of the SAML, X 509, and Kerberos.

This also is attached to signatures so that they can be encrypted with headers that are SOAP messages. To attach security tokens and certifications to messages the WS-Security has to be in place. It works in all of the layers of the application too so that there is security in place from start to finish for each of them.


The WS-Trust is actually an extension of the WS-Security. However, the specific areas that it covers include the issuing, renewing, and then validation process of the tokens for security. It also allows for the various trust relationships to be securely exchanged through messaging. Using the WS-Trust, applications are able to secure that effective communication is in place.


SharePoint Claims Based Authentication – The Basics of Claims – Part 1 – Introduction

We are going to discuss the various concepts that have to do with claims including federated identity. If they are new terms to you don’t worry because we are going to cover the ins and outs of them. They have both been around for quite some time and the mechanics of them are involved with claims based approaches. If you have heard of Kerberos before, this is a very similar concept. Kerberos is well known as an authentication protocol and it is used by Active Directory.

Both WS-Federation and the  SAML (Security Assertion Markup Language) are federation protocols that have been used for years. They are actually part of various systems out there that are used in all of the major platforms a business may have access to today. The idea of claims based identity isn’t new as it has been around for almost 10 years now.

I’m calling this one my “Basics Of Claims” series.

I got some more claims based stuff coming out soon too!