Thủ thuật Sharepoint 2010 part 36 pot

Claims-Based Authentication WHAT’S IN THIS CHAPTER? Using claims-based identity  SharePoint authentication options  Creating claims-based web applications  SharePoint Server 2010 utilizes a new authentication model called claims-based authentication (CBA). CBA is based on the concept of identity and utilizes open source standards and proto- cols so that it works with any corporate identity system, not just Active Directory and not just Windows-based systems. Identity is represented by 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 verifi ed by some system. This is normally some directory service that contains username and password information, but the beauty of CBA is that it is not limited to just username and password information. CBA provides a trust-based system between applications and a centralized provider that issues the token. The application trusts the individual because they trust the provider. Therefore, in addition to providing a single sign-on environment, this alleviates 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. This chapter is an introduction to CBA, and it will provide you with the knowledge necessary to begin using CBA for SharePoint websites. CLAIMSBASED IDENTITY User identity is a fundamental requirement for application security, 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 deciding which identity technology is the right one for a specifi c application, and then which one is the best 9 228  CHAPTER 9 claims-Based aUtheNticatioN across the enterprise so that you can accommodate the needs of all the applications. The solution to this 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 Challenge Will the application be accessed by employees from within the organization, from outside the organi- zation, from the public Internet? One technology may not be enough and the organization may have to support multiple technologies. For example, you could use Windows Integrated security for inter- nal users and Forms-Based Authentication (FBA) for users outside the organization; but we all know the complexity this introduces 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. And what about providing access to partner or vendor employees? For that you need to implement identity federation, so that the users won’t need a separate login. 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 the premises and in the cloud. User Information Storage Challenge 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. Solution After this brief review of two key challenges, you are probably thinking that the solution is simple. Why not create a single identity approach for all scenarios that provides each application with the specific information it needs? If so, you guessed correctly. Claims-based identity satisfies these requirements. 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. Identity information is stored in a security token, often simply called a token. A token contains one or more claims about the user. Think of a claim as metadata about the user that stays with them through- out their enterprise journey. For example, this could include username, manager’s name, address, e-mail address, group memberships, etc. Implementing claims-based identity generally requires using and understanding a set of core technolo- gies: Windows Identity Foundation (WIF), Active Directory Federated Services 2.0 (ADFS), and Claims-Based Identity  229 CardSpace 2.0. WIF is part of the SharePoint 2010 prerequisites, and it is automatically installed when you run the prerequisite installer as discussed in Chapter 4. The claims-based technologies are summa- rized in Table 9-1. Don’t worry if the table contains unfamiliar terms, as they are further defined in subsequent sections of this chapter. TABLE 91 Claims-Based Identity Technology for the Windows Platform TECHNOLOGY DESCRIPTION Windows Identity Foundation WIF, which was formerly called the “Geneva Framework,” is 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 com- municate and interoperate using industry standard protocols. ADFS 2.0 ADFS 2.0, formerly called “Geneva Server,” 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. Windows CardSpace 2.0 Windows CardSpace, formerly code-named “InfoCard,” is an identity selector technology that can replace usernames and passwords that you use to register with and log on to websites and online services. CardSpace stores users’ digital identities, and represents the identity information in visual Information Cards. This enables users to share information with sites, review the identity of a site, and manage their digital information. Claims-based authentication is user authentication that utilizes claims-based identity, and it opens the door to great possibilities in SharePoint Server 2010. Users can have identities in different direc- tory stores and use them simultaneously to access different resources in SharePoint. Using Claims Identity for Authentication SharePoint 2010 supports claims-based authentication, which is a powerful and flexible authentica- tion model. Claims-based authentication (CBA) in SharePoint 2010 works with a variety of identity systems, such as Active Directory, LDAP directories, and even LiveID. CBA uses several different technology components to authenticate users and enable them to present their digital identity to an application. Key components include tokens, claims, identity providers, and the Security Token Service (STS). The following steps describe the general authentication process, such as a user attempting to access a web application using a web browser: 1. A web browser will request a token from an STS on the behalf of the user. This request is made using WS-Trust, a standard protocol for web service communication. The request typically includes the name of the user whom the token will represent and an identifier that describes the application the user wishes to access. 230  CHAPTER 9 claims-Based aUtheNticatioN 2. The STS performs an information look-up and verification. User information is stored in a database like SQL Server or a directory store like Active Directory or an LDAP directory. Once the information is verified and the user is authenticated, the STS issues a token, which is returned to the requestor. The STS’s authority to issue tokens has been granted by some identity provider, which is also called an issuer. The issuer stands behind the validity of the claims contained in the token. SharePoint 2010 includes its own STS, and the identity pro- vider would be represented by the organization. 3. The browser sends the token to the desired web application, which receives the token and the required claims. The application uses the claims information because it trusts the identity provider, referred to as a relying party. Once the application verifies the token signature, con- firming it originated from a trusted STS, the claims are accepted and the information is used for authorization. A key benefit is that 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. An administrator must configure the STS to issue the right claims. SharePoint 2010 includes an STS and WIF to claims-enable web applications, and therefore SharePoint websites can be configured to utilize CBA. To broaden SharePoint’s identity capability, you could install ADFS 2.0. ADFS provides much broader support for CBA, including the capability to federate to other organizations outside the hosting organization. ADFS 2.0 is an improvement over its predeces- sor, ADFS 1.0, because it implements an STS that generates SAML tokens in response to WS-Trust requests. In addition, ADFS 2.0 supports both web browsers and other clients, such as Office desktop clients and those built using Windows Communication Foundation (WCF). ADFS 1.0 only sup- ported web browsers. The ADFS 2.0 STS can be used entirely inside an organization, exposed on the Internet, or both. However, ADFS 2.0 is not required to use claims-based identity; CBA can be implemented using an STS from any vendor, or even a custom-built STS. Table 9-2 summarizes the components and open source protocols used in CBA. TABLE 92 Claims-Based Authentication Components and Open Source Protocols COMPONENT DESCRIPTION Token A token contains claims about a user and a digital signature. The service that issues the token digitally signs the token in order to verify the issuer and guard against unauthorized claim changes. Claim A claim is any piece of information that describes a characteristic about the user. Security Token Service (STS) An STS creates and issues tokens. STS is a web service that issues tokens as defined by the WS-Trust security standard. Secure Store Service SSS is a claims-aware service that has been discussed in several previous chapters. It is responsible for decrypting the token issued by the STS to access the application ID, and retrieving credentials from the secure store database. The credentials are then used to authorize access to resources. SharePoint Authentication Options  231 COMPONENT DESCRIPTION WS-Trust This is an open source standard that defines the concept of an STS, and the issuing, renewing, and validating of security tokens. Identity Provider The organization that backs the STS and ensures that the claims are authentic Relying Party An application that accepts and uses a token is referred to as a rely- ing party. The user has been authenticated by a trusted provider, and the application is relying on the information contained in the claims. SAML The Security Assertion Markup Language is an open source XML standard for communicating and exchanging identity information, authentication, and authorization data between dierent organiza- tions. SAML provides Internet single sign-on (SSO) for organizations that want to securely connect to Internet applications that exist both inside and outside the safety of an organization’s firewall. SHAREPOINT AUTHENTICATION OPTIONS SharePoint Server 2010 supports CBA as well as classic mode authentication (CMA). CMA was how users were authenticated in SharePoint Server 2007. In SharePoint Server 2010, you can choose between claims-based authentication and classic mode authentication when you create a web application. SharePoint 2010 is represented by three logical layers or tiers: the front-end web server tier (WFE), the application server tier, and the back-end database tier. Each tier may require authentication using an authentication provider, which supports specific authentication methods. There are several factors to consider when choosing an authentication method. One factor is whether or not you will be using FBA. If you plan to use FBA, you will need to utilize CBA. This is a change from SharePoint 2007. You may also be considering SAML token-based authentication; if so, you will need to use CBA. If neither FBA or SAML are being planned, and identity federation is also not under consideration, then using classic mode authentication may be the preferred method. Classic Mode Classic mode authentication refers to the Integrated Windows authentication model supported in SharePoint Server 2007. CMA does not utilize any of the claims infrastructure, and therefore none of the claims features are available. Classic mode supports all the Windows authentication methods that were available in SharePoint 2007. Similar to the restriction in SharePoint 2007, SharePoint 2010 web applications that use classic mode are limited to one form of authentication for each zone. These different Windows authentication methods include the following: Anonymous  Basic  232  CHAPTER 9 claims-Based aUtheNticatioN Digest  Certificate  NTLM  Kerberos  Claims-Based SharePoint Server 2010 CBA enables authentication using Windows Integrated security and non-Windows systems. A key concept with CBA in SharePoint 2010 is that authentication is based on an identity provider. Applications trust this provider because they are configured to utilize the provider. The beauty of the system is that any provider that meets specific Internet security standards can be used. These standards include WS-Security, WS-SecurityPolicy, WS-Trust and WS-Federation. Therefore companies have the flexibility to choose their provider, and as long as it’s compliant with these standards it will be supported by SharePoint. CBA supports three different authentication pro- viders out of the box: Windows Authentication  — This includes all the same authentication methods that CMA supports, as listed above. Forms-Based Authentication (FBA)  — These methods include LDAP, database or custom membership, and role providers. Note that FBA is only available when you use claims-based authentication. SAML Token-Based Authentication  — These include ADFS 2.0, Windows Live ID, and third-party providers. CREATING CLAIMSBASED WEB APPLICATIONS The following instructions walk you through the process of creating a claims-enabled web applica- tion. You will also configure the application to allow anonymous access. Finally, you will add FBA to the application so that you have a dual authentication configuration. Configuring CBA with Windows Authentication Begin by configuring CBA with Windows Authentication: 1. Create a new web application using CBA. The process for creating a new web application was discussed in detail in Chapter 4, so it isn’t repeated here. Only the changes specific to enabling CBA are discussed. You must first enable CBA in the Authentication section of the Create New Web Application web page in Central Administration. The default is classic mode, so you will need to select claims mode. Notice that the Claims-Based Authentication option has been selected, as shown in Figure 9-1. . firewall. SHAREPOINT AUTHENTICATION OPTIONS SharePoint Server 2010 supports CBA as well as classic mode authentication (CMA). CMA was how users were authenticated in SharePoint Server 2007. In SharePoint. the right claims. SharePoint 2010 includes an STS and WIF to claims-enable web applications, and therefore SharePoint websites can be configured to utilize CBA. To broaden SharePoint s identity. for Authentication SharePoint 2010 supports claims-based authentication, which is a powerful and flexible authentica- tion model. Claims-based authentication (CBA) in SharePoint 2010 works with a