windows vista for developers delivery guide phần 7 pps

The Windows Workflow Foundation framework includes a default set of activities that provide functionality for control flow, conditions, event handling, state management, and communicatin

Demonstration 6: Creating a Sequential Workflow

In this demonstration, you will see how you can create an application that uses a

sequential workflow

Key Point

The key point of this demonstration is:

• You can add activities to a Windows Workflow application and configure the

workflow to process the activities sequentially

Using Activities in Workflows

Activities are the fundamental building blocks of workflows A workflow is a set of

activities organized hierarchically in a tree structure Once all of the activities in a given

flow path are finished running, the workflow instance completes

An activity represents an action in a workflow It can be a simple action such as a delay,

or it can be a composite activity that consists of several child activities An activity, like a

workflow, can be sequential, which means that the order of its actions is specified at

design time Or the activity can be event-driven, which means that the order of its actions

is determined at run time in response to external events

The Windows Workflow Foundation framework includes a default set of activities that

provide functionality for control flow, conditions, event handling, state management, and

communicating with applications and services When designing workflows, you can use

the activities provided by Windows Workflow Foundation, and you can create your own

activities

The following table lists a sample of the activities in the Windows Workflow Foundation framework activity set

Activity Description

InvokeWebService Makes a call out to a Web service

Code Executes a specified method in the code-beside file

Delay Causes the containing branch of the workflow to wait for a time-out EventDriven Used in a Listen or a workflow event handler to specify the event

and contain the executed activities Listen Waits for one of a set of events

Terminate Enables you to immediately end the operation of your workflow in

the event of an error condition

Using Conditions in Workflows

You can use conditions to control the behavior of your workflow When the workflow

encounters a condition, the runtime engine evaluates the condition and then acts based on

the result of that evaluation

There are two ways to represent conditions in your workflow:

• Writing a handler in code that returns a Boolean value

• Adding a rule in your workflow definition

You can dynamically update rule conditions at run time to alter the behavior of the

workflow

Conditional Activities

Several activities that are provided with the Windows Workflow Foundation use

conditions:

Activity Description

IfElseActivity Tests a condition on each branch and performs activities on the

first branch for which the condition equals true

WhileActivity Continuously executes any activities contained within it as long as

its condition evaluates to true The condition is reevaluated at the completion of each loop

ConditionedActivityGroup Continuously executes any activities within it as long as its

condition evaluates to true Each individual activity within the ConditionedActivityGroup has a When condition Each activity executes only when the When condition evaluates to true

ReplicatorActivity Completes its execution when its UntilCondition property

evaluates to true

Demonstration 7: Performing Conditional Processing

In this demonstration, you will see how you can configure a workflow that uses

conditional processing

Key Point

The key point of this demonstration is:

• You can use conditional activities such as IfElseActivity to control the flow of a

workflow

Managing Digital Identity by Using CardSpace

Digital Identity is digital information that identifies a user to another application or

service Implementing digital identities between diverse and different systems can be

complicated by the absence of a consistent standard for implementing digital identities

CardSpace is used to provide a consistent and system-independent solution for managing

digital identities

Objectives

After completing this section, you will be able to:

• Define digital identity

• Describe the Laws of Identity

• Define CardSpace

• Describe how to establish a digital identity by using CardSpace

• Manage information cards

• Integrate CardSpace with applications

• Invoke CardSpace from a Web page

What Is Digital Identity?

A digital identity refers to the representation of a personal identity that is used in a

distributed network interaction with other machines and people A digital identity is used

to identify a user or process to another system For example, your Windows Security

Identifier (SID) may be a digital identity that identifies you to other computers and

applications on your network

Like identities in the real world, there are many varieties of digital identities Different

contexts require a different identity, each of which is expressed in a different way and

provides different information The problem is that there is currently no consistent way to

define how digital identities are used by applications

Digital identity terminology

The following list defines the terms used to discuss digital identity:

• Digital identity A set of claims made by one digital subject about itself or another

digital subject

• Digital subject A person or thing represented or existing in the digital realm which is

being described or dealt with

• Claim An assertion of the truth of something, typically one that is disputed or in

doubt For example, a set of claims might convey personally identifying information

such as name, address, and date of birth

• Identity metasystem The Identity metasystem is an interoperable architecture for digital identity that assumes that people will have several digital identities based on multiple underlying technologies, implementations, and providers The three roles within the metasystem are:

• Identity providers Parties that issue digital identities For example, credit card

providers might issue identities enabling payment

• Relying parties Parties that require identities, for example, a Web site or online

service that utilizes identities offered by other parties

• Subjects The individuals and other entities about whom claims are made

Examples of subjects include end users, companies, and organizations

The Laws of Identity

The Laws of Identity are intended to codify a set of fundamental principles to which any

identity metasystem must conform in order to be universally accepted The laws were

proposed, debated, and refined through a long-running, open, and continuing dialogue on

the Internet The laws specify the following components of the architecture of the identity

metasystem

• User control and consent Identity systems must reveal information identifying a user

only with the user’s consent

• Minimal disclosure for a constrained use The identity system must disclose the least

identifying information possible because this is the most stable, long-term solution

• Justifiable parties Identity systems must be designed so the disclosure of identifying

information is limited to parties having a necessary and justifiable place in a given

identity relationship

• Directed identity A universal identity system must support both omnidirectional

identifiers for use by public entities and unidirectional identifiers for use by private

entities, thus facilitating discovery while preventing unnecessary release of

correlation handles

• Pluralism of operators and technologies A universal identity solution must utilize

and enable the interoperation of multiple identity technologies run by multiple

identity providers

• Human integration Identity systems must include the human user as a component of

the distributed system, integrated through unambiguous human-machine

communication mechanisms offering protection against identity attacks

• Consistent experience across contexts The unifying identity metasystem must

guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies

For more information see the “Laws of Identity” white paper on the Microsoft MSDN Web site

What Is CardSpace?

Windows CardSpace is a Microsoft NET Framework component that provides the

consistent user experience required by the identity metasystem CardSpace plays an

important part in the identity metasystem by providing a way for users to select identities

when authenticating to Web applications

Windows CardSpace provides:

• Support for any digital identity system CardSpace and the identity metasystem are

agnostic about the format of the security token that is requested from an identity

provider and passed on to a relying party Typically, CardSpace is not even aware of

what format this token is in Because of this, CardSpace can work with any digital

identity system, using any type of security token

• Consistent user control of digital identity Users are shielded from differences in

security technologies and have a consistent and predictable way to use their digital

identities

• Replacement of password-based Web logon The security tokens issued by most identity providers do not use passwords, therefore relying parties, including Web sites and others, can use these tokens rather than passwords to authenticate their users

If a site uses tokens, it will help reduce the vulnerability to phishing attacks

• Improved user confidence in the identity of remote applications CardSpace helps users make informed decisions about which identity providers they will let provide them with digital identities and which relying parties are allowed to receive those digital identities

Establishing Digital Identity by Using CardSpace

The following process describes how digital identity is established using CardSpace:

1 The application gets the security token requirements of the relying party, which is the

Web site or online service that the user wants to access This information is contained

in the relying party’s policy and includes information such as what security token

formats the relying party will accept and exactly what claims those tokens must

contain

2 Once this information is returned and passed to CardSpace, the system displays the

card selection screen To give the user a consistent experience, every information

card he or she owns on this system is shown, but any information cards whose

associated security token and claims that do not match the requirements of this

relying party are unavailable

3 Once the user clicks a particular card, CardSpace issues a request for a token to the

identity provider associated with that card The identity provider then returns a

security token

4 Once this security token has been received, CardSpace provides it to the application,

which passes it on to the relying party The relying party can then use this token to

authenticate the user or for some other purpose

Managing Information Cards

The Digital Identities Control Panel application helps you manage your digital identities

By using it, you can:

• Create a new Personal card Personal cards allow you to quickly register and sign

into Web sites without filling out forms or using passwords

• Install a Provider card Provider cards are issued by third parties such as banks,

membership organizations, and major Web sites

• Export and restore your information cards

• Track the sites to which you have provided your information

• Password protect your card information

Using CardSpace with Web Applications

CardSpace design goals for integrating with Web sites

The following list describes the design goals for using CardSpace-based authentication

with Web sites:

• Browser independence The protocols developed for CardSpace-based authentication

to Web sites should be implemented by a broad range of Web browsers on the

platforms of their choice

• Web server independence The protocols developed for CardSpace-based

authentication to Web sites should be used by Web-based applications running on a

broad range of Web servers on the platforms of their choice

• Minimal impact on Web sites The adoption of CardSpace-based authentication for

existing Web sites should require as few changes to the Web sites as possible

• Seamless browser integration CardSpace-based authentication should be viewed as a

seamless security feature that is a natural extension of the browsers being used

• Seamless user experience CardSpace Web integration design should permit graceful

fallback when a browser or platform does not have CardSpace support available

• Compatibility with browser high-security settings The mechanisms chosen should

remain enabled even when browser security settings are set to high

Invoking CardSpace from a Web Page

HTML extensions are used on a Web page to signal to the browser when to invoke the

identity selector To address compatibility issues, two HTML extension formats are

specified Browsers may support one or both of the extension formats

• OBJECT Syntax The OBJECT tag is widely supported, but it is also disabled by

high-security settings on some browsers, including Internet Explorer

• XHTML Syntax An alternative is to use an XHTML syntax that is not disabled by

changing browser security settings However, not all browsers provide full support

for XHTML

CardSpace invocation parameters

The following table provides the parameters used to invoke CardSpace to provide the

user’s digital identity

Parameter Description

issuer (optional) Specifies the URL of the Secure Token Service (STS) from which

to obtain a token If omitted, no specific STS is requested STS is

a service that is responsible for releasing signed tokens containing claims about an individual The special value "urn:schemas- microsoft-com:ws:2005:05:identity:issuer:self" specifies that the token should come from a self-issued identity provider

issuerPolicy (optional) Specifies the URL of an endpoint from which the STS’s policy can

be retrieved

(continued)

Parameter Description

tokenType (optional) Specifies the type of the token to be requested from the STS as a

URI

requiredClaims (optional) Specifies the types of claims that must be supplied by the identity

If omitted, there are no required claims The value of requiredClaims is a space-separated list of URIs, each specifying

a required claim type

optionalClaims (optional) Specifies the types of optional claims that may be supplied by the

identity

An example of the OBJECT syntax is:

<OBJECT type="application/x-informationCard" name="xmlToken">

Session Summary

The Microsoft NET Framework 3.0 is the new managed code programming model for

Windows .NET Framework 3.0 builds on the foundation of NET Framework 2.0 and

adds new technologies such as Windows Communication Foundation, Windows

Workflow Foundation, and CardSpace This session described how to build and deploy

applications by using the new technologies in NET Framework 3.0

This session described:

• NET Framework 3.0 and how to deploy it to clients

• How to develop Web service–based applications by using Windows Communication

Foundation

• How to build workflow applications by using Windows Workflow Foundation

• How to use CardSpace to provide a consistent and system-independent solution for

managing digital identities