Plan SharePoint 2013

Planning for solutions Planning for server farm architecture
Plan user profiles and identities (SharePoint Server 2013)    Find the set of overview and planning topics for user profiles and identities for SharePoint Server 2013. System requirements for SharePoint 2013    Find information about hardware requirements, software requirements, browser support, and IP support for SharePoint 2013.
Plan for social computing and collaboration in SharePoint Server 2013    Learn how to plan for social computing and collaboration in SharePoint Server 2013. Plan logical architectures for SharePoint 2013    Use the SharePoint design samples and architectural guidance to plan an architecture for a SharePoint 2013 deployment.
Plan document management in SharePoint 2013    Learn about the document management features of a solution based on SharePoint Server 2013. Plan for on-premises or hosted virtualization in SharePoint 2013    Create a well-designed plan to install and configure SharePoint 2013 in a virtual environment.
Plan digital asset libraries in SharePoint Server 2013    Find links to articles and related resources that can help you plan digital asset libraries in SharePoint Server 2013. Plan authentication in SharePoint 2013    Find resources about user authentication, server-to-server authentication, and app authentication to help you understand and plan for authentication in SharePoint 2013.
Plan records management in SharePoint Server 2013   Learn about records management in SharePoint Server 2013. Permissions planning for sites and content in SharePoint 2013    Learn about how to plan permissions for sites and site content for SharePoint 2013.
Plan eDiscovery in SharePoint Server 2013    Find links to articles about eDiscovery in SharePoint Server 2013. Overview of backup and recovery in SharePoint 2013    Understand backup and recovery scenarios, the backup architecture, and recovery processes before you plan to back up and restore SharePoint 2013.
Plan web content management in SharePoint Server 2013    Learn how to plan publishing sites by using SharePoint Server 2013 features. Plan for backup and recovery in SharePoint 2013    Learn how to plan backup and recovery strategies for your SharePoint 2013 environment.
Plan search in SharePoint Server 2013    Create a well-designed plan to install and configure search in SharePoint 2013. Plan for monitoring in SharePoint 2013   Learn about SharePoint monitoring tools and scenarios. Plan schedules and create a response plan to keep the SharePoint farm running.
Plan managed metadata in SharePoint Server 2013    Learn about managed metadata and taxonomy in SharePoint Server 2013. Plan for high availability and disaster recovery for SharePoint 2013    Create a well-designed high availability plan and a disaster recovery plan that meets business goals and objectives.
Plan for business intelligence in SharePoint Server 2013    Learn about how SharePoint Server 2013 implements business intelligence to analyze data. SQL Server and storage (SharePoint 2013)    Learn how to plan for SQL Server 2008 R2 with Service Pack 1 (SP1) and SQL Server 2012 and storage configuration for SharePoint 2013.
Plan for Business Connectivity Services in SharePoint 2013    Learn to plan to use Microsoft Business Connectivity Services to access external data in SharePoint Server 2013. Security planning for SharePoint 2013 farms    Learn about how to plan SharePoint 2013 security for server farms.
Plan for Access Services in SharePoint Server 2013    Learn how to use Access Services in SharePoint Server 2013 to share solutions on the web.
Plan email integration for a SharePoint farm in SharePoint 2013    Learn how to plan for email integration in SharePoint 2013.
Plan for mobile devices in SharePoint 2013    Learn how to plan for your SharePoint Server 2013 mobile infrastructure.
Fundamental site planning in SharePoint 2013    Learn about site collections, sites, and site templates in SharePoint 2013.
Governance planning in SharePoint 2013 Find resources about governance in SharePoint Server 2013. Learn about governing IT services, information management, and application management.
Getting started with SharePoint Server 2013 workflow    Read a high-level view of the SharePoint 2013 Workflow platform.
Plan for administrative and service accounts in SharePoint 2013    Learn about the accounts to use to manage SharePoint 2013 deployment scenarios and services.
Advertisements

Authentication SharePoint 2013

Content Description
Authentication overview for SharePoint 2013 Learn about how user, app, and server-to-server authentication works in SharePoint 2013.
Plan for user authentication methods in SharePoint 2013 Plan how to use various user authentication methods in SharePoint 2013 to help create a secure experience for users of web applications.
Plan for app authentication in SharePoint 2013 Plan for authentication of SharePoint 2013 SharePoint Store and App Catalog apps.
Plan for server-to-server authentication in SharePoint 2013 Plan for server-to-server authentication for SharePoint 2013 and other servers that support the server-to-server protocol.
Plan the Secure Store Service in SharePoint Server 2013 Plan for Secure Store Service and service application requirements, and for target applications and credential mappings.
Plan for Kerberos authentication in SharePoint 2013 Plan for Kerberos authentication in SharePoint 2013 for Windows and claims-based authentication.
Server-to-server authentication and user profiles in SharePoint Server 2013 Plan user profiles for server-to-server authentication in SharePoint Server 2013.

Authentication overview for SharePoint 2013

how user, app, and server-to-server authentication works in SharePoint 2013.

SharePoint 2013 requires authentication for the following types of interactions:

•Users who access on-premises SharePoint resources

•Apps that access on-premises SharePoint resources

•On-premises servers that access on-premises SharePoint resources, or vice versa

User authentication in SharePoint 2013

User authentication is the validation of a user’s identity against an authentication provider, which is a directory or database that contains the user’s credentials and can verify that the user submitted them correctly. User authentication occurs when a user attempts to access a SharePoint resource.

SharePoint 2013 supports two authentication types for user authentication:

•Claims-based authentication

•Windows classic mode authentication

The result of a claims-based authentication is a claims-based security token, which the SharePoint Security Token Service (STS) generates. The result of a Windows classic mode authentication is a Windows security token. We recommend that you use claims-based authentication for user authentication.

SharePoint 2013 supports Windows, forms-based, and Security Assertion Markup Language (SAML)-based claims authentication

App authentication in SharePoint 2013

App authentication is the validation of a remote SharePoint app’s identity and the authorization of the app and an associated user of a secured SharePoint resource request. App authentication occurs when an external component of 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 example, suppose that a user opens a SharePoint page that contains an IFRAME of a SharePoint app, and that IFRAME needs an external component, such as a server on the intranet or the Internet, to access a secured SharePoint resource in order to render the page. The external component of the SharePoint app must be authenticated and authorized so that SharePoint provides the requested information and the app can render the page for the user.

Note that if the SharePoint app does not require a SharePoint secured resource to render the page for the user, app authentication is not needed. For example, a SharePoint app that provides weather forecast information and only has to access a weather information server on the Internet does not have to use app authentication. This type of application can be done with SharePoint 2010 Products.

App authentication is a combination of two processes:

•Authentication

Verifying that the application has registered correctly with a commonly trusted identity broker

•Authorization

Verifying that the application and the associated user for the request has the appropriate permissions to perform its operation, such as accessing a folder or list or executing a query

To perform app authentication, the application obtains an access token either from the Microsoft Azure Access Control Service (ACS) or by self-signing an access token using a certificate that SharePoint 2013 trusts. The access token asserts a request for access to a specific SharePoint resource and contains information that identifies the app and the associated user, instead of the validation of the user’s credentials. The access token is not a logon token.

For SharePoint Store apps, an example of the authentication process is as follows:

1.A user opens a SharePoint web page that contains an IFRAME that has to be rendered by a SharePoint Store app, which is hosted on the Internet and uses ACS as its trust broker. To render the IFRAME for the user, the SharePoint Store app must access a SharePoint resource.

2.The SharePoint STS requests and receives a context token from ACS.

3.SharePoint sends the requested web page together with the context token to the user’s web browser.

4.The user’s web browser sends a request for the IFRAME’s content and the context token to the SharePoint Store app server on the Internet.

5.The SharePoint Store app server requests and receives an access token from ACS.

6.The SharePoint Store app server sends the SharePoint resource request and the access token to the SharePoint server.

7.The SharePoint server authorizes the access, checking both the app’s permissions, which were specified when the app was installed, and the associated user’s permissions.

8.If permitted, SharePoint sends the requested data to the SharePoint Store app server on the Internet.

9.The SharePoint Store app server on the Internet sends the IFRAME results to the web browser, which renders the IFRAME portion of the page for the user.

Notice how the SharePoint Store app has accessed SharePoint server resources without having to obtain the user’s credentials. The access was authenticated through ACS, which is trusted by the server running SharePoint 2013, and authorized through the set of app and user permissions.

For SharePoint App Catalog apps, an example of the authentication process is as follows:

1.A user opens a SharePoint web page that contains an IFRAME that has to be rendered by an App Catalog app that is hosted on the intranet and uses a self-signed certificate for its access tokens. To render the IFRAME for the user, the App Catalog app must access a SharePoint resource.

2.SharePoint sends the requested page along with the IFRAME to the user’s web browser.

3.The user’s web browser sends a request for the IFRAME’s content to the App Catalog app server on the intranet.

4.The App Catalog app server authenticates the user and generates an access token, signed with its self-signed certificate.

5.The App Catalog app server sends the SharePoint resource request and the access token to the SharePoint server.

6.The SharePoint server authorizes the access, checking both the app’s permissions, which were specified when the app was installed, and the associated user’s permissions.

7.If permitted, the SharePoint server sends the requested data to the App Catalog app server on the intranet.

8.The App Catalog app server sends the IFRAME results to the web browser, which renders the IFRAME portion of the page for the user.

Note : App Catalog apps can use either ACS or a self-signed certificate for their access tokens.

Server-to-server authentication in SharePoint 2013

Server-to-server authentication is the validation of a server’s request for resources that is based on a trust relationship established between the STS of the server that runs SharePoint 2013 and the STS of another server that supports the OAuth server-to-server protocol, such as on-premises running SharePoint 2013, Exchange Server 2013, Lync Server 2013, or Azure Workflow Service, and SharePoint 2013 running in Office 365. Based on this trust relationship, a requesting server can access secured resources on the SharePoint server on behalf of a specified user account, subject to server and user permissions.

For example, a server running Exchange Server 2013 can request resources of a server running SharePoint 2013 for a specific user account. This contrasts with app authentication, in which the app does not have access to user account credential information. The user can be currently signed in to the server making the resource request or not, depending on the service and the request.

When a server running SharePoint 2013 attempts to access a resource on a server or a server attempts to access a resource on a server running SharePoint 2013, the incoming access request must be authenticated so that the server accepts the incoming access request and subsequent data. Server-to-server authentication verifies that the server running SharePoint 2013 and the user whom it is representing are trusted.

The token that is used for a server-to-server authentication is a server-to-server token, not a logon token. The server-to-server token contains information about the server that requests access and the user account on whose behalf the server is acting.

For on-premises servers, an example basic process is as follows:

1.A user opens a SharePoint web page that requires information from another server (for example, display the list of tasks from both SharePoint 2013 and Exchange Server 2013).

2.SharePoint 2013 generates a server-to-server token.

3.SharePoint 2013 sends the server-to-server token to the other server.

4.The other server validates the SharePoint server-to-server token.

5.The other server sends a message to SharePoint 2013 to indicate that the sent server-to-server token was valid.

6.The service on the server running SharePoint 2013 accesses the data on the server.

7.The service on the server running SharePoint 2013 renders the page for the user.

When both servers are running in Office 365, an example process is as follows:

1.A user opens a SharePoint web page that requires information from another server (for example, display the list of tasks from both SharePoint Online and Exchange Online).

2.SharePoint Online requests and receives a server-to-server token from ACS.

3.SharePoint Online sends the server-to-server token to the Office 365 server.

4.The Office 365 server verifies the user identity in the server-to-server token with ACS.

5.The Office 365 server sends a message to SharePoint Online to indicate that the sent server-to-server token was valid.

6.The service on SharePoint Online accesses the data on the Office 365 server.

7.The service on SharePoint Online renders the page for the user.