SharePoint security - Part 2: User authentication

For starters, SharePoint seems like something big and confusing. Meanwhile, SharePoint is a regular ASP.NET application running on IIS. This is certainly reflected in the security system, an important element of which is user authentication.

SharePoint authentication methods

Authentication is the process of verifying a user's identity. SharePoint supports 3 basic authentication methods:

Windows is the main and most common way. This authentication works in the same way as standard Windows network security mechanisms and is performed by a domain controller. This type of authentication is configured at the IIS level. There are four main implementations of this authentication:

Anonymous access - allows users to access sites without providing a username and password. By default, for anonymous access, the account is IUSR_ <computer_name>.
')
Basic HTTP authentication - with this authentication method, the server asks the user for a username and password that are transmitted over the network in an unencrypted form. It is an easy way to get information about a username and password, but provides little protection against unauthorized access, because Passwords are encoded in Base-64, which is easy to decode. This authentication method is supported by most browsers.
Digest HTTP authentication is similar to basic HTTP authentication, however passwords are sent over the network in an encrypted form. This authentication method is available only with Windows 2003 SP2.
Integrated Windows Authentication is one of the most secure authentication methods. When integrated authentication is enabled, the browser on the user's computer proves that the password is known through a cryptographic exchange with the web server using hashing. Integrated security is only available in Internet Explorer. IIS, and SharePoint, respectively, support two protocols for implementing integrated authentication:
- NTLM is a network authentication protocol developed by Microsoft for Windows NT. The protocol works on the principle of request-response, and the password is not sent to the server, but a hash created using the key returned by the server and user account information is sent. Next, the server checks the transferred hash locally and, accordingly, allows or does not allow access to the resource.
- Kerberos - offers a mechanism for mutual identification of the client and server before establishing a connection between them. It is based on the use of markers, tickets (tickets). When using this protocol, the client first sends the login and password to the authentication server. In response, the server returns an authentication token. Further, this token can be used when accessing resources on the network without the need to transfer account data (username / password) over the network and re-authenticate.
  
  The Kerberos protocol is more secure and faster than NTLM, but it requires additional configuration, often quite laborious and requiring detailed planning.

In more detail, the process of authenticating requests in IIS is described here: http://groff.habrahabr.ru/blog/78242/

ASP.NET form - in this case, it is not the windows user credentials that are used, but the credentials entered in the form and verified using the configured provider. This method is implemented using the functionality of ASP.NET and is built on the provider model. The provider model allows third-party systems and data warehouses to be used to authenticate and verify user credentials. By default, ASP.NET includes providers for LDAP and SQL. If necessary, custom providers can be developed.

Single Sign-On is a service that allows users to switch from one system to another without re-authentication. This saves the user from multiple data entry of his account in this transition. Often, systems or software products contain their own mechanism for verifying user credentials. The role of SSO is to translate user authority in one system to authority in another.

Many companies use specialized systems to store and verify user credentials other than Microsoft SSO. If such systems are planned to be used in conjunction with SharePoint, and at the same time it is necessary to refuse to store credentials in two places at once, there is an opportunity to create a custom SSO provider. SSO is available only in Microsoft Office SharePoint Server 2007 and is not available in WSS 3.0

What authentication method to choose?

It all depends on the situation. By default, when creating a new web application, NTLM authorization is proposed using the credentials of the user who is running the browser. In the case of closed-end intranet applications, this is usually sufficient. However, this behavior often does not meet specific requirements and requires additional configuration and selection of other authentication methods.

Anonymous authentication is used mainly in Internet scenarios, in which users should have free access to the SharePoint site. For such users, the site usually has read permissions. If we consider the Internet scenario, it is also often necessary to allow users to register to gain access to certain sections of the site or, for example, to obtain write rights. In this case, the ideal option would be form authentication, configured to use a database to store the credentials of registered users.

If you plan to use integrated Windows authentication and require a high level of security, the best option would be to use Kerberos authentication.

'Double-hop' problem

Also Kerberos authentication is used to solve the 'double-hop' problem. The essence of the problem lies in the need to access some network resource or server from the code using the credentials of the user who caused the code.

Consider an example. We are writing a web part that displays data from a third-party database, such as Oracle. Moreover, only the data that is available to the user who opened the page with our web part should be displayed, according to his access rights. Those. when accessing the database, the windows account of the user who opened the web part should be used.

Immediately suggests the use of ASP.NET impersonation. This is logical, but it will work only if the Oracle database is located on the same computer on which the web server with our web part is installed and configured. The reason for this is the NTLM protocol, which does not allow the impersonal user credentials to be transmitted over the network. One way to solve this problem is to use Kerberos authentication in the domain and configure delegation between the database server and the web server.

The second solution to this problem is to use the Win32 API to impersonate the user before accessing the database server. This approach is implemented using Single Sign-On.

Single Sign-On is also worth using in cases where you plan to use SharePoint with third-party applications, in which users must have access to third-party systems without the need to enter credentials.

Basic HTTP authentication is practically not used due to the low level of security.

Where and how to set up authentication?

All SharePoint authentication settings are applied at the web application level. Therefore, the starting point for configuring authentication is the SharePoint Central Administration farm, and specifically the Application Management > Authentication Providers page.

Authentication settings can be applied manually by editing the web.config file and setting parameters in the IIS administration console. However, it is recommended that you use the central administration interface, because with this method, the settings specified through the interface will automatically be applied to all web servers in the farm.

In the meantime, there are cases when you cannot do without manual configuration. In particular, if you need to use digest HTTP authentication, you will need to configure each IIS server in the farm. Also, manual configuration will be required if you use authentication using forms - you will have to connect the necessary providers to all web.config farm files.

Web application zones

Zones are used to support multiple ways to authenticate a web application. This can be useful, for example, if access to a site other than company employees (Windows authentication) must be accessed by clients (form authentication). In this case, for some, a zone created by default is used, and integrated windows authentication is configured for it, and a new zone is created for clients based on the existing one and authentication is configured for it using forms.

SharePoint allows for one web application to use the following zones:

Default zone
Intranet zone
Zone internet
User Zone
Extranet zone

Authentication settings for all zones are the same by default (NTLM with anonymous access disabled). Therefore, all the necessary settings must be made manually.