Chapter 6

Claims Authentication and OAuth

WHAT’S IN THIS CHAPTER?

• What’s new with claims and authorization?
• User authentication
• Application authentication
• Server-to-server authentication

SharePoint 2013 contains several new enhancements to the claims infrastructure, and it introduces Open Authorization (OAuth) capability, which enables new server-to-server and application authentication scenarios.

A user authentication model called claims-based authentication (CBA) was first introduced in SharePoint 2010. SharePoint websites using CBA are said to be using claims authentication, or just claims. SharePoint 2013 introduces several new enhancements to the claims infrastructure and capability, and it is now the default user authentication mechanism for all SharePoint 2013 websites. As SharePoint adoption increases, users are accessing SharePoint websites from both their company’s on-premise implementation and from cloud-based solutions such as Windows Azure, and SharePoint online, which is a part of Office 365. A SharePoint application may even be accessed from different organizations. This diverse set of access scenarios requires a robust authentication and authorization infrastructure, which CBA provides for applications running on-premises or in the cloud.

CBA is based on the concept of identity and utilizes open-source standards and protocols so that it works with any corporate identity system, not just Active Directory and not just Windows-based systems. Identity is represented by a set of information about the user, and this information is encapsulated in a security token. This token is presented to any application to which the individual is attempting to gain access. The individual’s token, and therefore his or her identity, is verified by some directory service. Typically, user authentication contains username and password information. The beauty of CBA is that this token can contain a richer set of information that can be used for authorization, as well as confirming user authentication. CBA provides a trust-based system between applications and a centralized provider that issues the token. The application trusts the individual because the provider is trusted. Therefore, in addition to providing a single sign-on environment, this eliminates the need for each application to authenticate the user, enabling the application to focus on what permissions to assign, and how the application interacts with the user. CBA can be used in combination with OAuth to provide new authentication scenarios.

SharePoint 2013 also introduces support for the Open Authorization 2.0 (OAuth) standard. OAuth is an industry standard protocol that allows a user or application to temporarily access resources or information on behalf of another user, thereby eliminating the need for the requesting user to share his or her password information. SharePoint 2013 uses this capability to provide the new server-to-server authentication capability with other applications, such as Exchange Server 2013, and apps in the SharePoint Store or App Catalog.

This chapter provides an overview of the claims authentication process and the new SharePoint 2013 claims enhancements. It also covers the new server-to-server authentication process, the OAuth functionality, and how these new security processes are used.

WHAT’S NEW WITH CLAIMS AND AUTHORIZATION?

Several new capabilities are introduced in SharePoint 2013, and the following sections cover those most pertinent to the administrator. As you plan to upgrade to SharePoint 2013 from SharePoint 2010, you should be planning your strategy to migrate classic-mode websites to claims-mode websites. The user authentication infrastructure is now more efficient and effective, as login tokens are now cached using the Distributed Cache Service. SharePoint 2013 can share resources and information more securely with other applications using the server-to-server authentication process. OAuth, which is new to SharePoint 2013, is used to provide access to resources.

Migrating from Classic to SharePoint 2013 Claims

This is a very important topic for SharePoint administrators, as Windows claims authentication is the new default user authentication mechanism for SharePoint 2013 when you create a new SharePoint 2013 web application. SharePoint 2013 will continue to support classic-mode authentication, but the capability to create a classic-mode SharePoint web application is no longer available using the web browser. You can still create a classic-mode web application using PowerShell, but claims authentication is recommended and it is required to support all SharePoint 2013 functionality.

SharePoint 2013 supports three different types of claims authentication: Windows-based claims, Security Assertion Markup Language–based (SAML) claims, and forms-based authentication (FBA) claims. Organizations that used classic-mode authentication in SharePoint 2010 have the following supported options for migrating to claims-based authentication:

• Migrate from classic authentication to claims authentication in SharePoint 2010. SharePoint 2010 content can then be migrated to SharePoint 2013 via normal methods (database attach, etc.).
• Migrate the SharePoint 2010 content to SharePoint 2013 via the database attach method. Convert the classic-mode web application to use claims via PowerShell.

SharePoint 2013 introduces new PowerShell cmdlets to accomplish this migration. For a more in-depth discussion of the classic-to-claims migration, and the overall process of upgrading SharePoint 2010 to SharePoint 2013, administrators should refer to Chapter 5, “Upgrading to SharePoint 2013.”

Authentication Infrastructure

SharePoint 2013 introduces the new Distributed Cache Service (DCS), which is used to cache login tokens (also known as FedAuth cookies). This is a big improvement over SharePoint 2010, which stored the login token on each web front-end (WFE) server in the farm. In SharePoint 2010, users who are redirected to a different load-balanced WFE often need to re-authenticate when using SAML or FBA authentication if load balancer affinity, also called sticky sessions, is not enabled. Therefore, sticky sessions are no longer required with SharePoint 2013. In addition to the use of the DCS, SharePoint 2013 has much more verbose logging of the claims authentication process. The ULS logs contain much more information about user authentication, such as user redirection, token addition and removal from the cache, and so on, which helps to manage and troubleshoot claims.

OAuth

SharePoint 2013 supports and extends the OAuth 2.0 standard. As mentioned earlier, OAuth is an industry standard protocol that enables users to authorize an application to act on their behalf without sharing their username and password. This is accomplished by establishing a trust relationship between the applications, which means you don’t have to assign a Windows login credential to an application. This enables users to, for example, share their resources or data (SharePoint lists, documents, photos, and videos) stored on one website with another website, or use this information as input for a custom application. OAuth is used only for resource access, not for user authentication. As you might guess, the new SharePoint 2013 Cloud App Model (also referred to as just the App Model) uses OAuth extensively to authorize apps to access resources on behalf of users.

SharePoint 2013 uses OAuth to allow applications to access SharePoint resources in one of three ways:

• With the combined permissions of the application and the user
• With only the permissions of the application
• With only the permissions of the user

The app is given access to these resources by defining a trust relationship between the application and SharePoint 2013. Depending on the architecture of the application, a trust relationship between SharePoint 2013 and a cloud provider such as Windows Azure Access Control Service (ACS) can also be established. These trust relationships are very similar to the trust relationships used for authenticating SharePoint users with claims authentication. We provide a more detailed discussion of the claims authentication process in the User Authentication section.

Server-to-Server Authentication

Server-to-Server (S2S) authentication, which is used to create SharePoint high-trust apps, is a scenario for application-to-application authentication, and OAuth provides the basis for this capability. S2S uses a Microsoft extension of the OAuth protocol to enable services or servers to share resources on behalf of a user, and this user does not have to be authenticated. S2S requires user profiles, so user profile mapping and profile imports must be configured. For all those interested in using SharePoint Foundation 2013, high-trust apps are not possible because user profiles are required and not available in Foundation. S2S allows SharePoint to share information across SharePoint 2013 farms, and with other S2S-compliant applications. For example, the following SharePoint 2013 capabilities utilize S2S:

• eDiscovery — The Electronic Discovery capability enables SharePoint 2013 to index mailbox content in Exchange Server 2013 and conversation content in Lync Server 2013 to include that information as part of a legal hold.
• Task management — Tasks created in Outlook 2013 or in SharePoint 2013 are synchronized and viewable from a user’s personal site.
• Site mailboxes — These are Exchange 2013 mailboxes that are rendered and viewable from SharePoint 2013 websites.
• Workflow — As discussed in Chapter 16, “Installing and Configuring Azure Workflow Server,” S2S is used by SharePoint 2013 to authenticate and share information with the new Azure Workflow Server.

That concludes a brief overview of some of the new key features, which are discussed in more detail throughout the chapter. The following section describes claims identity and the actual authentication process. It introduces several new terms and provides a basis for the rest of the chapter.

USER AUTHENTICATION

In this section, our goal is for the administrator to gain a deeper understanding of claims-based authentication, as this is the new default mechanism for SharePoint 2013. We begin by introducing the concept of claims-based identity, and then describe how to use it, ending with a high-level overview of the claims authentication process.

Claims-Based Identity

Users new to claims-based identity routinely ask the same set of questions:

• Why do we need yet another way to authenticate users?
• What is user identity?
• What is a claim?
• Why is claims authentication the default SharePoint mechanism?

The answers to these questions are associated with the key challenges related to providing users with access to information. These challenges include user identity, user access, and user information and storage. As you will see, claims-based identity presents a solution to these challenges.

User Identity

User identity is a fundamental requirement for application security, in terms of both user authentication and user authorization. Knowing who is requesting access to websites and access to object information is critical to providing a secure environment. The challenge is determining which identity technology is the right one for a specific application, and then which one is the best across the enterprise or cloud environment so that you can accommodate the needs of all the applications. The solution can become very complicated. You need to satisfy two key requirements:

• How users will gain access to the enterprise’s applications, regardless of their location
• How different types of user information will be retrieved by the applications so that the applications can accomplish their required functions

User Access

User access to websites and information is necessary for sharing and collaborating inside and outside the organization. Providing user access in a secure manner is critical, and a key challenge. Administrators and developers need to know whether an application will be accessed by employees from within the organization, from a device outside the organization, from the public Internet, or any combination of these. One technology may not be enough; the organization may have to support multiple technologies. For example, you might use Windows integrated security for internal users, and forms-based authentication (FBA) for users outside the organization; but this introduces complexity in terms of providing a single authentication mechanism and the need for storing different user information in multiple locations. In addition, neither Windows integrated security nor FBA provide much information about the user, with the latter providing username and password information only, unless both the membership and role providers have been created and configured. In addition, suppose you need to provide access to partner or vendor employees. For that you need to implement identity federation using SAML so that users won’t need a separate login. An example of identity federation would be using Active Directory Federated Services (ADFS). ADFS would provide a SSO experience for these non-employees, without IT having to give them a company login account. Finally, keep in mind that the application requiring login may exist in the cloud, as this scenario is rapidly gaining popularity; or you could have a hybrid scenario, with applications both on-premises and in the cloud.

User Information

How will information about users be stored and retrieved? The application can query the user for some information and look up other information. This may not sound like a big issue, but consider the number of different applications in an organization, and that each may need to store and retrieve information that is specific to its functionality. Even when your organization requires simple identity capability, such as all users across the enterprise authenticating using Active Directory, this type of login provides very little information about the user.

The Solution

The solution to user access and user information has typically been solved by each different application requiring its own login and user information. This may not be an issue if there is just one application, but when you have multiple applications this becomes a big problem for both users and administrators. Claims identity offers a different and better solution: create a single identity approach for all scenarios so that the user is authenticated once, and each application is provided with the specific information it needs. However, you may be wondering why you need to use claims; wouldn’t SharePoint’s classic mode NTLM and Kerberos work just fine? The following reasons may help to convince you otherwise:

• NTLM and Kerberos protocols haven’t been significantly updated in many years.
• The need to federate SharePoint with other systems and to establish hybrid environments that include both on-premise and cloud resources is here and increasing. NTLM and Kerberos are not particularly well suited for interoperability with other applications outside your organization.
• Windows claims supports both NTLM and Kerberos.
• Claims alone and in combination with OAuth offers new ways to delegate authentication and authorization, and to utilize user profile information.
• SharePoint and SAML open new directory integration possibilities that Active Directory alone cannot meet. For non-Microsoft products and technologies, SAML is the standard, just as Active Directory is the standard for Microsoft products.
• You may already be using claims authentication and not realize it. For example, when you log in to Windows Live (which has been renamed to Microsoft ID) or grant access to your Facebook profile, you are using WS-Federation and OAuth.

Claims-based identity provides a common way for applications to acquire identity information from users, irrespective of whether they are inside the organization, in other organizations, or on the Internet. Now that you understand the concept of claims identity and its role as a solution for user authentication, the following section takes a look at using claims identity.

Using Claims-Based Identity

The purpose of this section is to show how claims identity is used to authenticate users. It begins with a real-world analogy that illustrates the use of claims. Then you will learn the technical requirements for implementing claims authentication. Finally, you will walk through the actual claims authentication process.

A Real-World Analogy

It’s very likely that at some point, you have used your driver’s license to establish or verify your identity. Your license contains a set of attributes that assert your identity, such as name, age, eye color, and so on. In order to obtain such a license, prospective drivers must furnish required credentials bearing proof of their identity. This proof might be a birth certificate, a passport, and might even include a utility bill or some other proof of residency. These assertions are verified by the state agency, and the state issues your driver’s license. This list of identity assertions is used by other companies or agencies to verify your identity because they trust the state agency that issued your license.

In claims identity, this list of assertions can be considered a set of claims. Assertions can include a username, a role, an employee ID, and a variety of other attributes pertinent to the individual’s position. The state agency represents the Security Token Service (STS). Users request access to SharePoint resources and are redirected to the STS. The STS verifies their identity (authenticates the user), and then issues a security token that encapsulates the user’s claims. The STS functions as an identity provider (IdP) because it creates and manages security tokens. To create a security token, the STS must be able to locate valid credentials for a user in an attribute store. Active Directory Domain Services can be used as an attribute store for an STS, and would be an example of an authentication provider. SharePoint and other applications trust the STS and therefore do not have to re-authenticate the user. The claims can then be used to determine authorization and permission levels for access to SharePoint 2013 resources.

A relying party is any entity that trusts the issuer of the driver’s license or, in the claims world, the STS. In the physical world, the security agent at the airport is a relying party. In the claims world, SharePoint trusts the STS (or multiple STSs) to have authenticated the users who make requests for SharePoint resources, and therefore is a relying party. In both the real world and the claims world, those who produce the security tokens often add other relevant information about the user to the tokens. In the driver’s license example, address information, height, weight, and a picture are typically included. In the claims world, security tokens can include information that SharePoint can use to authorize the user’s requests for SharePoint resources, such as organization information, group memberships based on geography or job role, or any other information that can be used to determine what a user can do inside of SharePoint. In our driver’s license analogy, the relying party of a driver’s license depend on the birthdate to determine whether a user can purchase alcohol. Note that the relying party makes this decision based on the value of the birthdate, not just the presence of the birthdate. As a relying party, SharePoint uses attributes gathered from Active Directory and other attribute stores. In the case of the driver’s license and the security token, these attributes are added when the token or license is created. This addition of claims is referred to as claims augmentation.

Driver’s licenses expire, and once expired they are no longer considered a legitimate means of providing identification. Similarly, a security token has a defined lifetime after which it is no longer valid.

Driver’s licenses are also subject to being modified or duplicated to provide false information. Relying parties in the physical world (security agents at an airport, for instance) deal with this by not accepting licenses that show signs of tampering. In the claims world, the STS knows the type and number of claims specified by the relying party, and the STS token is digitally signed to protect against tampering and ensure authenticity.

Technical Requirements

To implement claims identity, SharePoint 2013 utilizes a Security Token Service (STS) defined in WS-Trust, and is configured to trust one or multiple STSs. SharePoint 2013 is claims-enabled once it is installed, but the following provides perspective on the key components. Implementing claims-based identity and using claims for authorization generally requires using and understanding a set of core technologies:

• Windows Identity Framework (WIF) — WIF provides the .NET classes required to enable claims-based authentication. All the required interactions with the security infrastructure (Active Directory, LDAP directories, cloud-based directory services such as Windows Azure Access Control Service, etc.) are enabled by WIF. WIF is based on a set of open-source standards, and specifically includes capability for WS-Security, WS-Trust, and WS-Federation. WIF is part of the SharePoint 2013 prerequisites, and it is automatically installed when you run the prerequisite installer.
• Security Assertion Markup Language (SAML) — SAML is a markup language that is the recognized standard for communicating identity information. WIF officially supports SAML 1.1, although support for SAML 2.0 is currently available via a Community Technical Preview (CTP) from Microsoft.
• Open Authorization 2.0 (OAuth) — OAuth is a protocol that enables users to authorize access to resources without user credentials (user ID and password, certificates, etc.). The user is required to authorize this access when it is first requested. Subsequent access is considered to be acceptable to the end user. Access is granted to specific resources for a specific duration. OAuth is the protocol used to allow SharePoint applications from the Office Store or an organization’s application store (known as the App Catalog) to access SharePoint resources on behalf of the user or the application principal. OAuth is used to allow applications that are running outside of SharePoint to access protected SharePoint resources.
• Active Directory Federated Services 2.0 — ADFS 2.0 provides both identity federation and single sign-on (SSO) solutions. ADFS is an STS. It uses Active Directory as its identity store; and Lightweight Directory Access Protocol (LDAP), SQL, or a custom store as an attribute store. ADFS is not required for SharePoint 2013, but it enables SharePoint 2013 to federate with other applications. ADFS also provides SAML 2.0 support, and it can be used with SharePoint 2013 to deliver this capability.

Claims-based authentication is user authentication that utilizes claims-based identity. Users can have identities in different directory stores and use them simultaneously to access different resources in SharePoint. Claims-based authentication is the default for SharePoint 2013. SharePoint 2013 supports Windows claims (NTLM and Kerberos), FBA claims, and SAML 1.1 claims. In order to use SAML 2.0, SharePoint 2013 must federate with ADFS, which supports both SAML 1.1 and SAML 2.0. Using claims-based authentication enables you to take advantage of all the new capabilities in SharePoint 2013.

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 6-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 6-1

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.

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. As demonstrated in Chapter 3, 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, as discussed in detail in Chapter 8, “Configuring SharePoint for 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 6-2.

TABLE 6-2: References for Configuring FBA and SAML Authentication Providers

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

Federated User Authentication Process

As collaboration boundaries expand and need for information increases, access to resources that are not hosted by your company or an organization that knows you is needed. For example, many people want to use Internet-based resources such as Facebook, Twitter, and so on. Because accessing any computer-based resources involves some type of authentication, authorization, and user administration, this greatly complicates our access requirements, and therefore our ability to access external resources. In claims terminology, the user wishes to access an application that doesn’t trust the user’s STS; but what if the application that owns the resources the user wishes to access trusts an STS that trusts the user’s STS? This is referred to as identity federation. In this scenario, an identity provider offers an STS (for example, SharePoint 2013) and another STS is offered by a federation provider (FP). The administrator configures the federation provider STS to trust the identity provider STS. As a result, the user is allowed to securely access the necessary resources even though the resources are outside his or her environment.

Users on the Internet typically interact with several common IdPs (e.g., Facebook, Microsoft ID, Yahoo, Office 365). If SharePoint 2013 or any claims-enabled application in general needed to accept identities from each of these (i.e., trust them), two different approaches could be used:

• Configure SharePoint 2013 or the application to trust each STS. Users would be presented with a list of available STSs, choose the one they want to use, and proceed to authenticate against that STS.
• Use a federation provider (FP) such as ADFS 2.0 or Windows Azure Access Control Service. The FP trusts each of these STSs and provides an abstraction layer between them and SharePoint or the application. In this case, SharePoint or the application is configured to trust only the federation provider STS.

The FP simplifies administration, especially if multiple applications need to be configured. FPs can also provide claims transformations that alter the type and number of claims. FPs are an abstraction layer that can shield an application from the peculiarities of each STS that the application needs to support. The claims transformation capabilities enable claims that originate from each different STS to be mapped to a consistent set of claims appropriate for the relying party application. Figure 6-2 shows an overview of the federated user authentication process with a FP, such as ADFS or Windows Azure Access Control Service (ACS), and a different IdP that is trusted by the FP. The following steps in the process illustrate two new key points: how an STS can act as a federation provider, accepting one token and producing another, and how one STS can trust another STS:

FIGURE 6-2

This process illustrates how one STS can trust another STS, and how federated identity can be used across environments and applications. ADFS 2.0 supports both web browsers and other clients, such as Office desktop clients and those built using Windows Communication Foundation (WCF). The ADFS 2.0 STS can be used entirely inside an organization, exposed on the Internet, or both. ADFS 2.0 is not required to use SharePoint 2013 claims-based identity. CBA or federated CBA can be implemented using an STS from any vendor, or even a custom-built STS.

Part of the beauty of this process is that users gain access to resources without explicitly logging into the desired application. Users log in to their familiar application, and they have single sign-on (SSO) with the desired application.

APPLICATION AUTHENTICATION

This section begins with a brief overview of the new Cloud App Model. Our purpose here is only to provide information pertinent to the authentication discussion, as Chapter 11, “Managing and Configuring Apps” is dedicated to this topic. This is followed by a discussion of the critical role that OAuth plays in SharePoint 2013 authentication. The section concludes with two examples that illustrate the use and process of app authentication, including a detailed discussion of the OAuth process.

Cloud App Model

The new SharePoint 2013 Cloud App Model enables developers to provide solutions, called apps in the new terminology, to extend the capabilities of SharePoint 2013. This new approach to creating customized solutions for SharePoint 2013 largely replaces the traditional approach discussed in Chapter 10, which is still available but no longer recommended. The new app model describes a new paradigm for a solution that is self-contained, installs and uninstalls easily, does not negatively impact SharePoint performance, is applicable to SharePoint 2013 on-premise or in the cloud, and is easy to use. Like it or not, this is the new world. This section describes the authentication and authorization aspects of the new app model because they are pertinent to a complete discussion of this chapter’s subject, but other aspects of the app model are covered in detail in Chapter 11. Two key points are pertinent to our discussion:

• SharePoint apps refer to complete solutions for customizing SharePoint 2013 that were created using the new app model.
• SharePoint apps require claims authentication on the SharePoint web application.

SharePoint apps can be obtained from one of two sources: the Office Store (sometimes also referred to as the SharePoint Store), located publically on the Internet and managed by Microsoft, and an enterprise application store located inside the SharePoint 2013 farm known as the app catalog. An app catalog is created within a SharePoint 2013 web application. The important point here is that these app locations are installation points for the app; the app is not installed in the store. The store is where administrators and any users with the proper permissions go to install an app, or download the app for inclusion in the app catalog.

One of the key drivers for the new app model is to ensure that SharePoint apps do not negatively affect the performance of the SharePoint environment, and therefore they are applicable to both on-premises environments owned by corporations, and public, multi-tenant environments such as Office 365. This is accomplished by not allowing any of the actual code from the app to be installed inside the SharePoint environment; SharePoint does not host the app. The SharePoint app is hosted in one of three places:

• Provider-hosted — This type of app is hosted on a separate set of servers from the SharePoint farm. These servers can be located on-premise as part of the corporate enterprise or hosted in the cloud.
• Autohosted in Windows Azure — This is only available for SharePoint 2013 online, which is part of Office 365. The app runs as a web role in Windows Azure, and uses ACS to obtain the security token.
• SharePoint-hosted — The app is hosted in a SharePoint 2013 website that is part of the site collection where the app is installed. This has historically been referred to as a subsite, but in the app model it is referred to as a subweb or app web. In a multi-tenant scenario such as SharePoint 2013 Online, the app runs in the app catalog.

The administrator should note that apps running on-premise are either provider-hosted or SharePoint-hosted. Every authentication method is supported by on-premises apps with one very notable exception: SAML authentication is supported only for certain identity providers. For additional details, see the Microsoft plan for app authentication in SharePoint 2013 at http://technet.microsoft.com/en-us/library/jj219806(v=office.15).aspx.

OAuth

The flexibility of the app model means that components of an application could be in SharePoint, on an app server on the corporate intranet, or hosted on the public Internet. If these components request secured SharePoint resources, then these requests need to be authenticated. SharePoint 2013 uses OAuth 2.0 to allow applications to access SharePoint resources in one of three ways:

• With the combined permissions of the application and the user
• With only the permissions of the application
• With only the permissions of the user

Resource access is enabled by defining a trust relationship between the application and SharePoint 2013. If necessary, it also uses a relationship between SharePoint 2013 and Windows Azure Access Control Service (ACS). These trust relationships are very similar to how SharePoint interacts with an STS in the user authentication scenario. Note the following key points about OAuth’s role in SharePoint authentication:

• OAuth enables users to approve an application to act on their behalf without sharing their username and password.
• OAuth is used only for access tokens that are used to retrieve data from SharePoint 2013. In the context of the app model, this means it is used to authorize app requests for SharePoint resources.
• App permissions are based on trust, and are granted upon initial installation of the app.
• Apps installed from the SharePoint Store can use ACS as its STS.
• OAuth is not used for user authentication.
• OAuth is used as part of the server-to-server authentication capability, which is discussed later in the chapter.
• OAuth is used as part of the “app authentication” process, which is discussed in the next section.

App Authentication

Note that some of the public documentation on TechNet and MSDN uses the terminology app authentication to include both authentication of the app by a trusted STS and authorization of both the app and the associated user when the app requests access to a secured SharePoint resource. Administrators should be aware that the first part of the process is very similar to the claims authentication of a user, while the latter part is the OAuth portion of the process. In other words, OAuth is an authorization protocol, but in some ways it is very similar to user authentication. Once users are authenticated, the next step is to authorize them, as the goal is to provide users with access to resources. Likewise with the app, app authentication should be followed by app authorization, as the goal is to provide the app with access to SharePoint content.

App authentication is required when an external component of an app needs access to SharePoint resources — for example, a SharePoint Store app or an app catalog app, such as a web server that is located on the intranet or the Internet, attempts to access a secured SharePoint resource. For instance, an app that includes a component that runs in Windows Azure is an external app. App authentication enables a new set of functionality and scenarios that can be achieved by allowing an app to include data from SharePoint resources in the results that the app processes and displays for users.

To provide the app access to SharePoint resources, SharePoint must perform app authentication. SharePoint 2013 must be explicitly configured to allow external app functionality access to resources. Specifically, this includes the following:

To summarize, app authentication requires the SharePoint farm to be configured with an app authentication trust, the app to be registered with the Application Management service, and app permissions to be configured. Now let’s look at an example of app authentication.

SharePoint Store App Authentication

This example demonstrates installing an app from the SharePoint Store, and using ACS as the STS. Your on-premises SharePoint farm can use an external STS, such as ACS, and in general SharePoint can be configured to trust many different token providers. SharePoint needs to be configured to trust ACS, and the example also illustrates how to grant explicit permissions to the app. The OAuth process for granting the app access to SharePoint resources is shown in Figure 6-3. In order for the OAuth process to proceed successfully, you must configure SharePoint 2013 to trust ACS. First, however, there are a few PowerShell cmdlets that need to be run to establish the ACS trust and register the app as discussed earlier in the previous section.

FIGURE 6-3

Step 1 is necessary whenever you want to configure SharePoint to trust an external STS. In this example, SharePoint is being configured to trust the ACS instance that corresponds to your Office 365 account. You may be wondering why you need an Office 365 subscription. Recall that app authentication requires verifying the authenticity of both the app and the user. If you already have an Office 365 tenant, then your identity is already being verified using ACS as part of your subscription. App identity verification is accomplished using ACS because the app has chosen to use ACS as its identity provider STS. Steps 2 and 3 complete the app authentication process by registering the app with the Application Management service and explicitly assigning permissions to the app. These steps are discussed in much more detail in Chapter 11 if you need additional information.

New-SPTrustedSecurityTokenIssuer
   –MetadataEndpoint "<Metadata endpoint URL of ACS>"
   –IsTrustBroker –Name "ACS"

The value for "<metadata endpoint URL of ACS>" is https://accounts.accesscontrol.windows.net/metadata/json/1/?realm=<contextID property of your Office 365 subscription>. This metadata endpoint URL value and the value of your "<contextID property of your Office 365 subscription>" are discussed in the document “sps-2013-config-one-way-hybrid-environment.docx,” which you can download from http://www.microsoft.com/en-us/download/details.aspx?id=35593.

$spsite = Get-SPSite "https://<url_of_site>"
$appPrincipal = Register-SPAppPrincipal
   -NameIdentifier <app principal name> -Site $spsite
   -DisplayName "My Office 365 App"

$spsite = Get-SPSite "https://<url_of_site>"
Set-AppPrincipalPermission -appPrincipal $appPrincipal
   -site $spsite
   -right <Level> -scope <Scope>

Now that the app authentication has been configured, the following steps walk through the OAuth process for this example:

You might need to review the process a couple of times because it is quite involved, but it will be worth the effort.

App Catalog App Authentication

This example illustrates the second approach to app authentication. In this case, your app is hosted on-premises in servers that are not a part of the SharePoint farm, and not in the cloud as in the previous example. The app has been deployed to the SharePoint app catalog; app catalogs are deployed to web applications in SharePoint 2013. Apps in the app catalog are assumed to be more trustworthy than those external to SharePoint, so the app authentication process is different.

For this scenario, you need to configure a server-to-server trust relationship between SharePoint and the app. This type of configuration is also referred to as a high-trust app, which is an example of a provider-hosted app for use on the premises; it is not intended to be used in a cloud-hosted environment. Administrators should not be misled by the terminology “high trust,” so the following should further clarify what this means:

• A high-trust app does not have “full trust” access, and must still request and be granted access to SharePoint resources.
• The app is considered “high-trust” because it is trusted to impersonate a user (aka “asserting a user’s identity”), and it is responsible for creating the user portion of the access token.
• A high-trust app uses a certificate instead of a context token to establish trust.

Figure 6-4 shows the process for app authentication in this scenario, as described in the following steps. The SharePoint configuration is more involved in this scenario, so administrators are referred to Chapter 11 for details, or to http://msdn.microsoft.com/en-us/library/fp179901(v=office.15).aspx#Configure.

FIGURE 6-4

As you can see, even though the actual SharePoint configuration is more involved in the second example, the OAuth process is much simpler. This should be expected, as an app that has been deployed to the app catalog should be trusted to a much greater extent than one that is hosted outside of the organization. This example was a good warm-up for the next section, which delves more deeply into S2S authentication and gives examples of how it is useful to enable different servers to share information.

SERVER-TO-SERVER AUTHENTICATION

Server-to-Server authentication (S2S) represents an example of application-to-application OAuth. This approach uses a Microsoft extension of the OAuth protocol to enable applications or servers to share resources on behalf of users, without user authentication. This is achieved using a trusted connection between applications. As you saw in the last example of the preceding section, this type of configuration can be used when deploying a developer-hosted app in a private network to avoid any dependencies on ACS or any other servers running across the Internet. The S2S process is essentially an access request and access granting process between two S2S-compliant applications or servers. The criteria to share resources between two compliant servers include the following:

• The application or server requesting the resources must be trusted.
• The application or server requesting the resources must have the proper permissions.

Do these criteria look familiar? They should, as they are exactly the same criteria you saw previously for app authentication. Just as SharePoint 2013 has a native STS for user authentication, SharePoint 2013 also has another STS dedicated to provide server-to-server security tokens. A trust established between the SharePoint 2013 STS and any other S2S-compliant server or services enables the sharing of resources. For on-premises deployments, the key step that configures the trust relationship involves establishing the JavaScript Object Notation (JSON) meta data endpoint of the other S2S-compliant service. This is accomplished using the New-SPTrustedSecurityTokenIssuer cmdlet.

S2S-compliant servers include SharePoint Server 2013, Exchange Server 2013, Lync Server 2013, Azure Workflow Server, or any other software that supports the Microsoft server-to-server protocol. Server-to-server authentication enables a new set of functionality and scenarios, such as the new eDiscovery capability in SharePoint 2013 and Exchange 2013. It also enables information from one SharePoint 2013 farm to be retrieved and displayed from another SharePoint 2013 farm. This is discussed in the next section.

SharePoint to SharePoint S2S

The SharePoint 2013 to SharePoint 2013 configuration is the simplest S2S scenario. It requires configuring a one-way trust between the server receiving the requests and the server that will be sending them. Detailed documentation about the configuration is provided at http://technet.microsoft.com/en-us/library/jj655400.aspx, so here we will only show the key PowerShell command that makes it all possible, New-SPTrustedSecurityTokenIssuer:

New-SPTrustedSecurityTokenIssuer –MetadataEndpoint
   "https://<HostName>/_layouts/15/metadata/json/1"
   –IsTrustBroker –Name "<FriendlyName>"

The parameter <HostName> is the name and port of the SSL-enabled SharePoint web application of the farm that will be sending S2S requests, and the <FriendlyName> parameter is a friendly name for the SharePoint 2013 farm that is sending S2S requests. It is recommended that OAuth communication occur over SSL, but it can be configured using PowerShell to use HTTP for lab environments. Administrators responsible for configuring app authentication and S2S will become very familiar with this PowerShell cmdlet. Figure 6-5 shows the inter-server communication process, which is described in the following steps:

FIGURE 6-5

SharePoint to Exchange and Lync S2S

The S2S process for sharing information between SharePoint 2013 and Exchange 2013, and SharePoint 2013 and Lync 2013, is the same but the configuration is more involved. Table 6-3 contains references to TechNet articles that describe the configuration process in detail, so we will not repeat that discussion here. The configuration process details the steps required to establish two, one-way trusts. These two, one-way trusts are necessary to support SharePoint consuming information from Exchange and Lync, as well as Exchange and Lync consuming information from SharePoint.

TABLE 6-3: Configuring S2S Between SharePoint 2013 and Another Server

We discuss configuring SharePoint 2013 and Azure Workflow Server (AWS) in Chapter 16, “Installing and Configuring Azure Workflow Server.” AWS is the new workflow capability for SharePoint 2013. Despite the name, AWS can be used on-premises, and it can be hosted on a server that is part of the SharePoint 2013 farm or separately. S2S is a great new addition to the claims authentication capability of SharePoint, and it will provide new authentication approaches for non-SharePoint applications.

SUMMARY

The subject of claims authentication is vast, and providing all the necessary information and background would require an entire book. The overview provided in this chapter focused on the key areas and new features of interest to administrators. Unlike SharePoint 2010, SharePoint 2013 doesn’t introduce a new user authentication technology, but it does include changes and enhancements. This chapter covered key definitions and terminology, and provided some insight into the actual user authentication process. It also introduced the new application authentication capability, whether that uses app authentication or S2S. SharePoint 2013 is adopting more standards with each release. OAuth is the most recent example of standards adoption, and it is at the core of the new app model and S2S authentication. Claims and OAuth open doors to many new, valuable scenarios. Bottom line: Claims authentication is here to stay, and it has become a critical player in the overall architecture and operation of SharePoint 2013.