Authentication in SharePoint 2013

Authentication in SharePoint 2013

                                                                                        

Three types of authentication:-

1.       User authentication

2.       App authentication

3.       Server-to-Server authentication

1. User authentication:-

User authentication occurs when a user attempts to access a SharePoint resource and the user s identity is validated against an authentication provider.

There are three types of User authentications,

1.1   Windows claims-based authentication

1.2   Forms-based authentication

1.3   SAML token-based authentication

1.1 Windows claims-based authentication:-

Windows claims-based authentication uses your existing Windows authentication provider (Active Directory Domain Services [AD DS]) to validate the credentials of connecting clients. Use this authentication to allow AD DS-based accounts access to SharePoint resources. Authentication methods include NTLM, Kerberos, and Basic.

For Windows claims authentication, SharePoint 2013 uses the NTLM or Kerberos protocols to validate user credentials for users that are in forests and domains trusted by the SharePoint 2013 server.

SharePoint 2013 also supports classic-mode Windows authentication, but this is not recommended. Classic-mode Windows authentication does not support app authentication, server-to-server authentication, and Office Web Apps. To configure a web application to use classic-mode authentication, you must use the New-SPWebApplication or Set-SPWebApplication Windows PowerShell cmdlets.

1.1 Windows claims-based authentication How it Works:-

In this example, a user who does not already have a SharePoint security token accesses a secured SharePoint web page.

1)      User requests a web page.

2)      SharePoint requests Windows credentials using NTLM, Kerberos, or basic protocols.

3)      User sends the Windows credentials for the user account.

4)      SharePoint validates the user s Windows credentials with AD DS.

5)      SharePoint obtains the group membership list for the user account from AD DS. SharePoint creates a SharePoint security token, sends an authorization code and the requested web page (from 1).

1.1 Windows claims-based authentication Configuration:-

New web applications created in Central Administration are configured by default to use Windows authentication and the NTLM method:

                    I.            Modify the authentication settings for the web application in Central Administration to include Kerberos.

                  II.            Modify the settings of the web application in the IIS Manager snap-in to enable the Digest and Basic authentication methods.

1.2 Forms-based authentication:-

Forms-based authentication can be used against credentials that are stored in an authentication provider that is available through the ASP.NET interface. These include.

                     i.            AD DS.

                   ii.            A database such as a SQL Server database.

                  iii.            A Lightweight Directory Access Protocol (LDAP) data store

Forms-based authentication validates users based on credentials that users type in a login form (typically a web page). Unauthenticated requests are redirected to a login page, where a user must provide valid credentials and submit the form.Use forms-based authentication with accounts in authentication providers that are available by using the ASP.NET interface.

With forms-based claims authentication, SharePoint 2013 uses the ASP.NET interface to access membership providers and role managers to validate user credentials and obtain user roles.

1.2 Forms-based authentication How It Works:-

In this example, a user who does not already have a SharePoint security token accesses a secured SharePoint web page.

1)      User requests a web page.

2)      SharePoint sends a SharePoint forms-based login page.

3)      User sends the credentials entered in the forms-based login page.

4)      SharePoint validates the credentials with the ASP.NET membership provider.

5)      SharePoint obtains roles from the ASP.NET role provider.

6)      SharePoint creates a SharePoint security token, sends the FedAuth cookie, and web page.

1.2 Forms-based authentication Configuration:-

Configuring forms-based authentication involves the following:

                    I.            Modify the Web.config files for the Central Administration web application, the Security Token Service web site, and the web application to register the ASP.NET membership provider and role manager.

                  II.            Configure the web application with the name of the membership provider and role manager that was added to the Web.config files.

                III.            Optionally, you can also create a custom login page for forms-based authentication.

1.3 SAML token-based authentication:-

SAML token-based authentication in SharePoint 2013 requires coordination with administrators of a claims-based environment, whether it is your own internal environment or a partner environment.

A SAML token-based authentication environment includes an identity provider security token service (IP-STS). The IP-STS issues SAML tokens on behalf of users whose accounts are included in the associated authentication provider. Tokens can include any number of claims about a user, such as a user name and the groups to which the user belongs. An Active Directory Federation Services (AD FS) 2.0 server is an example of an IP-STS.

Use SAML token-based authentication to allow accounts in authentication providers that are available by using a compatible IP-STS access to SharePoint resources.

For SAML token-based claims authentication, SharePoint 2013 supports the SAML 1.1 and WS-Federation Passive Requestor Profile (WS-Federation PRP) protocols for requesting computers to obtain SAML tokens as proof of validation of user credentials and for additional claims.

1.3 SAML token-based authentication How it Works:-

In this example, a user who does not already have a SharePoint security token accesses a secured SharePoint web page.

1)      User requests a web page.

2)      SharePoint sends a redirect and the user loads a login page from the AD FS server.

3)      User sends user credentials and requests a SAML security token.

4)      AD FS validates the user credentials with AD DS (the authentication provider).

5)      AD FS sends a SAML security token.

6)      User sends a new web page request containing the SAML security token.

7)      SharePoint creates a SharePoint security token, sends the FedAuth cookie, and the requested web page.

1.3 SAML token-based authentication Configuration:-

The key elements of SAML token-based authentication are the following:

                                I.            Configure the IP-STS with the set of authentication providers (such as AD DS, databases, and others) corresponding to organization and partner accounts.

                              II.            Configure the IP-STS with the set of relying parties corresponding to the web applications that use SAML token-based authentication and claims mappings.

                            III.            Configure the SharePoint 2013 farm with the token signing certificate of the IP-STS, the corresponding claims mappings as done on the IP-STS, and the name of the IP-STS as a trusted security token issuer.

                            IV.            Configure the web application with the name of the IP-STS as a SAML identity provider.

2. App Authentication:-

App authentication occurs when an external component of an app for SharePoint attempts to access a secured SharePoint resource. App authentication is a combination of:

                    I.            Verification of a remote app for SharePoint's identity (authentication).

                  II.            Validation of the type of access through user and app permissions (authorization).

App Trust Level are Two Type, they are

2.1   Low-Trust Apps

2.2   High-Trust Apps

2.1 Low-trust Apps:-

A low-trust app relies on the Windows Azure Access Control Service (ACS) as the trusted security token issuer for access tokens that are required to obtain secured resources on a SharePoint farm. The app provider or Windows Azure can host low-trust apps. To trust low-trust apps, you must have an Office 365 subscription.

In this example, a user accesses a secured SharePoint web page containing an IFRAME that is rendered by an app hosted in Windows Azure. To render the IFRAME, the app must access a resource on the server running SharePoint 2013 on behalf of the requesting user.

1)      User requests a web page containing the Azure app s IFRAME.

2)      SharePoint obtains a context token from ACS.

3)      SharePoint sends the web page with the app s IFRAME and the context token to the user.

4)      User requests the IFRAME contents with the context token from the app.

5)      App obtains an access token from ACS.

6)      App requests the SharePoint resource using the access token.

7)      After app and user authorization, SharePoint responds with the requested resource.

8)      App sends the IFRAME contents to the user.

2.2 High-trust Apps:-

A high-trust app is an app that an intranet server or a provider's server on the Internet hosts. For high-trust apps, the app acts as the trusted security token issuer for access tokens that are required to obtain secured resources on a SharePoint farm.

In this example, a user accesses a secured SharePoint web page containing an IFRAME that is rendered by a high-trust app. To render the IFRAME, the app must access a resource on the server running SharePoint 2013 on behalf of the requesting user.

1)      User requests a web page containing the high-trust app s IFRAME.

2)      SharePoint sends the web page with the app s IFRAME.

3)      User requests the IFRAME content from the high-trust app server.

4)      App authenticates the user and generates an access token.

5)      App requests the SharePoint resource using the access token.

6)      After app and user authorization, SharePoint responds with the requested resource.

7)      App sends the IFRAME contents to the user.

3. Server-to-Server Authentication:-

Server-to-server authentication enables a new set of functionality and scenarios that utilize cross-server resource sharing and access, including the following:

                    I.            eDiscovery Discover and place holds on content in the SharePoint farm, in Exchange Server 2013, on file shares, and in other SharePoint farms.

                  II.            Exchange task synchronization Allows users to synchronize SharePoint Server 2013 and Project Server tasks with Exchange Server 2013 and have them appear in Outlook 2013.

                III.            Site mailboxes Provides SharePoint Server 2013 users with team email, hosted by Exchange Server 2013, on a SharePoint site.

                IV.            SharePoint 2013 Hybrid Federated search, Business Connectivity Services, and Duet Online between an on-premises SharePoint 2013 farm and SharePoint Online.

Server products that are capable of server-to-server authentication:-

3. Server-to-Server Authentication How It Works:-

Similar to app authentication, SharePoint 2013 allows access to the requested resource when the server making the request is verified as trusted and the type of access is authorized through validation of user and server permissions.The validation of a server's request for resources that is based on a trust relationship established between the Security Token Service (STS) of the server that runs SharePoint 2013 and the security token service (STS) of another server that supports the OAuth server-to-server protocol. Based on this trust relationship, a requesting server can access secured SharePoint resources on behalf of a specified user account, subject to server and user permissions.

3. Server-to-Server Authentication Configuration:-

Server-to-server authentication configuration consists of adding a new trusted security token issuer that corresponds to each server that will send resource requests on behalf of users.

                    I.            For on-premises SharePoint farms, you configure the JSON metadata endpoint of the other SharePoint farm.

                  II.            For your SharePoint Online farm, you configure the JSON metadata endpoint of your Office 365 subscription.

                III.            For servers running Exchange Server 2013 or Lync Server 2013, you configure the JSON metadata endpoint of the other server.

Example — How Server-to-Server Authentication works between on-premises SharePoint farms:-

In this example, Farm B has been configured to trust Farm A by using server-to-server authentication. Farm A has been configured with a result source for search that uses the Remote SharePoint protocol to get search results from the index of Farm B. To obtain search results, Farm A sends a query to Farm B.

1)      User on Farm A executes a query to get search results from the local search index and the search index of Farm B.

2)      Farm A generates an access token, identifying the user and the requested resource (a search index).

3)      Farm A sends the access token to Farm B.

4)      Farm B validates the access token, verifies authorization, and sends the search results.

5)      Farm A sends the complete set of search results from both Farm A and Farm B to the user.