Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Microsoft Sharepoint 2013 : User Authentication (part 3) - Using Claims-Based Identity - Understanding the User Authentication Process and Authentication Providers

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
11/29/2014 8:10:13 PM

Understanding the User Authentication Process and Authentication Providers

User authentication scenarios in SharePoint 2013 can be as straightforward as using Windows Integrated Security and Active Directory or as complicated as using Windows Azure Access Control Service as a federation provider. The process for user authentication with a trusted IdP and using SharePoint’s internal STS is a complex process. This process is shown in Figure 1, and described in the following steps. This example uses SharePoint as the relying party, but the relying party could be any claims-enabled application.

FIGURE 1

image
1. The process begins when the user makes a request to access SharePoint resources or a SharePoint website. In reality, a web browser or other client acting on behalf of the user makes an HTTP Get request. SharePoint checks to see if the request contains a SAML token with the user’s identity. Once a valid SAML token is identified, SharePoint 2013 then inspects the target URL of the incoming request to see whether it references a standard SharePoint site or a child site associated with a specific app web. If the incoming request targets a standard site, SharePoint 2013 conducts its authentication and authorization process granting access to the requested resource. However, if the request targets an app web, SharePoint initiates an OAuth process. In our scenario, the client is requesting access to a SharePoint website, and has not yet been authenticated, so no SAML token is present.

2. Since the user has not been authenticated, SharePoint sends an authentication request redirect to the client so that it can be authenticated by its IdP.

3. The client issues an authentication request to its IdP, which can be Active Directory, FBA, or any SAML-based system, and the client is authenticated based on the user’s credentials. In general, the request also contains information identifying the application to which the user wants access. The IdP performs a lookup in the appropriate user directory or database and validates the user’s identity.

4. Once the client is authenticated, the IdP returns a Windows token, FBA token, or SAML token to the client.

5. The client sends the authentication token to SharePoint, and the SharePoint STS creates a new token with the appropriate claims. The SharePoint STS can perform claim transformation and claims augmentation, the former modifying the claims information while the latter includes adding additional claims information.

6. The SharePoint STS sends the new SAML token back to the client. So, at this point we have two tokens, an authentication token from the IdP and a SAML claims token from the SharePoint STS.

7. The client submits the SAML token to SharePoint, and SharePoint reviews the token, as in Step 1. SharePoint or the application verifies the token’s signature, confirming that it originated from a trusted IdP, and the claims are accepted. The token can also contain claims about the user that SharePoint can use for authorization.

8. SharePoint issues a response with the requested content to the client, and the process is complete.

Claims authentication is based on delegating user authentication to a trusted STS that is backed by the identity provider. The trust is established and verifiable by the STS and the claims-consuming application (SharePoint) using the public:private key pair of a digital certificate.

A key benefit of claim identity and claims authentication is that the application does not have to authenticate the user. The application can focus on authorization because it no longer needs to authenticate the user. An application can specify exactly what claims it needs and which identity providers it trusts. Because the application doesn’t have to authenticate the user, it can be deployed on-premise or in the cloud without change. The application only needs to be configured to trust the appropriate STS, and the administrator configures the STS to issue the right claims required by the relying party.

Authentication providers are the means by which users are authenticated, because they represent a directory or database containing the user’s credentials. An example of an authentication provider is Active Directory Domain Services (AD DS). Other terms for an authentication provider that you may see used are user directory and attribute store. Claims authentication represents an authentication type, and it is a specific way of validating credentials against one or more authentication providers. SharePoint 2013 includes a local or internal STS and WIF to claims-enable web applications; therefore, SharePoint 2013 websites are configured to utilize claims.


NOTE Classic-mode authentication is still supported, but it is being deprecated, so organizations are encouraged to use claims authentication. Classic-mode configuration is done using PowerShell cmdlets; it cannot be implemented using Central Administration.

Claims authentication in SharePoint 2013 supports all the authentication providers supported in SharePoint 2010: Windows authentication (Kerberos, NTLM, Basic), forms-based authentication using ASP.NET membership and role providers, and SAML token-based authentication. When you create a new web application, the default authentication type is claims, and the default authentication provider is NTLM. You have the option to also choose Kerberos, and this type of configuration is very important for establishing a SharePoint farm to support business intelligence. In general, organizations that don’t use AD DS can use either FBA or SAML, as outlined here:

  • For organizations using an LDAP directory, FBA is easier to implement than SAML, although both approaches are available. SharePoint Server 2013 has a built-in LDAP provider. FBA can utilize the default providers that are included with ASP.NET, or organizations that have very specific security requirements (and very good developers) can create their own providers if necessary.
  • SAML is recommended for those organizations already using an authentication environment that supports WS-Federation 1.1 and SAML 1.1, which are both supported by SharePoint 2013. SAML tokens can be produced by identity providers such as Active Directory Federation Services (ADFS) and others.
  • Utilizing ADFS and services such as Windows Azure Access Control Services (ACS) as federation providers enables end users to authenticate against many common identity providers or even another organization’s Active Directory instance. ADFS 2.0 also supports SAML 2.0, so ADFS can be used to federate with SharePoint 2013 to enable integration with third-party SAML 2.0 providers.

The process for using FBA and SAML authentication providers with SharePoint 2013 is similar to that for SharePoint 2010, and is discussed in detail on TechNet. Several key references that describe the configuration are described in Table 2.

TABLE 2: References for Configuring FBA and SAML Authentication Providers

AUTHENTICATION PROVIDER REFERENCES
Forms-based authentication http://technet.microsoft.com/en-us/library/ee806890
http://www.microsoft.com/en-us/download/details.aspx?id=34684
SAML authentication using ADFS http://technet.microsoft.com/library/hh305235.aspx
http://technet.microsoft.com/en-US/library/jj219641.aspx

NOTE Claims-based authentication is Microsoft’s recommendation for all web applications and zones of a SharePoint 2013 farm, as this enables you to take advantage of all the new features and scenarios in SharePoint 2013 that use server-to-server authentication and app authentication.


WARNING The new Office Web Applications can only be used by SharePoint 2013 web applications that use claims-based authentication. Office Web Apps rendering and editing will not work on SharePoint 2013 web applications that use classic-mode authentication.

Several scenarios require the use of additional identity capability. One such example is federated user authentication, which is discussed in the next section.

Other -----------------
- Microsoft Sharepoint 2013 : What’s New with Claims and Authorization?
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 3)
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 2) - Working with the REST API in JavaScript
- Sharepoint 2013 : Client-side Programming - Working with the REST API (part 1) - Understanding REST fundamentals
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 7)
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 6)
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 5) - Moving Mailboxes
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 4) - Installing Exchange Server 2007 on a Server System
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 3) - Installing Exchange Server 2007 Prerequisites
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 2)
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server