Search This Blog

Tuesday, October 14, 2014

Authentication methods that are supported by Microsoft SharePoint Server 2010.

I am planning to deploy Form Based Authentication for my Project Server 2010. So thought to start my search around SharePoint first as we all know that our Project Server can’t live without SharePoint and found this wonderful article to  share :)
Information below is just a glimpse from the article I found.
SharePoint Server 2010 provides a flexible and extensible authentication system, which supports authentication for identity management systems that are based or are not based on the Microsoft Windows operating system. By integrating with ASP .NET pluggable authentication, SharePoint Server 2010 supports a variety of authentication scenarios, including:
Using standard Windows authentication methods.
Using a simple database of user names and passwords.
Connecting directly to an organisation’s identity management system.
Using two or more methods of authentication for accessing partner applications (such as, connecting to your partner company’s identity management system for authenticating partner employees while using Windows authentication methods to authenticate your internal employees).
The following are the lists of authentication methods:
Claims: 
1-  Claims authentication for SharePoint Server 2010 is built on the Windows Identity Foundation, which is a set of .NET Framework classes that are used to implement claims-based identity.
Claims-based authentication: Token containing claims2- Claim is piece of information that describes given identity on some aspect. Take claim as name-value pair. Claims are held in authentication token that may have also signature so you can be sure that token is not tampered on its way from remote machine to your system. You can think of token as envelop that contains claims about user.
Token may contain different claims:
  • username or user ID in remote system,
  • full name of user,
  • e-mail address,
  • membership in security groups,
  • phone number,
  • color of eyes.
System can use claims to identify and describe given user from more than one aspect. This is something you don’t achieve easily with regular username-password based authentication mechanisms.

Claims-based authentication

Claims-based authentication is more general authentication mechanism that allows users to authenticate on external systems that provide asking system with claims about user. The next image from TechNet library page Authentication Patterns illustrates authentication flow simply and effectively.
Claims-based authentication
Here is authentication flow:
  1. User makes request to some application.
  2. System redirects user to authentication page of external system (it may also happen after system lets user to select external system where he or she wants to log in).
  3. After successful authentication external system redirects user back with some information.
  4. Application makes request to external system to validate user.
  5. If user is valid then user gets access to application.

Claims-based authentication in practice

Claims-based authentication can be found from many applications:
  • Microsoft SharePoint 2010 and 2013,
  • Windows Azure Access Control Services (ACS),
  • Active Directory Federation Services (ADFS),
  • Applications using Windows Identity Foundation (WIF).
This list is not complete, of course, and I am sure you can find more examples from web. About Windows Azure ACS you can read my posting ASP.NET MVC 3: Using AppFabric Access Control Service to authenticate users.

From user information to claims

Not all authentication mechanisms support claims. Take OAuth and Windows authentication as examples. So, how can claims-aware systems use these authentication methods and still provide claims? The answer is simple – we need adapters or proxies that can wrap user information to claims.
From user information to claims identity
This is simplified picture that is here to give you some idea about how user information from other systems is turned to claims. In the case of using adapter directly web application or some component is able to understand one or more authentication mechanisms and wrapping information to claims happens in web application. If you want to be close-to-metal-guy then I can scare you with one of my older blog posts Adding Twitter authentication support to ASP.NET application.
It is also possible to use identity “proxy”. In this case we have token service between our application and external system where user authenticates. This kind of token service is used by Windows Azure ACS. Token service of ACS knows details about different authentication mechanisms and provides your application with token service so your application receives always tokens with claims.

Wrapping up

Claims-based authentication is more general authentication system than old and unsecure username-password thing. Instead of saying yes or no about authentication attempt claims-based authentication is wider – external system can give out more information about user by creating claims and putting these into signed token. Although claims-based authentication is new thing it has been around for awhile and in Microsoft world it is trending up. Claims-based authentication is more complex by implementation but it also more secure than yesterday’s authentication mechanisms. Besides SharePoint it lately made its way also to ASP.NET web applications.

Windows:
 The standard IIS Windows authentication methods are supported.
Below are the following  types of windows authentication:
1.     Anonymous
2.     Basic
3.     Digest
4.     Certificates
5.     Kerberos (Integrated Windows)
6.     NTLM (Integrated Windows)

  • 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 authentication (FBA): 
SharePoint Server 2010 adds support for identity management systems that are not based on Windows by integrating with forms-based authentication. Forms-based authentication enables SharePoint Server 2010 to work with identity management systems that implement the MembershipProvider interface. You do not need to rewrite the security administration pages or manage shadow Active Directory directory service accounts.
Below are the following  types of FBA authentication:

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


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





I hope it’s not do different from Project Server 2007 FBA method..
Best of  luck for FBA on Project Server 2010



No comments:

Post a Comment