Windows Azure based on claim identity, single sign-on

Claim identity is a simple and powerful way to handle the identity authentication and access of Web sites and Web services, whether you are working locally or facing the cloud.

You can create a more secure application by reducing your custom implementation and using a single simplified identity model based on claim.

Windows Identity Foundation (WIF) is a set of. NET Framework classes. It is a framework for implementing an claim identity in your application.

Architecturally, using an claim identity can detach an application from the authentication business. Single sign-on becomes easier to implement, and your application is no longer responsible for the following operations:

authenticate the user. Store user accounts and passwords. Call the enterprise directory to find the user identification details. Integration with other platforms or corporate identity systems.

Instead, your application uses the security token that the authority sends to your application that contains claim. SecurityToken Services (STS) is a service that builds, signs, and issues security token according to interoperable protocols. Your application is relying party.

Claim. Claim is the user information your application needs to know. For example, the user's name or e-mail address, or whether it is in a sales organization. Your application will accept claim from the following sources:

Security token. In Web services, these claim are included in the security header of the SOAP envelop. In a browser-based Web application, claim arrives from the user's browser via an HTTP POST and may later be cached in a cookie if a session is required.

Authority. The authority is a Web application or Web service that knows how to issue a secure token. In a claim-based identity scheme, the Authority is responsible for publishing the appropriate claim (such as name and e-mail messages or whether the person is in a sales organization).

Security Token Service (STS). STS is also trusted by both client and WEB services to provide interoperable security token.

Relying party. That is, your application or WEB service. It is often described as a claim aware application or a claim based application.

SAML Token. Most existing STS will issue the SAML (Security assertion Markup Language) token. SAML is an industry-recognized xml-based language that can be used to render claim in an interoperable way.

Scene

There are many kinds of scenes. In my chosen scenario, the user points his browser to the claim Awareweb application (relying party). The WEB application redirects the browser to the STS to authenticate the user.

The STS is a simple WEB application that reads incoming requests, authenticates the user through a standard HTTP mechanism, and then creates a SAML token and generates a section of JavaScript, causing the browser to send an HTTP post that will SAML Token sent back to relying party.

The SAML token in the POST body contains the claim requested by the relying party.

Your application accepts the SAML token and uses several lines of code to parse the token and extract claim through Windows Identity Foundation. You can now access the requested data, such as name, e-mail, and whether the person is in the sales organization.

We offer a lot of other options. This particular scenario uses WS.

You don't have to worry about exactly what domain or part of the security domain your users are. In fact, you can support Facebook identities, Windows Live, Google IDs, or user claim based on the Active Directory. Using claim identities makes it easier to combine identities with other platforms or organizations.

Claim object model for Windows Identity Foundation

When you use WIF to build a relying party, WIF will mask all the heavy tasks associated with encryption, WIF (and its underlying WCF) will perform these tasks for you. It decrypts the security token delivered from the client, verifies its signature, verifies any proof keys, divides token into a set of claim, and renders it to you through an Easy-to-use object model.

In your code, you can ask token to get each claim you want.

The following is an example of returning an e-mail address.

Protected
String getUserEmail (object sender, EventArgs e)

{

Iclaimsidentity ID =
((Iclaimsprincipal) Thread.CurrentPrincipal). Identities[0];

Can use a simple foreach loop to
Find a claim ...

string usersemail = null;

foreach (Claim c in ID. Claims) {

if (c.claimtype
= = Claimtypes.email) {

Usersemail = C.value;

Break;

}

return usersemail;

}

The code assumes that the caller has been authenticated and that she and the e-mail address have been sent as claim. The reason this program can make this assumption is because it has a Web.config file that uses Ws-federation authentication Module (FAM) in WIF and has an STS address configured to authenticate users and provide these types of claim.

FAM is a httpmodule specifically designed to simplify the process of building federated WEB applications using asp.net2.0 to build claim aware.

Therefore, some information is required in Web.config, as described in the Microsoft Windows Identity Foundation (WIF) Developer's white paper.

WIF provides a built-in Visual Studio project template for creating claim awareasp.net applications or claim AWAREWCF services. So you can have a good start.

Write your own STS

You may already be maintaining a list of members for your user name, name, and password. You can create your own STS to provide identification.

STS accepts incoming requests, validates and decrypts them, divides them into claim, and performs the opposite operation for outgoing security token. WIF is responsible for all these heavy tasks.

Note: WIF does not provide a framework for managing policies that you can view as the logic or rule of STS background.

Transforming the ASP.net membership provider to STS

If you are using the ASP.net membership provider, you can turn it into STS, making it one of the providers that your users can use to access your application. You can do this by adding a simple STS asp.net a Web site based on the membership provider. By adding a simple page containing WIF code, your partner can accept that your users are using their Web site, or even enable a single sign-on for users who have logged on to your site. See Using the Identity Provider feature to improve the ASP.net membership provider Web site.

Provide single sign-on

As long as your application uses claim, you can add additional landings more easily. The application only focuses on whether token is provided by a trusted provider. STS provides information required by an application, such as name, e-mail, or whether this person is a sales role.

Single sign-on (SSO) means that a user's token is trusted in multiple IT systems or even multiple organizations. Your application can use federated identities as a means of linking users ' electronic identities and attributes (stored in multiple different identity management systems).

In many scenarios, the STS that provides user claims runs as your application within the same organization. But now your application can take advantage of the STS outside the organization.

As long as the application trusts the federated provider Sts,sts can run anywhere-even in the cloud.

Windows Azure access Control is a federated provider STS running in the cloud. When you connect to other organizations, Active Directory that provides token may not be able to represent roles in the same way as the organization. Access control can map the roles of various providers directly to the names used by your application.

You can even allow you to log on from other providers, such as Facebook, Google, Windows Live, or Yahoo.

I'll introduce access control in the next section of this series.

Windows Identity Foundation Background

Windows identity Foundation is part of a Microsoft identity authentication and access management solution built on Active Directory. Active Directory also includes the following:

Active Directory Federation Services 2.0: An IT security token service that can issue and transform claim and other token, manage user access, and implement federated and access management to simplify single sign-on. Windows Azure Access Control Service: Provides a simple way to provide authentication and access control for WEB applications and services, and integrates with standards-based identity providers, including the enterprise's Active Directory (such as Active Directory) and Web identities, such as Windows Live ID, Google, Yahoo!, and Facebook.

Getting Started with Windows Identity Foundation

See the claims-based Architecture white paper written by David Chappell. Gets the Windows Identity Foundation. Windows Identity Foundation Reference on MSDN.

. You can learn about identity training courses first. The video and hands-on experiments in the Identify developer training course will show you how to use technologies such as Windows identity Foundation and Windows Azure appfabricaccess Control Service to easily resolve authentication , authorization and identity drive personalized challenges. After completing this course, you will soon find that the claim identity gives you the skills you need to reuse to protect the security of various applications, including from the ASP.net web site to the WCF Web service.

. See also the Microsoft Windows identity Foundation (WIF) Developer's white Paper, which describes how to start building with Microsoft Windows identity Foundation claim Aware application.