Windows平台上的身份验证与授权：基于声明的身份与访问控制指南

需积分: 10 102 浏览量更新于2024-08-01 收藏 1.82MB PDF 举报

"A Guide to Claims-based Identity" 是一本面向IT专业人士的指南，旨在帮助架构师、开发者以及在Windows系统上工作的人们评估和实施基于声明的身份识别与访问控制策略。这本书特别适用于那些设计、构建或维护需要用户身份信息的网络应用和服务的人员，比如使用Microsoft .NET Framework、ASP.NET、Windows Communication Foundation (WCF)和Visual C#的开发者。该书的核心内容围绕着声明身份（Claims）的概念展开，强调了其在身份验证和授权中的作用。首先，书中指出并不是所有系统都必须采用声明身份，但在规划新应用或对现有应用进行改进时，它提供了一种简化和标准化的身份管理方法。声明不仅提供了关于用户身份的基本信息，还支持权限管理和跨系统协作，使得应用程序间的信任关系更加清晰。章节2深入解释了声明如何简化了身份验证逻辑，通过统一的标准，减少了代码中关于用户认证和授权的复杂性。一个熟悉的例子被用来直观地展示声明的实用价值。此外，书中还讨论了良好声明的特性，包括有效性、权威性和可扩展性，以及如何选择和配置合适的发行者（Issuers），如Active Directory Federation Services (ADFS)。书中关键的实践步骤包括：第一步，让应用程序支持声明，这可能涉及对现有框架的调整；第二步，获取或开发一个可靠的发行者来产生和管理声明；第三步，配置应用程序信任这个发行者，确保安全通信；最后，配置发行者以满足应用的需求，并处理可能的匿名用户情况。 "GuidetoClaims-BasedIdentityandAccessControl"这本书不仅介绍了技术原理，还提供了实际操作指导，帮助读者理解和应用声明身份模式与实践。无论是初次接触该领域的新人，还是已经在工作中遇到相关问题的专业人士，都能从中受益匪浅，提升Windows平台上的身份管理效率和安全性。通过阅读本书，读者将对基于声明的身份验证和访问控制有更深入的理解，从而更好地服务Web服务和现代应用环境。

2   3   

The following table shows the relationships between security to-

kens, claims, and issuers.

Security token Claims Issuer

Windows token. This

token is represented as a

security identiﬁ er (SID).

This is a unique value of

variable length that is

used to identify a

security principal or

security group in

Windows operating

systems.

User name and groups. Domain.

User name token. User name. Application.

Certiﬁ cate. Examples can include a

thumbprint, a subject, or

a distinguished name.

Issuer chains to the root.

The claims-based approach to identity makes it easy for users to sign

in using Kerberos where it makes sense, but at the same time, it’s just

as easy for them to use one or more (perhaps more Internet-friendly)

authentication techniques, without you having to recode, recompile,

or even reconﬁ gure your applications. You can support any authenti-

cation technique, some of the most popular being Kerberos, forms

authentication, X.509 certiﬁ cates, smart cards, as well as information

cards and others.

    

This is an important disclaimer. Companies with a host of internal ap-

plications can use Windows Integrated authentication to achieve

many of the beneﬁ ts provided by claims. Active Directory does a great

job of storing user identities, and because Kerberos is a part of Win-

dows, your applications don’t have to include much authentication

logic. As long as every application you build can use Windows inte-

grated authentication, you may have already reached your identity

utopia.

However, there are many reasons why you might need something

other than Windows authentication. You might have Web-facing ap-

plications that are used by people who don’t have accounts in your

Windows domain. Another reason is that your company has merged

with another company and you’re having trouble authenticating across

two Windows forests that don’t (and may never) have a trust relation-

ship. Perhaps you want to share identities with another company that

has non-.NET Framework applications or you need to share identities

between applications running on different platforms (for example, the

Macintosh). These are just a few situations where claims-based iden-

tity can be the right choice for you.

   

Most applications include a certain amount of logic that supports

identity-related features. Applications that can’t rely on Windows In-

tegrated authentication tend to have more of this than applications

that do. For example, Web-facing applications that store user names

and passwords must handle password reset, lockout, and other issues.

Enterprise-facing applications that use Windows Integrated authenti-

cation can rely on the domain controller.

But even with Windows Integrated authentication, there are still

challenges. Kerberos tickets only give you a user’s account and a list

of groups. What if your application needs to send e-mail to the user?

What if you need the e-mail address of the user’s manager? This starts

to get complicated quickly, even within a single domain. To go beyond

Kerberos’s limitations, you need to program Active Directory. This is

not a simple task, especially if you want to build efﬁ cient Lightweight

Directory Access Protocol (LDAP) queries that don’t slow down your

directory server.

Claims-based identity allows you to factor out the authentication

logic from individual applications. Instead of the application determin-

ing who the user is, it receives claims that identify the user.

  

Claims-based identity is all around us. A very familiar analogy is the

authentication protocol you follow each time you visit an airport. You

can’t simply walk up to the gate and present your passport or driver’s

license. Instead, you must ﬁ rst check in at the ticket counter. Here,

you present whatever credential makes sense. If you’re going overseas,

you show your passport. For domestic ﬂ ights, you present your driv-

er’s license. If your children ﬂ y with you, they don’t need to show

anything at all, but the ticket agent asks you their names to provide

some level of authentication. After verifying that your picture ID

matches your face, the agent looks up your ﬂ ight and veriﬁ es that

you’ve paid for a ticket. Assuming all is in order, you receive a boarding

pass that you take to the gate.

A boarding pass is very informative. Gate agents know your name

and frequent ﬂ yer number (authentication and personalization), your

ﬂ ight number and seating priority (authorization), and perhaps even

more. The gate agents have everything that they need to do their jobs

efﬁ ciently.

You can use claims to

implement Role-

Based Access Control

(RBAC). Roles are

claims, but claims can

contain more

information than

roles. Also, you can

send claims inside a

signed (and possibly

encrypted) security

token and be certain

that they come from

a trusted issuer.

╭

Claims provide a

powerful abstraction

for identity.

╭

Claims help you to factor

authentication logic out

of your applications.

4   5   

There is also special information on the boarding pass. It is en-

coded in the bar code and/or the magnetic strip on the back. This in-

formation (such as a boarding serial number) proves that the pass was

issued by the airline and is not a forgery.

In essence, a boarding pass is a signed set of claims made by the

airline about you. It states that you are allowed to board a particular

ﬂ ight at a particular time and sit in a particular seat. Of course, agents

don’t need to think very deeply about this. They simply validate your

boarding pass, read the claims on it, and let you board the plane.

It’s also important to note that there may be more than one way

of obtaining the signed set of claims that is your boarding pass. You

might go to the ticket counter at the airport, or you might use the

airline’s Web site and print your boarding pass at home. The gate

agents boarding the ﬂ ight don’t care how the boarding pass was cre-

ated. They only care that it is an authentic set of claims that give you

permission to get on the plane.

In software, this bundle of claims is called a security token. Each

security token is signed by the issuer who created it. A claims-based

application considers users to be authenticated if they present a valid,

signed security token from a trusted issuer. Figure 1 shows the basic

pattern for using claims.

 

Issuers, security

tokens, and

applications

For an application developer, the advantage of this system is clear:

your application doesn’t need to worry about what sort of credential

the user presents. Someone who determines your company’s security

policy can make those rules and buy or build the issuer. Your applica-

tion simply receives the equivalent of a boarding pass. No matter what

authentication protocol was used, Kerberos, SSL, forms authentica-

tion, or something more exotic, the application gets a signed set of

claims that has information it needs about the user. This information

is in a simple format that the application can use right away.

    ?

Security tokens can contain claims such as the user’s name, e-mail

address, manager’s e-mail address, groups, roles, and so on. Think

about claims the same way you think about attributes in Active

Directory or some other central repository over which you have little

control. Depending on your organization, it may be easy or difﬁ cult to

centralize lots of information about users and issue claims to share

that information with applications.

It rarely makes sense to centralize data that is speciﬁ c to one

application only. In fact, even applications that use claims can still

beneﬁ t from storing a table that contains user information. This table

is where you can keep application-speciﬁ c user data that no other

application cares about. This is data for which your application is

authoritative. In other words, it is the single source for that data, and

someone must be responsible for keeping it up to date.

Another use for a table like this is to cache non-authoritative data

that you get from claims. For example, you might cache an e-mail

claim for each user so that you can send out notiﬁ cation e-mail with-

out the user having to be logged in. You should treat any cached claims

as read-only and refresh them the next time the user visits your

application and presents fresh claims. Include a date column that

you update each time you freshen the record. That way, you know

how stale the cached claims have become when it comes time to

use them.

Issuer

Application

1. Authenticate.

2. Issue token.

3. Send token.

When you decide what kinds

of claims to issue, ask

yourself how hard is it to

convince the IT department

to extend the Active

Directory schema. They have

good reasons for staying

with what they already have.

If they’re reluctant now,

claims aren’t going to change

that. Keep this in mind when

you choose which attributes

to use as claims.

Claims are like salt.

Just a little bit ﬂ avors

the broth. The next

chapter has more

information on what

makes a good claim.

6   7   

   

Today, it’s possible to purchase an issuer that provides user informa-

tion, packaged as claims.

If you have Windows Server 2008 R2 Enterprise Edition, you are

automatically licensed to run Microsoft’s issuer, Active Directory Fed-

eration Services (ADFS) 2.0. ADFS provides the logic to authenticate

users in several ways, and you can customize each instance of your

ADFS issuer to authenticate users with Kerberos, forms authentica-

tion, or certiﬁ cates. Alternatively, you can ask your ADFS issuer to

accept a security token from an issuer in another realm as proof of

authentication. This is known as identity federation and it’s how you

achieve single sign-on across realms.

Figure 2 shows all the tasks that the issuer performs.

 

ADFS functions

After the user is authenticated, the issuer creates claims about that

user and issues a security token. ADFS has a rule engine that makes it

easy to extract LDAP attributes from the user’s record in Active Di-

rectory and its cousin, Lightweight Directory Services. ADFS also al-

lows you to add rules that include arbitrary SQL statements so that

you can extract user data out of your own custom SQL database.

You can extend ADFS to add other stores. This is useful because,

in many companies, a user’s identity is often fragmented. ADFS hides

this fragmentation. Your claims-based applications won’t break if you

decide to move data around between stores. Claims-based applica-

tions expect to receive claims about the user, but they don’t care

about which identity store those claims come from. These applica-

tions are loosely coupled to identity. This is one of the biggest bene-

ﬁ ts of claims-based identity.

 

One option that claims-based applications give you is user anonymity.

Remember that your application no longer directly authenticates the

users; instead, it relies on an issuer to do that and to make claims

about them. If user anonymity is a feature you want, simply don’t ask

for any claim that personally identiﬁ es the user. For example, maybe

all you really need is a set of roles to authorize the user’s actions, but

you don’t need to know the user’s name. You can do that with claims-

based identity by only asking for role claims. Some issuers (such as

ADFS) support the idea of private user identiﬁ ers, which allows you

to get a unique, anonymous identiﬁ er for a user without any personal

information (such as a name or e-mail address). Keep user anonymity

in mind when you consider the power of claims-based identity.

Implementing Claims-Based Identity

There are some general set-up steps that every claims-based system

requires. Understanding these steps will help you when you read

about the claims-based architectures.

 :      

 

When you build a claims-based application, it needs to know how to

validate the incoming security token and how to parse the claims that

are inside. The Windows Identity Foundation (WIF) provides a

common programming model for claims that can be used by both

Windows Communication Foundation (WCF) and ASP.NET applica-

tions. If you already know how to use methods such as IsInRole and

properties such as Identity.Name, you’ll be happy to know that WIF

simply adds one more property that is named Identity.Claims. It

identiﬁ es the claims that were issued, who issued them, and what they

contain.

There’s certainly more to learn more about WIF programming

model, but for now just remember to reference the WIF assembly

(Microsoft.IdentityModel.dll) from your ASP.NET applications and

WCF services in order to use WIF’s programming paradigm.

You can also receive

tokens that were

generated outside

of your own realm.

This is known as

federated identity.

Issuer (ADFS)

Claims-based

application

1. Authenticate.

3. Issue token.

4. Send token.

Custom stores

Active Directory

Relational database

Active Directory

Lightweight

Directory Services

XML

2. Gather

information.

╭

A good issuer can make it

easier to implement authori-

zation and personalization

in your applications.

╭

Claims-based applications

are loosely coupled to

identity.

For this to be

possible, the issuer

must not collude

with the application.

8   9   

 :     

For most teams, the easiest and most secure option will be to use

ADFS 2 .0 as the issuer of tokens. Unless you have a great deal of

security experience on your team, you should look to the experts to

supply an issuer. That’s why ADFS 2.0 is a good option for most

people. If you need to customize the issuer and the extensibility points

in ADFS 2.0 aren’t sufﬁ cient, you can license third-party software or

use WIF to build your own issuer. Note, however, that implementing

a production-grade issuer requires specialized skills that are beyond

the scope of this book.

 :   

   

After you build a claims-based application and have an issuer to sup-

port it, the next step is to set up a trust relationship. An application

trusts its issuer to identify and authenticate users and make claims

about their identities. When you conﬁ gure an application to rely on a

speciﬁ c issuer, you are establishing a trust (or trust relationship) with

that issuer.

There are several important things to know about an issuer when

you establish trust with it:

What claims does the issuer offer?

•

What key should the application use to validate signatures on

•

the issued tokens?

What URL must users access in order to request a token

•

from the issuer?

Claims can be anything you can imagine, but practically speaking,

there are some very common claims offered by most issuers. They

tend to be simple, commonly available pieces of information, such as

ﬁ rst name, last name, e-mail name, groups and/or roles, and so on.

Each issuer can be conﬁ gured to offer different claims, so the applica-

tion (technically, this means the architects and developers who design

and build the application) needs to know what claims are being of-

fered so they can either select from that list or ask whoever manages

the issuer to expand its offering.

All of the questions in the previous list can easily be answered by

asking the issuer for federation metadata. This is an XML document

that the issuer provides to the application. It includes a serialized copy

of the issuer’s certiﬁ cate that provides your application with the

correct public key to verify incoming tokens. It also includes a list of

claims the issuer offers, the URL where users can go to get a token,

and other more technical details, such as the token formats that it

knows about (although in most cases you’ll be using the default SAML

format understood by the vast majority of issuers and claims-based

applications). WIF includes a wizard that automatically conﬁ gures

your application’s identity settings based on this metadata. You just

need to give the wizard the URL for the issuer you’ve selected, and it

downloads the metadata and properly conﬁ gures your application.

 :     

  

The issuer needs to know a few things about an application before it

can issue it any tokens:

What Uniform Resource Identiﬁ er (URI) identiﬁ es this

•

application?

Of the claims that the issuer offers, which ones does this

•

application require and which are optional?

Should the issuer encrypt the tokens? If so, what key should

•

it use?

What URL does the application expose in order to receive

•

tokens?

Each application is different, and not all applications need the same

claims. One application might need to know the user’s groups or roles,

while another application might only need a ﬁ rst and last name. So

when a client requests a token, part of that request includes an iden-

tiﬁ er for the application the user is trying to access. This identiﬁ er is

a URI and, in general, it’s simplest to just use the URL of the applica-

tion, for example, http://www.fabrikam.com/purchasing/.

If you’re building a claims-based Web application that has a rea-

sonable degree of security, you’ll require the use of SSL (HTTPS) for

both the issuer and the application. This will protect the information

in the token from eavesdroppers. Applications with stronger security

requirements can also request encrypted tokens, in which case, the

application typically has its own certiﬁ cate (and private key). The is-

suer needs a copy of that certiﬁ cate (without the private key) in order

to encrypt the token issued for that application.

Once again, federation metadata makes this exchange of informa-

tion easy. WIF includes a tool named FedUtil.exe that generates a

federation metadata document for your application, so that you don’t

have to manually conﬁ gure the issuer with all of these settings.

While you’re

developing

applications, you

can use a stub issuer

that just returns

the claims you need.

WIF supplies a

local issuer that

can be used for

prototyping and

development and

it’s integrated

with Microsoft

Visual Studio®.

Trust is unidirectional.

The application trusts

the issuer, and not the

other way around.

╭

Issuers only provide claims

to authorized applications.

There are, of course,

many reasons why an

application shouldn’t

get any more

information about a

user than it needs.

Just two of them are

compliance with

privacy laws and the

design practice of

loose coupling.

剩余87页未读，继续阅读

ebooksanywhere

粉丝: 0
资源: 13

Windows平台上的身份验证与授权：基于声明的身份与访问控制指南

Claims-based Identity for Windows

allstate-claims-severity.zip

Insurance-Claims-Fraud-Detection

ASP.NET Core中的Claims-Based身份验证

Claims-Processor

Insurance-Claims-App-for-Android:保险理赔应用

kaggle-allstate-claims-severity.zip

asp.net-identity-asp.net-core-identity

first app village claims-开源

Claims-frontend-app：索赔管理API的前端应用程序

最新资源