Scenario Testing

Scenario Testing is an interactive tool to define your test scenarios by dragging and dropping methods to be tested.It is build using Workflow Foundation 4 (WF 4).The test scenarios can be saved and loaded again for testing.

http://scenariotesting.codeplex.com/

PowerShell Workflow

PowerShell Workflow helps organizations to define their operational processes through the power of Workflow and Powershell. PowerShell Workflow is a free tool to use

It can be downloaded from http://powershellworkflow.codeplex.com/

Prerequisites:
PowerShell Workflow require following softwares to be installed on the system1. Windows PowerShell 2.0 http://support.microsoft.com/kb/9689292.
Microsoft .Net Framework 4.0 http://msdn.microsoft.com/en-us/netframework/aa569263

A business case for BPM

Discussing the need of business process management system in an organization.

Business Process Management

Azure Services Platform : .Net Services

Microsoft® .NET Services are a set of Microsoft-hosted, highly scalable, developer-oriented services that provide key building blocks required by many cloud-based and cloud-aware applications. Much like the .NET Framework provides higher-level class libraries that make developers more productive, .NET Services can help developers focus on their application logic rather than building and deploying their own cloud-based infrastructure services.
From an interoperability perspective, the .NET Services are also available to other development technologies through the use of industry-standard protocols such as REST, SOAP, and HTTP. While more services are in the works, .NET Services currently includes three core components — the Access Control Service, Service Bus, and Workflow service.
Overview

Access Control
The Microsoft .NET Access Control Service provides an easy way to control web applications and services while integrating with standards-based identity providers, including enterprise directories and web identity systems such as Windows Live ID. Authorization decisions can be pulled out of the application and into a set of declarative rules that can transform incoming security claims into claims that applications understand.

Service Bus
The Microsoft .NET Service Bus makes it easy to connect applications together over the Internet. Services that register on the Bus can easily be discovered and accessed, across any network topology. The Service Bus provides the familiar Enterprise Service Bus application pattern, while helping to solve some of the hard issues that arise when implementing this pattern across network, security, and organizational boundaries, at Internet-scale.

Workflow Service
The Microsoft .NET Workflow Service is a high-scale host for running workflows in the cloud. It provides a set of activities optimized for sending, receiving, and manipulating HTTP and Service Bus messages; a set of hosted tools to deploy, manage and track the execution of workflow instances; and a set of management API’s. Workflows can be constructed using the familiar Visual Studio 2008 Workflow Designer.

Azure Services Platform

What is the Azure Services Platform?
The Azure™ Services Platform (Azure) is an internet-scale cloud services platform hosted in Microsoft data centers, which provides an operating system and a set of developer services that can be used individually or together. Azure’s flexible and interoperable platform can be used to build new applications to run from the cloud or enhance existing applications with cloud-based capabilities. Its open architecture gives developers the choice to build web applications, applications running on connected devices, PCs, servers, or hybrid solutions offering the best of online and on-premises.
Azure reduces the need for up-front technology purchases, and it enables developers to quickly and easily create applications running in the cloud by using their existing skills with the Microsoft Visual Studio development environment and the Microsoft .NET Framework. In addition to managed code languages supported by .NET, Azure will support more programming languages and development environments in the near future. Azure simplifies maintaining and operating applications by providing on-demand compute and storage to host, scale, and manage web and connected applications. Infrastructure management is automated with a platform that is designed for high availability and dynamic scaling to match usage needs with the option of a pay-as-you-go pricing model. Azure provides an open, standards-based and interoperable environment with support for multiple internet protocols, including HTTP, REST, SOAP, and XML.
Microsoft also offers cloud applications ready for consumption by customers such as Windows Live™, Microsoft Dynamics™, and other Microsoft Online Services for business such as Microsoft Exchange Online and SharePoint® Online. The Azure Services Platform lets developers provide their own unique customer offerings by offering the foundational components of compute, storage, and building block services to author and compose applications in the cloud.
The Azure Services Windows Azure
Windows® Azure is a cloud services operating system that serves as the development, service hosting and service management environment for the Azure Services Platform. Windows Azure provides developers with on-demand compute and storage to host, scale, and manage internet or cloud applications. Windows Azure supports a consistent development experience through its integration with Visual Studio. In the early stages of CTP, .NET managed applications built using Visual Studio will be supported. Windows Azure is an open platform that will support both Microsoft and non-Microsoft languages and environments. Windows Azure welcomes third party tools and languages such as Eclipse, Ruby, PHP, and Python.Learn more about Windows Azure. Live Services
Live Services is a set of building blocks within the Azure Services Platform for handling user data and application resources. Live Services provides developers with an easy on-ramp to build rich social applications and experiences, across a range of digital devices that can connect with one of the largest audiences on the Web.Learn more about Live ServicesMicrosoft SQL Services
Microsoft SQL Services extends the capabilities of Microsoft SQL Server into the cloud as a Web-based, distributed relational database. It provides Web services that enable relational queries, search, and data synchronization with mobile users, remote offices and business partners. It can store and retrieve structured, semi-structured, and unstructured data.Learn more about SQL ServicesMicrosoft .NET Services
Microsoft .NET Services make developing loosely coupled cloud-based applications easier. .NET Services includes access control to help secure your applications, a service bus for communicating across applications and services, and hosted workflow execution. These hosted services allow you to easily create federated applications that span from on-premises environments to the cloud. Learn more about .NET ServicesMicrosoft® SharePoint® Services & Dynamics® CRM Services
In the future, developers will have access to SharePoint & CRM functionality for collaboration and building stronger customer relationships. With the flexibility to use familiar developer tools like Visual Studio, developers will be able to rapidly build applications that utilize SharePoint and CRM capabilities as developer services for their own applications. Developers can expect a breadth of SharePoint & CRM capabilities across the spectrum of on-premises, online & the Azure Services Platform.
Who Benefits From the Azure Services Platform?
The Azure Services Platform is designed to help developers easily create applications for the web and connected devices. The services platform offers the greatest flexibility, choice, and control in reaching users and customers while using existing skills.
Easy developer on-ramp to the cloud - Millions of developers worldwide already use the .NET Framework and the Visual Studio development environment. Utilize those same skills to create cloud-enabled applications that can be written, tested, and deployed all from Visual Studio. In the near future developers will be able to deploy applications written on Rubyon Rails and Python as well.
Enables Agile & Rapid Results - Applications can be deployed to the Azure Services Platform with the click of a button. Changes can be made quickly and without downtime, making it an ideal platform for affordably experimenting and trying new ideas.
Imagine and Create New User Experiences - The Azure Services Platform enables you to create web, mobile, or hybrid-applications that use the cloud with on-premises applications. Combined with Live Services ability to reach over 400 million Live users, new opportunities exist to interact and reach users in new ways.
Standards-Based Compatibility - The services platform supports industry-standard protocols, including HTTP, REST, SOAP, RSS, and AtomPub, for consuming, exposing, and integrating with third-party services. You can easily integrate applications built on a variety of different technologies and operating systems.
How Can I Use Azure?
Explore the benefits of the Azure Services Platform for your role:
Web developers
Corporate developers
Independent software vendors (ISVs)
Systems integrators and value added partners
Business decision maker
Benefits for Business
The Azure Services Platform offers a range of businesses flexibility, control, and an affordable solution for running Web-scale applications. The services reduce tedious and expensive infrastructure management and planning and are built with security and reliability in mind, along with the option of a pay-as-you-go model.
Whether you’re a software vendor, corporate IT group, or a start-up, by using the services platform you can focus on your business and the needs of your customers.
Simplify Capacity Planning – Additional computing and services capacity can be available for your needs, eliminating the need for planning, purchasing, and provisioning expensive hardware to meet unpredictable spikes in usage.
Simple Infrastructure Management – The services platform manages critical operating system updates and management tasks, giving you control of the environment while letting you focus on the needs of your users.
Give New Life To Existing Investments - The services platform can be used to provide new capabilities to existing on-premises and Web applications. The Azure Services Platform can be integrated into existing applications or used to expose on-premises application services to consumers, business partners, or other organizations.

Claims-based Authentication

Claims-based Authentication / Claims-based identity model
When you build claims-aware applications, the user presents her identity to your application as a set of claims (see Figure 1). One claim could be the user’s name, another might be her email address. The idea here is that an external identity system is configured to give your application everything it needs to know about the user with each request she makes, along with cryptographic assurance that the identity data you receive comes from a trusted source.

Figure 1: User Presents Claims

Under this model, single sign-on is much easier to achieve, and your application is no longer responsible for:
· Authenticating users
· Storing user accounts and passwords
· Calling to enterprise directories to look up user identity details
· Integrating with identity systems from other platforms or companies

Under this model, your application makes identity-related decisions based on claims supplied by the user. This could be anything from simple application personalization with the user’s first name, to authorizing the user to access higher valued features and resources in your application.

It’s not Just About Federation

The claims-based model of identity has been incubating for awhile now inside Microsoft. The original reason for proposing this model was to enable federation between organizations, but over time it’s become apparent that claims aren’t just for federation. But some of these terms still linger on. For example, when you use Geneva Framework in your ASP.NET application, one way to perform claims processing is to enable an Geneva Framework component called the WS-Federation Authentication Module. Don’t let the word “federation” throw you off. There are clear benefits to building applications that outsource authentication and authorization. Any company that has, or plans to have in the future, more than one web application or web service, can benefit by starting with a claims-based model for identity.

Introduction to Claims-Based Identity

In this section of the paper, I’m going to introduce some terminology and concepts so that you, as a developer, can get your head around this new architecture for identity. Let’s start with some terminology.

Identity

The word “identity” is a very overloaded term. So far I’ve been using it to describe the problem space that includes authentication, authorization, etc. But for the purposes of describing the programming model in Geneva Framework, I will use the term identity to describe a set of attributes (well, claims as you’ll see shortly) that describe a user or some other entity in the system that you care about from a security standpoint.

Claim

You can think of a claim as a bit of identity information such as name, email address, age, membership in the Sales role, and so on. The more claims your application receives, the more you’ll know about your user. You may be wondering why I’m using the word “claim”, instead of the more traditional “attributes”, commonly used in the enterprise directory world. The reason has to do with the delivery method – in this model your application doesn’t look up user attributes in a directory. Instead, the user delivers claims to your application, and you’re going to examine them with a certain measure of doubt.

Each claim is made by an issuer, and you’ll trust the claim only as much as you trust the issuer. You’ll trust a claim made by your company’s domain controller more than you would if it were made by the user herself! As you’ll see shortly, the Claim class in Geneva Framework has an Issuer property that allows you to find out who issued the claim.

Security Token

The user delivers a set of claims to your application piggybacked along with her request. In a web service, these claims are carried in the security header of the SOAP envelope. In a browser-based web application, the claims arrive via an HTTP POST from the user’s browser, and may later be cached in a cookie if a session is desired. Regardless of how they arrive, they must be serialized somehow, and this is where security tokens come in. A security token is a serialized set of claims that is digitally signed by the issuing authority. The signature is important – it gives you assurance that the user didn’t just make up a bunch of claims and send them to you. In low security situations where cryptography isn’t necessary or desired, you can use unsigned tokens, but that’s not a scenario I’m going to focus on in this paper.

One of the core features in Geneva Framework is the ability to create and read security tokens. Geneva Framework and the underlying plumbing in the .NET Framework handles all the cryptographic heavy lifting, and presents your application with a set of claims that you can read.

Issuing Authority

There are lots of different types of issuing authorities, from domain controllers that issue Kerberos tickets, to certificate authorities that issue X.509 certificates, but the specific type of authority I’ll be talking about in this paper issues security tokens that contain claims. The issuing authority I’m speaking of is a web application or web service that knows how to issue security tokens. It must have enough knowledge to be able to issue the proper claims for the target relying party given the user making the request, and may be responsible for interacting with user stores to look up claims and authenticate the users themselves.
Whatever issuing authority you choose to buy or build, it will play a central role in your identity solution. When you factor authentication out of your application by relying on claims, you’re ultimately just passing responsibility to that authority and asking it to authenticate users on your behalf.

Security Token Service (STS)

A security token service (STS) is the plumbing that builds, signs, and issues security tokens according to the interoperable protocols that I’ll discuss in the upcoming section called Standards. There’s a lot of work that goes into implementing these protocols, but Geneva Framework does all of this heavy lifting for you, making it feasible for someone who isn’t an expert in the protocols to get an STS up and running with very little effort.
Geneva Server, one of the products featured in Geneva technologies, is a security token service that you can use instead of building your own STS. You might be wondering what Geneva Server uses for implementing the protocols and building a security token. Yes, you guessed it right, it uses Geneva Framework for all of this heavy lifting.

If you want to build your own STS, Geneva Framework offers all the necessary APIs to make your job easy. It’s up to you to figure out how to implement the logic, or rules that drive it (often referred to as security policy).

Relying Party (RP)

When you build an application that relies on claims, you are building a relying party. Some synonyms that you may have heard are, claims aware application, or claims-based application. Web applications and web services can both be built this way, as you’ll see later in this paper.

Basic Scenario

Now that you’ve learned some basic terminology, here’s an example of a claims-based system in action.

Figure 2 shows a claims-aware web service (the relying party) and a smart client that wants to use that service. The relying party exposes policy that describes its addresses, bindings, and contracts. But the policy also includes a list of claims that the relying party needs, for example user name, email address, and role memberships. The policy also tells the smart client the address of the STS (another web service in the system) where it should retrieve these claims. After retrieving this policy (1), the client now knows where to go to authenticate: the STS. The smart client makes a web service request (2) to the STS, requesting the claims that the relying party asked for via its policy. The job of the STS is to authenticate the user and return a security token that gives the relying party all of the claims it needs. The smart client then makes its request to the relying party(3), sending the security token along in the security SOAP header. The relying party now receives claims with each request, and simply rejects any requests that don’t include a security token from the issuing authority that it trusts.

Standards

In order to make all of this interoperable, several WS-* standards are used in the above scenario. Policy is retrieved using HTTP GET and the policy itself is structured according to the WS-Policy specification. The STS exposes endpoints that implement the WS-Trust specification, which describes how to request and receive security tokens. Most STSs today issue SAML tokens (Security Assertion Markup Language). SAML is an industry-recognized XML vocabulary that can be used to represent claims in an interoperable way. This adherence to standards means that you can purchase an STS instead of building it yourself. Or, if you end up in a sticky multi-platform situation, this allows you to communicate with an STS on an entirely different platform and achieve single sign-on across all of your applications, regardless of platform. Identity federation also becomes an option, as I’ll explain shortly.

Browser-based Applications

Smart clients aren’t the only ones who can participate in the world of claims-based identity. Browser-based applications (also referred to as passive clients ) can participate as well. Figure 3 shows how this works. The user points her browser at a claims-aware web application (relying party). The web application redirects the browser to the STS so the user can be authenticated.

The STS in Figure 3 is wrapped by a simple web application that reads the incoming request, authenticates the user via standard HTTP mechanisms, and then creates a SAML token and emits a bit of JavaScript that causes the browser to initiate an HTTP POST that sends the SAML token back to the relying party. The SAML token in the POST body contains the claims that the relying party requested. At this point it is common for the relying party to package the claims into a cookie so that the user doesn’t have to be redirected for each 3 request. The WS-Federation specification includes a section that describes how to do these things in an interoperable way.

Identity Federation

When you build claims-aware web applications and services, you decouple yourself from any one user store. All you want to know is that an authority you trust has given you the identity details you need about the user who is using your application. You don’t have to worry about what domain or security realm that user happens to be part of. This makes it a lot easier to federate identity with other platforms or organizations.

Here’s a concrete scenario that will help get your head around this idea. Let’s say a company called Fabrikam is in the business of manufacturing bicycles, and thousands of bike shops around the world carry their bikes. Fabrikam has a website that allows their retailers to get information about bikes, make purchases, and so on.

When a new retailer (Bob) starts a business and wants to sell Fabrikam’s bikes, he contacts Fabrikam, signs some agreements, and tells Fabrikam about his employees: who should be allowed to use Fabrikam’s retailer website, who should be allowed to make purchases, and so on. Fabrikam issues a user name and password for each employee at Bob’s bike shop, and configures its website to grant those users different levels of access depending on their job.

Over time, Bob ends up doing business with lots of other bike manufacturers, each of which has their own proprietary mechanism for purchasing. Some use the web, and some rely on fax and phone calls. It’s easy for Bob to forget about all of these niggling details when he’s doing his best just to sell bikes every day. So when Alice joins as a new employee, it takes Bob awhile to remember that he has to call Fabrikam (and all of the other manufacturers) and let them know that Alice should be allowed to make purchases. Alice’s first few weeks on the job are a bit daunting as she learns all of the passwords she needs to know for the various systems she’ll be using, and she’ll be denied access to Fabrikam’s retailer website until Bob gets around to calling Fabrikam to add Alice as a user. What happens when Alice’s role in Bob’s company changes, or even worse, if she leaves the company entirely? When does Fabrikam find out about this?

What we have here are two companies that have established a trust relationship, a covenant, between one another. Fabrikam relies on Bob to indicate which employees should have access to Fabrikam’s resources, and what level of access each should have. Identity federation is all about automating this covenant. Since Fabrikam already trusts Bob to tell the truth about his employees, it makes sense to let Bob’s system authenticate those employees and automatically give Fabrikam the details about each employee’s current role in the company.

Once Bob is responsible for authenticating his own staff, Fabrikam no longer has to issue user accounts for Bob’s employees. When Alice logs into her computer at Bob’s bike shop, that login can be used to tell Fabrikam who Alice is, and what role she plays in Bob’s organization. If Alice leaves the company, all Bob has to remember to do is disable her user account, and she’ll no longer be able to use Fabrikam’s website, or any other manufacturer’s website that federates with Bob. When Alice changes jobs, and Bob adjusts her group memberships in his directory, Fabrikam discovers that change the next time Alice logs on and uses Fabrikam’s web application. What we have now is single sign-on across organizations, and this is a good thing, not just for developers, but for IT pros, users, and shareholders alike.

Even within a single company, federation can be useful. If you end up with two different implementations, say Java-based and Microsoft .NET-connected, as long as your applications are built to support federated identity, you have a clear path to achieve single sign-on, and all of the benefits it provides.

Identity federation works by introducing a second issuer. Your applications still trust the same STS they used to, and it will continue to issue all of the tokens that your application needs. But now instead of directly authenticating all users directly, your STS will be configured to accept SAML tokens from partner organizations, leaving it to them to authenticate users in their own realm in a way that makes sense.

In Figure 4, the client is in a different security realm over in Bob’s bike shop, while the relying party is still in Fabrikam’s data center. In this case, the client (Alice, say) authenticates with Bob’s STS (1) and gets a security token that she can send to Fabrikam. This token indicates that Alice has been authenticated by Bob’s security infrastructure, and includes claims that specify what roles she plays in Bob’s organization. The client sends this token to Fabrikam’s STS, where it evaluates the claims, decides whether Alice should be allowed to access the relying party in question, and issues a second security token that contains the claims the relying party expects.

The client sends this second token to the relying party(3), which now discovers Alice as a new user, and allows her to access the application according to the claims issued by Fabrikam’s STS.
Note that the relying party didn’t have to concern itself with validating a security token from Bob’s bike shop. Fabrikam’s authority did all of that heavy lifting: making certain to issue security tokens only to trusted partners that have previously established a relationship with Fabrikam. In this example, the relying party will always get tokens from its own STS. If it sees a token from anywhere else, it will reject it outright. This keeps your applications as simple as possible.

Figure 5 shows a company that uses .NET Framework and Geneva Framework to build its applications. They have recently merged with another company whose IT platform is based on Java. Because the Microsoft .NET-connected applications are already claims-aware, the company was able to install an STS built on Java technology and suddenly the Microsoft .NET-connected applications became accessible to users in the Java-based directory, with no changes to application code or even application configuration.

Source: Microsoft Geneva Website
http://msdn.microsoft.com/en-us/security/aa570351.aspx

Claims-based Authentication / Claims-based identity model

Claims-based Authentication / Claims-based identity model
When you build claims-aware applications, the user presents her identity to your application as a set of claims (see Figure 1). One claim could be the user’s name, another might be her email address. The idea here is that an external identity system is configured to give your application everything it needs to know about the user with each request she makes, along with cryptographic assurance that the identity data you receive comes from a trusted source.

Figure 1: User Presents Claims

Under this model, single sign-on is much easier to achieve, and your application is no longer responsible for:
· Authenticating users
· Storing user accounts and passwords
· Calling to enterprise directories to look up user identity details
· Integrating with identity systems from other platforms or companies

Under this model, your application makes identity-related decisions based on claims supplied by the user. This could be anything from simple application personalization with the user’s first name, to authorizing the user to access higher valued features and resources in your application.

It’s not Just About Federation

The claims-based model of identity has been incubating for awhile now inside Microsoft. The original reason for proposing this model was to enable federation between organizations, but over time it’s become apparent that claims aren’t just for federation. But some of these terms still linger on. For example, when you use Geneva Framework in your ASP.NET application, one way to perform claims processing is to enable an Geneva Framework component called the WS-Federation Authentication Module. Don’t let the word “federation” throw you off. There are clear benefits to building applications that outsource authentication and authorization. Any company that has, or plans to have in the future, more than one web application or web service, can benefit by starting with a claims-based model for identity.

Introduction to Claims-Based Identity

In this section of the paper, I’m going to introduce some terminology and concepts so that you, as a developer, can get your head around this new architecture for identity. Let’s start with some terminology.

Identity

The word “identity” is a very overloaded term. So far I’ve been using it to describe the problem space that includes authentication, authorization, etc. But for the purposes of describing the programming model in Geneva Framework, I will use the term identity to describe a set of attributes (well, claims as you’ll see shortly) that describe a user or some other entity in the system that you care about from a security standpoint.

Claim

You can think of a claim as a bit of identity information such as name, email address, age, membership in the Sales role, and so on. The more claims your application receives, the more you’ll know about your user. You may be wondering why I’m using the word “claim”, instead of the more traditional “attributes”, commonly used in the enterprise directory world. The reason has to do with the delivery method – in this model your application doesn’t look up user attributes in a directory. Instead, the user delivers claims to your application, and you’re going to examine them with a certain measure of doubt.

Each claim is made by an issuer, and you’ll trust the claim only as much as you trust the issuer. You’ll trust a claim made by your company’s domain controller more than you would if it were made by the user herself! As you’ll see shortly, the Claim class in Geneva Framework has an Issuer property that allows you to find out who issued the claim.

Security Token

The user delivers a set of claims to your application piggybacked along with her request. In a web service, these claims are carried in the security header of the SOAP envelope. In a browser-based web application, the claims arrive via an HTTP POST from the user’s browser, and may later be cached in a cookie if a session is desired. Regardless of how they arrive, they must be serialized somehow, and this is where security tokens come in. A security token is a serialized set of claims that is digitally signed by the issuing authority. The signature is important – it gives you assurance that the user didn’t just make up a bunch of claims and send them to you. In low security situations where cryptography isn’t necessary or desired, you can use unsigned tokens, but that’s not a scenario I’m going to focus on in this paper.

One of the core features in Geneva Framework is the ability to create and read security tokens. Geneva Framework and the underlying plumbing in the .NET Framework handles all the cryptographic heavy lifting, and presents your application with a set of claims that you can read.

Issuing Authority

There are lots of different types of issuing authorities, from domain controllers that issue Kerberos tickets, to certificate authorities that issue X.509 certificates, but the specific type of authority I’ll be talking about in this paper issues security tokens that contain claims. The issuing authority I’m speaking of is a web application or web service that knows how to issue security tokens. It must have enough knowledge to be able to issue the proper claims for the target relying party given the user making the request, and may be responsible for interacting with user stores to look up claims and authenticate the users themselves.
Whatever issuing authority you choose to buy or build, it will play a central role in your identity solution. When you factor authentication out of your application by relying on claims, you’re ultimately just passing responsibility to that authority and asking it to authenticate users on your behalf.

Security Token Service (STS)

A security token service (STS) is the plumbing that builds, signs, and issues security tokens according to the interoperable protocols that I’ll discuss in the upcoming section called Standards. There’s a lot of work that goes into implementing these protocols, but Geneva Framework does all of this heavy lifting for you, making it feasible for someone who isn’t an expert in the protocols to get an STS up and running with very little effort.
Geneva Server, one of the products featured in Geneva technologies, is a security token service that you can use instead of building your own STS. You might be wondering what Geneva Server uses for implementing the protocols and building a security token. Yes, you guessed it right, it uses Geneva Framework for all of this heavy lifting.

If you want to build your own STS, Geneva Framework offers all the necessary APIs to make your job easy. It’s up to you to figure out how to implement the logic, or rules that drive it (often referred to as security policy).

Relying Party (RP)

When you build an application that relies on claims, you are building a relying party. Some synonyms that you may have heard are, claims aware application, or claims-based application. Web applications and web services can both be built this way, as you’ll see later in this paper.

Basic Scenario

Now that you’ve learned some basic terminology, here’s an example of a claims-based system in action.

Figure 2 shows a claims-aware web service (the relying party) and a smart client that wants to use that service. The relying party exposes policy that describes its addresses, bindings, and contracts. But the policy also includes a list of claims that the relying party needs, for example user name, email address, and role memberships. The policy also tells the smart client the address of the STS (another web service in the system) where it should retrieve these claims. After retrieving this policy (1), the client now knows where to go to authenticate: the STS. The smart client makes a web service request (2) to the STS, requesting the claims that the relying party asked for via its policy. The job of the STS is to authenticate the user and return a security token that gives the relying party all of the claims it needs. The smart client then makes its request to the relying party(3), sending the security token along in the security SOAP header. The relying party now receives claims with each request, and simply rejects any requests that don’t include a security token from the issuing authority that it trusts.

Standards

In order to make all of this interoperable, several WS-* standards are used in the above scenario. Policy is retrieved using HTTP GET and the policy itself is structured according to the WS-Policy specification. The STS exposes endpoints that implement the WS-Trust specification, which describes how to request and receive security tokens. Most STSs today issue SAML tokens (Security Assertion Markup Language). SAML is an industry-recognized XML vocabulary that can be used to represent claims in an interoperable way. This adherence to standards means that you can purchase an STS instead of building it yourself. Or, if you end up in a sticky multi-platform situation, this allows you to communicate with an STS on an entirely different platform and achieve single sign-on across all of your applications, regardless of platform. Identity federation also becomes an option, as I’ll explain shortly.

Browser-based Applications

Smart clients aren’t the only ones who can participate in the world of claims-based identity. Browser-based applications (also referred to as passive clients ) can participate as well. Figure 3 shows how this works. The user points her browser at a claims-aware web application (relying party). The web application redirects the browser to the STS so the user can be authenticated.

The STS in Figure 3 is wrapped by a simple web application that reads the incoming request, authenticates the user via standard HTTP mechanisms, and then creates a SAML token and emits a bit of JavaScript that causes the browser to initiate an HTTP POST that sends the SAML token back to the relying party. The SAML token in the POST body contains the claims that the relying party requested. At this point it is common for the relying party to package the claims into a cookie so that the user doesn’t have to be redirected for each 3 request. The WS-Federation specification includes a section that describes how to do these things in an interoperable way.

Identity Federation

When you build claims-aware web applications and services, you decouple yourself from any one user store. All you want to know is that an authority you trust has given you the identity details you need about the user who is using your application. You don’t have to worry about what domain or security realm that user happens to be part of. This makes it a lot easier to federate identity with other platforms or organizations.

Here’s a concrete scenario that will help get your head around this idea. Let’s say a company called Fabrikam is in the business of manufacturing bicycles, and thousands of bike shops around the world carry their bikes. Fabrikam has a website that allows their retailers to get information about bikes, make purchases, and so on.

When a new retailer (Bob) starts a business and wants to sell Fabrikam’s bikes, he contacts Fabrikam, signs some agreements, and tells Fabrikam about his employees: who should be allowed to use Fabrikam’s retailer website, who should be allowed to make purchases, and so on. Fabrikam issues a user name and password for each employee at Bob’s bike shop, and configures its website to grant those users different levels of access depending on their job.

Over time, Bob ends up doing business with lots of other bike manufacturers, each of which has their own proprietary mechanism for purchasing. Some use the web, and some rely on fax and phone calls. It’s easy for Bob to forget about all of these niggling details when he’s doing his best just to sell bikes every day. So when Alice joins as a new employee, it takes Bob awhile to remember that he has to call Fabrikam (and all of the other manufacturers) and let them know that Alice should be allowed to make purchases. Alice’s first few weeks on the job are a bit daunting as she learns all of the passwords she needs to know for the various systems she’ll be using, and she’ll be denied access to Fabrikam’s retailer website until Bob gets around to calling Fabrikam to add Alice as a user. What happens when Alice’s role in Bob’s company changes, or even worse, if she leaves the company entirely? When does Fabrikam find out about this?

What we have here are two companies that have established a trust relationship, a covenant, between one another. Fabrikam relies on Bob to indicate which employees should have access to Fabrikam’s resources, and what level of access each should have. Identity federation is all about automating this covenant. Since Fabrikam already trusts Bob to tell the truth about his employees, it makes sense to let Bob’s system authenticate those employees and automatically give Fabrikam the details about each employee’s current role in the company.

Once Bob is responsible for authenticating his own staff, Fabrikam no longer has to issue user accounts for Bob’s employees. When Alice logs into her computer at Bob’s bike shop, that login can be used to tell Fabrikam who Alice is, and what role she plays in Bob’s organization. If Alice leaves the company, all Bob has to remember to do is disable her user account, and she’ll no longer be able to use Fabrikam’s website, or any other manufacturer’s website that federates with Bob. When Alice changes jobs, and Bob adjusts her group memberships in his directory, Fabrikam discovers that change the next time Alice logs on and uses Fabrikam’s web application. What we have now is single sign-on across organizations, and this is a good thing, not just for developers, but for IT pros, users, and shareholders alike.

Even within a single company, federation can be useful. If you end up with two different implementations, say Java-based and Microsoft .NET-connected, as long as your applications are built to support federated identity, you have a clear path to achieve single sign-on, and all of the benefits it provides.

Identity federation works by introducing a second issuer. Your applications still trust the same STS they used to, and it will continue to issue all of the tokens that your application needs. But now instead of directly authenticating all users directly, your STS will be configured to accept SAML tokens from partner organizations, leaving it to them to authenticate users in their own realm in a way that makes sense.

In Figure 4, the client is in a different security realm over in Bob’s bike shop, while the relying party is still in Fabrikam’s data center. In this case, the client (Alice, say) authenticates with Bob’s STS (1) and gets a security token that she can send to Fabrikam. This token indicates that Alice has been authenticated by Bob’s security infrastructure, and includes claims that specify what roles she plays in Bob’s organization. The client sends this token to Fabrikam’s STS, where it evaluates the claims, decides whether Alice should be allowed to access the relying party in question, and issues a second security token that contains the claims the relying party expects.

The client sends this second token to the relying party(3), which now discovers Alice as a new user, and allows her to access the application according to the claims issued by Fabrikam’s STS.
Note that the relying party didn’t have to concern itself with validating a security token from Bob’s bike shop. Fabrikam’s authority did all of that heavy lifting: making certain to issue security tokens only to trusted partners that have previously established a relationship with Fabrikam. In this example, the relying party will always get tokens from its own STS. If it sees a token from anywhere else, it will reject it outright. This keeps your applications as simple as possible.

Figure 5 shows a company that uses .NET Framework and Geneva Framework to build its applications. They have recently merged with another company whose IT platform is based on Java. Because the Microsoft .NET-connected applications are already claims-aware, the company was able to install an STS built on Java technology and suddenly the Microsoft .NET-connected applications became accessible to users in the Java-based directory, with no changes to application code or even application configuration.

Source: Microsoft Geneva Website
http://msdn.microsoft.com/en-us/security/aa570351.aspx