Authentication and Authorization in Share Point
Authentication is process of challenging and approving user’s Identity, while Authorization comes after the authentication, where user based permissions, rights, and privileges are taken into account. Microsoft SharePoint Services 3.0, MOSS, and SharePoint Foundation supports security for user access at the Web site, list, library folder, and item levels2. This security is managed based on role based mechanisms where each user is able to perform specific operation and all levels based on his/her role, and this is achieved through Authorization process once the user is successfully authenticated by the underlying authentication mechanism.
In SharePoint Services 3.0, MOSS and SharePoint Foundation, the Authentication is achieved mainly through following methods
1. Windows based Authentication, Including Active Directory Authentication (both Kerberos and NTLM protocols), anonymous and basic authentication. Authentication is done by underlying IIS.
2. Form based Authentication, which is implemented by the ASP.NET authentication provider model. SharePoint provides an LDAP membership provider which can talk to Active Directory, Active Directory Application mode (ADAM), Active Directory Lightweight Directory services (AD LDS). Forms-based authentication can also use the SQL Server provider included with ASP.NET. Forms authentication allows ASP.NET to perform the authentication for SharePoint Foundation, but In SharePoint Foundation, ASP.NET forms are supported only under claims authentication. A forms provider must be registered within a Web application that is configured for claims.
3. Claim based Authentication (SharePoint Foundation 2010), this new way of authentication facilitates by authenticating across widows based users, and non-windows based users, stronger real-time authentication, and delegating user identity between multiple applications. Claims based authentication addresses integration of different systems by allowing communications using open standards, and by providing a platform for developing more specialized ‘identity connectors’ between systems.
Above are the brief descriptions of available options for Authentication in SharePoint, to keep things simple and traceable I am omitting details because there could be a detailed discussion on each mentioned options.
How Windows Authentication works in SharePoint?
Now, let’s have a look how generally Authentication works in SharePoint.
1. A client anonymously generates a request using his/her browser that initiates a connection to a SharePoint front-end server, which is handled by IIS with .NET through an HTTP GET request.
2. If the zone is configured for anonymous access (such as for Internet scenarios), IIS continues to
process the request. Otherwise, IIS returns error 401.2 and requests authentication from the
3. The client browser receives the request and, depending on the zone and associated options,
authenticates the client. A common method is by prompting for a username/password, and
then passing an auth token back to SharePoint via IIS.
4. IIS is waiting for a response in the HTTP conversation and accepts the auth token, and then
either authorizes or denies access. At this point, IIS passes the request to SharePoint through
5. If the requested page has a Web Part that needs to access the back-end SQL databases,
SharePoint authenticates with the SQL Server and accesses the databases. The nature of the SQL authentication varies with the configuration options. For example, you can configure SQL Server authentication or Integrated Windows authentication using NTLM or Kerberos.
NTLM mode of Authentication
More specifically if NTLM mode of Authentication is configured then Step 3 and 4 would be as follows
3.1 IIS rejects the anonymous request with a 401.2 error and sends back a request to authenticate with NTLM.
3.2 The client browser receives the request, creates the Authentication token that includes domain and computer name, and then sends the authentication token to IIS.
3.3 IIS accepts the details and sends an NTLM challenge to the client.
3.4 The client responds with the response to the challenge (auth token again), encrypted with the
password of the user.
4.1 At this point, IIS needs to talk to the domain controller. It sends the client’s user name,
challenge, and challenge response.
4.2 The domain controller retrieves the password hash for the user and compares t to the challenge
response, which was encrypted using the user’s credentials. If there’s a match, the domain controller returns a successful authentication to IIS, and IIS can talk to the client browser.
Kerberos mode of Authentication
In case, where Kerberos mode (Kerberos uses a ticket system that authenticates once and then authorizes through delegation) of authentication is configured then Step 3 and 4 would be as follows
3.1 The client contacts the KDC (Key distribution center) on the domain controller and requests a ticket for the SPN (service principal name) based on what the browser client sent as the hostname.
3.2 If the KDC locates a matching SPN, it encrypts the ticket and returns it.
3.3 The browser client creates the authenticator and sends it with the service ticket to the IIS
server, which in turn decrypts the ticket, determines identity, and checks the permissions
(access control list) on the requested resource to see if access is permitted.
4 If access is permitted, IIS, through the Web Application service, contacts the SQL Server and the
service requests a ticket for the SQL Server from the KDC.
Generally, Windows based Authentication mode is selected whenever your application is running on windows, where Active directory is already configured, this is the easiest way of authenticating in SharePoint.
Anonymous Access is a way of providing unregistered users to interact with SharePoint sites. For internal deployments and Intranet sites Anonymous Access is always discouraged. The possible scenario in which anonymous authentication should be considered is on public-facing websites – so that people can browse sites without having to create accounts. Anonymous access does not provide item-level control, prevents document authoring, and does not provide access to remote interfaces.
Form Based Authentication in SharePoint
The Forms-based authentication option is generally selected when an environment does not use Active Directory, or needs to support external access. Form based Authentication basically builds on top of ASP.Net 2.0 Membership concepts, where there is Member Ship Provider which defines interfaces for identifying and authenticating individual users, and a Role Manager, which defines interfaces for grouping individual users into logical groups or roles4.
The authentication is authorization is done by redirecting to custom pages developed in asp.net using login controls and/or custom controls and after getting user credentials a user identity object is created which is used to authenticate users based on their roles against custom data base (SQL) or Active directory users.
For internal sites, one should disable anonymous authentication as it may prevent compliance with business’s accountability requirements and business policies. Windows authentication with the Kerberos protocol is most proffered where this is possible, as it offers better integration and ease of use.
Microsoft development kit for SharePoint
Is this Information helpful ? Please leave a Comment.