WHAT’S IN THIS CHAPTER?
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.
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.
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:
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.”
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.
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:
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 (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:
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.
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.
Users new to claims-based identity routinely ask the same set of questions:
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 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:
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.
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 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:
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.
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.
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.
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:
TECHNOLOGY | DESCRIPTION |
Windows Identity Foundation (WIF) | A set of application programming interfaces (APIs) that can be used by developers to build claims-aware and federation-capable applications. WIF provides a framework to claims-enable your applications and to create custom security token services. This enables enterprises to use a single identity model so that applications can communicate and interoperate using industry standard protocols. See http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=17331. |
ADFS 2.0 | Provides both identity federation and single sign-on (SSO) solutions. ADFS 2.0 is a security token service (STS) responsible for issuing security tokens. It uses Active Directory as its identity store; and Lightweight Directory Access Protocol (LDAP), SQL, or a custom store as an attribute store. ADFS 2.0 supports both active (WS-Trust) and passive (WS-Federation and SAML 2.0) scenarios. ADFS 2.0 supports SAML 1.1 and SAML 2.0. Windows Server 2012 includes ADFS 2.1. |
Claim | A claim is an identity assertion about the user, but in general it is any piece of information that describes a characteristic of the user. |
Security token | A token, or security token, represents a collection (one or more) of claims and a digital signature. The token is digitally signed to protect against unauthorized claim changes. |
Secure Store Service (STS) | Creates and issues security tokens. The STS is a web service that issues tokens as defined by the WS-Trust security standard. |
Identity provider | Any organization that backs the STS, ensures that the claims are authentic, and authenticates the user. |
Relying party | An application that accepts and uses a security token. The application has been configured to trust the STS and is relying on the information contained in the claims. |
WS-Security | The protocol that defines a security token and how to include and/or refer to one in a SOAP message. |
WS-Trust | Deals with the issuing, validating, and renewal of security tokens. It also defines the concept of a Security Token Service (STS), and how to request a security token directly from the service, including the format of messages used to request and respond. |
WS-Federation | Specifies the process for sending and receiving WS-Trust messages via a web browser (passive profile) and SOAP clients (active profile). |
Security Assertion Markup Language | SAML is an XML-based standard for exchanging authentication and authorization data between applications and services. SAML tokens are XML representations of claims. |
SAML Protocol | Defines message patterns for requesting and receiving SAML security tokens from a Security Token Service. |
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.
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.
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:
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.
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 |
Several scenarios require the use of additional identity capability. One such example is federated user authentication, which is discussed in the next section.
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:
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:
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.
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.
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 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:
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.
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:
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:
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.
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.
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.
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:
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.
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 (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:
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.
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:
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.
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.
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.
3.145.179.59