Authetication in SharePoint 2010

Classic:

In SharePoint the classic authentication, all is managed by AD. AD authenticates user in classic mode.

Active Directory authenticates a user, provides an NT Token. The token is used to authenticate to SharePoint. SharePoint consumes that token and it's converted into a SPUser object for authorization.

Kerberos Authentication:

Kerberos V5 authentication protocol provides a mechanism for authentication – and mutual authentication. – between a client and a server or between one server to another server.

Windows server 2003 implements the Kerberos V4 protocol as a security Support Provider(SSP), which can be accessed through the security support provider interface(SSPI). The Kerberos key distribution center(KDC) uses the domain’s AD directory service database as its security account database. AD is required for default NTLM and Kerberos implementations.

The Kerberos V5 protocol assumes that the initial transactions between client and server take place on an open network in which the packet is transmitted on a network which can be monitored and modified. This is very much like today’s Internet, where an attacker can easily pose either a client or a server, and can easily tamper the communication between client and server.

The Kerberos protocol is a more secure protocol that supports ticketing authentication. If user’s request contains valid user credentials and a valid Service Principal Name (SPN), then A Kerberos authentication server grants a ticket in response to a client computer authentication request. The client computer then uses the ticket to access network resources. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). The KDC distributes shared secret keys to enable encryption. The client and server computers must also be able to access Active Directory directory services. For Active Directory, the forest root domain is the center of Kerberos authentication referrals

Pros:

• Most secure Integrated Windows authentication protocol
• Allows delegation of client credentials
• Supports mutual authentication of clients and servers
• Produces less traffic to domain controllers
• Open protocol supported by many platforms and vendors

Cons:

• Requires additional configuration of infrastructure and environment to function correctly
• Requires clients have connectivity to the KDC (Active Directory domain controller in Windows environments) over TCP/UDP port 88 (Kerberos), and TCP/UDP port 464 (Kerberos Change Password – Windows)

Claims Based Authentication:

It is based on .net.

STS:

STS is built on Geneva framework which is now called Windows Identity Foundation. The STS (Security Token Service) core responsibility is issuing, managing, and validating security tokens. An STS resides on both an identity provider and SharePoint. STS is built on top of the shared services framework which is why it's listed as a service application within Central Administrator\Manage Service Applications page.

After a trust is established between SharePoint and an Identity provider, web applications can be set with Claims authentication type instead of classic. If a client attempts to authenticate to a claims aware web application, SharePoint redirects a client to the associated trusted identity provider. The identity provider authenticates clients and provides a security token. That token could be either of the following:

· NT Token

· SAML Token

This security token is then passed to SharePoint STS. In short, the STS will validate the token "Claims Based Identity" and generate a new security "SAML" token back to the client. This token is generated by SharePoint and for SharePoint. The client sends this SAML token to SharePoint to prove that he/she is officially authenticated. SharePoint validates and authenticates user and a SPUser object is created and is used for authorization.

1. Client hit SharePoint site via HTTP (Get)
2. SharePoint redirects client to Identity Provider in order to get a security token
3. Client attempts to authenticate to trusted Identity Provider
4. The identity provider's (Security Token Service) will validate the username and password and provide a security token to a client.

Note: A security token could be a Windows NT Token, SAML token, or FBA token

5. The client has a security token (authenticated) and submits it to SharePoint STS "Security Token Service"
6. SharePoint STS receives security token from client and determines if we trust the issuer of that token "Identity Provider"
7. STS then performs claims augmentation
8. STS issues client new SAML token
9. Client request resource "site" with new SAML token
10. SharePoint consumes SAML token, "validates authentication successful", and builds an SPUser object in order to authorize to the secured resource

FBA:

FBA users no longer uses an ASP.Net identity. FBA is now claims aware and the SharePoint STS facilitates the authentication process. Once user is authenticated, the SharePoint STS provides a SAML token to the client.

Note: When creating a web application designated for FBA, you must specify claims authentication type.

STS (federated equivalent of a domain controller) "issues tokens"

Basic FBA Sign-in process:

1. User signs in via FBA with credentials

2. SharePoint STS calls membership provider to authenticate

3. SharePoint STS calls role provider to get all the roles for the user

4. Post successful authentication, a SAML token is generated by the SharePoint STS and passed back to the user

5. The user then authenticates to SharePoint with SAML token and authentication is officially completed

It needs to make changes in the web.config files of that web application.

Supported authentication methods:

Method category	Authentication methods
Windows authentication	NTLM
	Kerberos
	Anonymous
	Basic
	Digest
Forms-based authentication	Lightweight Directory Access Protocol (LDAP)
	Microsoft SQL Server database or other database
	Custom or third-party membership and role providers
SAML token-based authentication (new with SharePoint Server 2010)	Active Directory Federation Services (AD FS) 2.0
	Third-party identity provider
	Lightweight Directory Access Protocol (LDAP)

To configure a Windows Authentication application to use Forms Based Authentication then you can convert from Classic Mode to Claims Based. But, there is no UI exist for doing this conversion. The only way around is through PowerShell.

IMPORTANT:  If an application is created using Claims Based Authentication and if you want to convert to Classic Mode then it is not possible either through the UI or through PowerShell.

How Claims works with Services

Accessing Internal Services

Within a Single Farm:

The classic example is a user performing a search. The WFE's (Server1) search web part talks to service application proxy. The associated search service application proxy calls the local STS to get a SAML token for the user. Once SAML token is collected, the search service application proxy then calls a server running the Query Processor via WCF call. I'll call this server, "Server 2". Server 2 receives the incoming request and validates the SAML token against its local STS. Once validated, Server 2 connects to various components to gather, merge, and security trims search results. Server 2 sends the trimmed search results back to Server 1 which is then presented to the user.

Accessing External Services

SharePoint 2010 STS can manipulate a SAML token in order to present it to an external web service. The way it presents the identity depends on the type of external web service. The goal is preventing the additional prompt for credentials so that a full Single Sign-On (SSO) experience is possible. The STS is comprised of the WIF "Windows Identity Framework" and also the C2WTS. Each component is used dependent upon the type of external service accessed.