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.