Designing a Microsoft SharePoint 2010 Infrastructure Vol 1 part 32 ppsx

MCT USE ONLY. STUDENT USE PROHIBITED Planning Authentication 6-13 authentication enables user authentication that is based on validation of credential input from a logon form. Unauthenticated requests are redirected to a logon page, where the user must provide valid credentials and submit the form. If the request can be authenticated, the system issues a cookie that contains a key for reestablishing the identity for subsequent requests. Configuring Forms-Based Authentication Using forms-based authentication as an authentication method for users requires some configuration. You must register the membership provider in the Web.config file, and you can also register a role manager. SharePoint 2010 uses the ASP.NET role manager interface to gather group information about the current user; the authorization process treats each ASP.NET role as a domain group. You can also manage membership providers and role managers through SharePoint 2010 Central Administration. You must register the membership provider and the role manager in the Web.config file for the Central Administration site in addition to registering these in the Web.config file for the Web application that hosts the content. Integrating with forms-based authentication places additional requirements on the authentication provider. In addition to registering the various elements in the Web.config file, you must program the membership provider, role manager, and HTTP module to interact with SharePoint 2010 and ASP.NET methods. Forms-based authentication passes credentials over HTTP, so using SSL to encrypt this traffic is highly recommended. Additional Reading For more information about how to plan authentication methods, see http://go.microsoft.com/fwlink/?LinkID=200884&clcid=0x409. For more information about how to configure forms-based authentication in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=201239&clcid=0x409.  MCT USE ONLY. STUDENT USE PROHIBITED 6-14 Designing a Microsoft® SharePoint® 2010 Infrastructure Secure Store Service Authorization Key Points In SharePoint 2010, the Secure Store Service replaces the SSO feature. The Secure Store Service is a claims-aware authorization service that includes a secure database for storing credentials that are associated with application IDs. Applications use these application IDs to authorize access to external data sources and other resources. The Secure Store Service runs on an application server, providing a database that is used to store user identities and passwords for application IDs. The Secure Store Service provides support for storing the credentials of multiple systems by using multiple application IDs. Application IDs and Mappings Each Secure Store Service entry includes an application ID that is used to retrieve a set of credentials from the secure store database. Application IDs are used to map users or groups to credential sets. Applications use application IDs to retrieve credentials from the secure store database on behalf of a user. The application can then use the retrieved credentials to access a data source. MCT USE ONLY. STUDENT USE PROHIBITED Planning Authentication 6-15 In a group mapping, every user who is a member of a specific domain group is mapped to the same set of credentials. In an individual mapping, each individual user is mapped to a unique set of credentials. Secure Store Service Mappings Individual mappings are useful if you require logging information about individual user access to shared resources. For group mappings, a security layer checks group credentials for multiple domain users against a single set of credentials for a resource; an application ID that is stored in the secure store database identifies this resource. Group mappings are easier to maintain than individual mappings and can provide improved performance. MCT USE ONLY. STUDENT USE PROHIBITED 6-16 Designing a Microsoft® SharePoint® 2010 Infrastructure Lesson 2 Planning a Claims-Based Authentication Topology SharePoint 2010 incorporates a new, more powerful and flexible authentication model that works with any corporate identity system, including Active Directory, LDAP-based directories, application-specific databases, and new user-centric identity models such as LiveID. Claims-based authentication is built around the concepts of claims, identities, and identity providers. Claims-based authentication provides a common way for applications to acquire identity information from users inside their organization, in other organizations, or on the Internet. Identity information is contained in a security token. A security token contains one or more claims about the user. This metadata about the user stays with them throughout their session. Claims-based authentication is new to SharePoint 2010, so this lesson covers claims-based authentication architecture and topologies in detail. MCT USE ONLY. STUDENT USE PROHIBITED Planning Authentication 6-17 Objectives After completing this lesson, you will be able to: • Describe the claims-based authentication architecture. • Describe the claims-based authentication topology for a single farm. • Describe the claims-based authentication topology for multiple farms. MCT USE ONLY. STUDENT USE PROHIBITED 6-18 Designing a Microsoft® SharePoint® 2010 Infrastructure Claims-Based Authentication Architecture Key Points The architecture of claims-based authentication consists of claims, identities, and identity providers. The relationship between these elements is described in the following sections. Claims A claim is a piece of information that is asserted about an object. The assertion is made either by the subject itself or by another object. Usually, users make claims about themselves, although applications, computers, and external systems can also make claims. Each claim is information that identifies the object: it may be an e- mail address, a user name, or membership of a group or role. The subject may assert several claims, presenting several pieces of information to gain access to multiple resources. Although claims are attributes of an object, the term claim is used because of the way in which the information is presented. Claims are a proactive way for the subject to present information to be used for validation. The application that receives the claims does not have to look up the required attributes in a directory service; the requesting object presents them. MCT USE ONLY. STUDENT USE PROHIBITED Planning Authentication 6-19 Each claim is made by an issuer, and the application trusts the claim only as much as it trusts the issuer. For example, a claim that a domain controller makes is trusted more than a claim that the user makes. The claims application programming interface (API) has an issuer property that enables the application to find out who issued the claim. Identities A set of claims is given one or more values and then packaged in security tokens that a Security Token Service (STS) issues. Tokens express information about a specific entity. This information consists of one or more claims, each of which contains some information about the subject to which this token applies. The claims in a token commonly contain many sorts of information; claims are not limited to, and may not necessarily include, a subject's name. An application that receives a token does not automatically accept the information that it contains. Instead, a received token is validated before an application uses any claims that it contains. The key concept is that a claim is not just a unique identifier that identifies the resource, application, or user. It is a set of values that is used to describe the resource, application, or user. The claims are also used to authorize access. Identity Providers The identity provider is the STS, which packages and then issues the claim. The STS gathers its information from an attribute store that contains the information about the user. The attribute store can be Active Directory Domain Services, a SQL Server database, an LDAP store, or a Windows Live® ID. The content of each security token is determined by the requirements of the authentication requests that are agreed upon by an STS and the SharePoint application. An agreed-upon collection of claims and claim rules is a policy. Policies are available in a policy store and are accessed by an STS. The STS functions as an identity provider and creates the token that encapsulates the subject’s claim. If the STS and the Web application are in the same SharePoint farm, the STS functions as a local Identity Provider STS (IP-STS). If the STS and the Web application are in different farms, the STS functions as a Relying Party SPS. If the IP-STS and the Web application are in the same SharePoint farm, the IP-STS provides security tokens to authenticated users whose attributes are available in local attribute stores. MCT USE ONLY. STUDENT USE PROHIBITED 6-20 Designing a Microsoft® SharePoint® 2010 Infrastructure If the IP-STS and the Web application are in different SharePoint farms, a Relying Party STS is used, which has a trust relationship with an IP-STS. A Relying Party STS and a Web application are in different SharePoint farms. As a result of this trust relationship, the Relying Party STS can authorize an external user whose credentials are not stored locally, so long as an IP-STS issues a valid security token for that user. MCT USE ONLY. STUDENT USE PROHIBITED Planning Authentication 6-21 Authentication Topologies for Single Farms Key Points The topology for claims-based authentication in a single farm consists of a local STS, which is local to the SharePoint farm. The authentication process is as follows: 1. An internal user whose credentials are directly accessible by the local STS requests authentication. 2. The Web application responds to the authentication request with a redirect to the local STS. 3. The authentication request is submitted to, and processed by, the local STS. 4. The STS finds the policy for the requesting Web application in the policy store and creates a token for the requesting user by using identity assertion values in the attribute store. MCT USE ONLY. STUDENT USE PROHIBITED 6-22 Designing a Microsoft® SharePoint® 2010 Infrastructure 5. A valid security token is returned to the user and then submitted to the Web application. 6. The Web application authenticates the user. In this example, the Web application returns a cookie to the user. . PROHIBITED 6 -16 Designing a Microsoft SharePoint 2 010 Infrastructure Lesson 2 Planning a Claims-Based Authentication Topology SharePoint 2 010 incorporates a new, more powerful and flexible authentication. IP-STS and the Web application are in different SharePoint farms, a Relying Party STS is used, which has a trust relationship with an IP-STS. A Relying Party STS and a Web application are in. PROHIBITED 6 -18 Designing a Microsoft SharePoint 2 010 Infrastructure Claims-Based Authentication Architecture Key Points The architecture of claims-based authentication consists of claims, identities,