Claims-Based Identity Blog

Announcing July 2011 update to Access Control Service 2.0

2011-07-25T08:30:00Z

Windows Azure AppFabric Access Control Service (ACS) 2.0 received a service update. All customers with ACS 2.0 namespaces automatically received this update, which primarily contained bug fixes in addition to a few new features and service changes:

Localization in eleven languages

The ACS management portal is now available in 11 languages. Newly-supported languages include Japanese, German, Traditional Chinese, Simplified Chinese, French, Italian, Spanish, Korean, Russian, and Brazilian Portuguese. Users can choose their desired language from the language chooser in the upper-right corner of the portal.

Rules now support up to two input claims

The ACS 2.0 rules engine now supports a new type of rule that allows up to two input claims to be configured, instead of only one input claim. Rules with two input claims can be used to reduce the overall number of rules required to perform complex user authorization functions. For more information on rules with two input claims, see http://msdn.microsoft.com/en-us/library/gg185923.aspx.

Encoding is now UTF-8 for all OAuth 2.0 responses

In the initial release of ACS 2.0, the character encoding set for all HTTP responses from the OAuth 2.0 endpoint was US-ASCII. In the July 2011 update, the character encoding of HTTP responses is now set to UTF-8 to support extended character sets.

Quotas Removed

The previous quotas on configuration data have been removed in this update. This includes removal of all limitations on the number of identity providers, relying party applications, rule groups, rules, service identities, claim types, delegation records, issuers, keys, and addresses that can be created in a given ACS namespace.

Please use the following resources to learn more about this release:

For any questions or feedback please visit the Security for the Windows Azure Platform forum.

If you have not signed up for Windows Azure AppFabric and would like to start using these new capabilities, be sure to take advantage of our free trial offer. Just click on the image below and get started today!

The Access Control Service Product Team

Announcing the WIF Extension for SAML 2.0 Protocol Community Technology Preview!

2011-05-16T13:17:00Z

It is our pleasure to announce the availability of the first CTP release of the WIF (Windows Identity Foundation) Extension for the SAML 2.0 Protocol ! We heard your feedback about the necessity to have support for the SAML 2.0 protocol in WIF. Today, we announce an extension to WIF that delivers on that feedback.

This WIF extension allows .NET developers to easily create claims-based SP-Lite compliant Service Provider applications that use SAML 2.0 conformant identity providers such as AD FS 2.0.

This CTP release includes a set of samples that illustrate how to use the extension. You can download the package that includes the WIF Extension for SAML 2.0 Protocol and samples from here.

Key features of this extension include:

Service Provider initiated and Identity Provider initiated Web Single Sign-on (SSO) and Single Logout (SLO)
Support for the Redirect, POST, and Artifact bindings
All of the necessary components to create a SP-lite compliant service provider application

We’ll be looking for your questions, comments, and other feedback on the claims based identity forum here. Watch this blog for future posts about the roadmap of this WIF extension.

Happy coding!

The WIF Team

AD FS 2.0 Content Map is published

2011-04-21T17:56:00Z

We have published an AD FS 2.0 content map wiki page which is intended to act as a content map for all members of the AD FS 2.0 community.

This is an on-going effort. Members of the AD FS product team will monitor this article on a regular basis and will post new links as they become available on Microsoft.com. The following is the current TOC list of this article:

We would like to enlist your help in adding useful links to this article in order to make hot AD FS 2.0 topics and solutions more discoverable to the overall community. If you know any useful AD FS 2.0 content that that is not listed in this article or if you would like to have a hot AD FS 2.0 topic documented, please send your feedback to AD FS Product Team.

Windows Azure AppFabric Access Control Service released!

2011-04-12T22:00:00Z

We are very happy to announce the general availability of the April release of Windows Azure AppFabric Access Control Service!

The new version of the Access Control Service includes all the great capabilities and enhancements that have been available in the Labs release of the service for several months. Now you can start using these capabilities in production.

The new version of the service adds the following capabilities:

Federation provider and Security Token Service

Out of box federation with Active Directory Federation Services 2.0, Windows Live ID, Google, Yahoo, Facebook

New authorization scenarios

Delegation using OAuth 2.0

Improved developer experience

New web-based management portal
Fully programmatic management using OData
Works with Windows Identity Foundation

Additional protocol support

WS-Federation, WS-Trust, OpenID 2.0, OAuth 2.0 (Draft 13)

This release represents a major enhancement to the previous version of Access Control Service, enabling new web application and web service federation scenarios. What’s more, we are excited to announce that Access Control Service will be offered at no charge during the promotion period ending January 1, 2012!

Please use the following resources to learn more about this release:

If you have any questions, be sure to visit the Security for the Windows Azure Platform section of the MSDN forums.

If you have not signed up for Windows Azure AppFabric and would like to start using these great new capabilities, be sure to take advantage of our free trial offer. Just click on the image below and get started today!

The Access Control Service Product Team

AD FS 2.0 Step-by-Step Guide: Federation with IBM Tivoli Federated Identity Manager

2011-04-04T20:48:23Z

We have published a step-by-step guide on how to configure AD FS 2.0 and IBM Tivoli Federated Identity Manager to federate using the SAML 2.0 protocol. You can view the guide as a web page and soon also in Word and PDF formats. This is the fifth in a series of these guides; the guides are also available on the AD FS 2.0 Step-by-Step and How-To Guides page.

Beyond Windows CardSpace

2011-02-15T15:59:00Z

For several years Microsoft has advocated the claims based identity model for more secure access and use of online applications and services. With enhancements to our existing platform, such as Active Directory Federation Services 2.0 and Windows Identity Foundation, we’ve made progress in that initiative. Claims-based identity is used widely inside Microsoft and is now part of many Microsoft products, such as SharePoint, Office 365, Dynamics CRM, and Windows Azure.

Microsoft has been a leading participant in the identity community and an active contributor to emerging identity standards. We have increased our commitment to standardization activities and added support into our products for the SAML 2.0, OpenID 2.0, OAuth WRAP and OAuth 2.0 protocols.

There is one component of our identity portfolio where we have recently decided to make a change. Windows CardSpace was initially released and developed before the pervasive use of online identities across multiple services. Perhaps more importantly, we released the user component before we and others had delivered the tools for developers and administrators to easily create claims-ready services. The identity landscape has changed with the evolution of tools and cloud services. Based on the feedback we have received from partners and beta participants, we have decided not to ship Windows CardSpace 2.0.

Claims-based identity remains a central concept for Microsoft’s identity strategy, and its role in our overall strategy continues to grow. Furthermore, we are not abandoning the idea of a user agent for exchanging claims. As part of our work on claims-based identity we are releasing a new technology preview of U-Prove. This release of U-Prove will take the form of a user agent that takes account of cloud computing realities and takes advantage of the high-end security and privacy capabilities within the extended U-Prove cryptographic technology.

Single Sign-On to Windows Azure using WIF and ADFS whitepaper now available

2011-01-05T16:54:00Z

We have published a whitepaper on how to enable Single Sign-On to Windows Azure using WIF and ADFS.

Here is the abstract:

This paper contains step-by-step instructions for using Windows® Identity Foundation, Windows Azure, and Active Directory Federation Services (AD FS) 2.0 for achieving SSO across web applications that are deployed both on premises and in the cloud. Previous knowledge of these products is not required for completing the proof of concept (POC) configuration. This document is meant to be an introductory document, and it ties together examples from each component into a single, end-to-end example.

Download it here!

Protecting and consuming REST based resources with ACS, WIF, and the OAuth 2.0 protocol

2010-11-29T23:45:04Z

ACS (Azure Access Control Service) recently added support for the OAuth 2.0 protocol. If you haven’t heard of it, OAuth is an open protocol that is being developed by members of the identity community to solve the problem of allowing 3rd party applications to access their data without providing their passwords. In order to show how this can be done with WIF and ACS, we have posted a sample on Microsoft Connect that shows an end-to-end scenario.

The scenario in the sample is meant to be as simple as possible to show the power of the OAuth protocol to enable web sites to access resource on behalf of a user without the user providing his or her credentials to that site. In our scenario, Contoso has a web service that exposes customer information that needs to be protected. Fabrikam has a web site and wants users to be able to view their Contoso data directly on it. The user doesn’t have to log in to the Fabrikam site, but gets redirected to a Contoso specific site in order to login and give consent to access data on their behalf.

The Contoso web service requires OAuth access tokens from ACS to be attached to incoming requests. The necessary protocol flow for the Fabrikam web site (in OAuth terms – the web server client), including redirecting the user to login and give consent, requesting access tokens from ACS, and attaching the token to outgoing requests to the service is taken care of under the covers. The sample contains a walkthrough that describes the components in more detail.

Try it out here, and tell us what you think!

AD FS 2.0 Step-by-Step Guide: Federation with Ping Identity PingFederate

2010-11-23T01:06:00Z

We have published a step-by-step guide on how to configure AD FS 2.0 and Ping Identity PingFederate to federate using the SAML 2.0 protocol. You can view the guide in docx, doc, or PDF formats and also as a web page. This is the fourth in a series of these guides; the guides are also available on the AD FS 2.0 Step-by-Step and How-To Guides page. Special thanks to Ping Identity for sponsoring this guide.

Access Control for Windows Phone 7 Apps

2010-11-06T05:17:00Z

With the U.S. release of Windows Phone 7 around the corner, I’m excited to share a sample that shows some of our early thinking around how ACS in LABS can be used to enable sign in to web services… from the phone apps.

This makes it simple to write REST services, for Windows Phone 7 Silverlight applications, that can be used millions of users, including those at Live ID, Facebook, Google, Yahoo and AD FS accounts.

To see it in action, check out Vittorio’s PDC talk. The sample appears in the last few minutes, but I recommend watching the full talk.

As an early sample of how mobile apps may be supported, your feedback is very valuable. Download it and try it out!

Caleb Baker

Program Manager - Access Control Services

AD FS 2.0 Step-by-Step Guide: Federation with Shibboleth 2 and the InCommon Federation

2010-10-22T02:43:00Z

We have published a step-by-step guide on how to configure AD FS 2.0 and Shibboleth to federate using the SAML 2.0 protocol. There is also an appendix on federating with the InCommon Federation. You can view the guide in docx format and as a web page. This is the third in a series of these guides; the guides are also available on the AD FS 2.0 Step-by-Step and How-To Guides page.

“Programming Windows Identity Foundation” is available!

2010-09-17T16:09:00Z

My name is Peter Kron and I’m a Principal Software Developer on the Windows Identity Foundation team. Over the last year it has been my pleasure to work with Vittorio Bertocci as the technical reviewer for his latest book, Programming Windows Identity Foundation. Many of you will recognize Vittorio from his engaging sessions at PDC, TechEd, IDWorld and other conferences, or follow his popular blog, Vibro.NET. He has also authored or co-authored other books for Microsoft Press.

Vittorio is a Senior Architect Evangelist with Microsoft and over the past five years has been active (and if you know Vittorio, you know that is very active) in helping customers develop SOA based on WCF and, most recently, Identity.

His experience working through real-world scenarios with numerous developers makes him an ideal choice to write this book. He knows the issues they have faced and how Microsoft technologies like WCF and WIF can be brought to bear on them. In this book, Vittorio takes the reader through basic scenarios and explains the power of claims. He shows how to quickly create a simple claims-based application using WIF. Beyond that, he systematically explores the extensibility points of WIF and how to use them to handle more sophisticated scenarios such as Single Sign-on, delegation, and claims transformation, among others.

Vittorio goes on to detail the major classes and methods used by WIF in both passive browser-based applications and active WCF services. Finally he explores using WIF as your applications move to cloud-based Windows Azure roles and RIA futures.

I think you’ll find this book a valuable tool for learning how to build claims-based web applications and services. Or you will keep a copy handy for reference, as I do. The book is available now from Microsoft Press, and all of the sample code described in the book is available for download.

All of us on the WIF team are happy to see this in print (and e-book)!

Demonstrating federation interop with CA, IBM, and Sun products

2010-09-03T20:40:24Z

Microsoft’s Patterns & Practices group recently wrote about three labs demonstrating federation interoperability between WIF and AD FS 2.0 and three other vendor products – specifically, CA SiteMinder 12.0, IBM Tivoli Federated Identity Manager 6.2, and Sun OpenSSO 8.0.

First, the team took the samples from the Claims Identity Guide and deployed them in a lab. They then configured the lab to use IBM, Computer Associates & Sun identity providers. Finally, they captured videos of demos for each configuration.

You can read about each of the labs here:

· Identity Federation Interoperability – WIF + ADFS + CA SiteMinder

· Identity Federation Interoperability – WIF + ADFS + IBM Tivoli Federated Identity Manager

· Identity Federation Interoperability – WIF + ADFS + Sun’s OpenSSO

Announcing Active Directory Federation Services 2.0 Management Pack for Microsoft System Center Operations Manager 2007

2010-08-06T20:37:00Z

Active Directory Federation Services (AD FS) 2.0 has just released its first Management Pack (MP) for Microsoft System Center Operations Manager 2007 Service Pack 1 (SP1) and R2!! We have worked on it for quite some time, and it is exciting to finally get it out!

As you may know, there is an MP for AD FS v1. This MP is for AD FS 2.0. The goal of the AD FS 2.0 MP is to help your IT operators easily monitor the health of the AD FS 2.0 service and its different parts as well as to provide them with troubleshooting content in case some issues arise. If it’s your first time hearing about MP, don’t worry. Let’s do a quick overview by first explaining what an MP is and why you may want to use one.

Note: if you already have System Center Operations Manager 2007, you can download and use the AD FS 2.0 MP for free! For details about System Center Operations Manager 2007 licensing, see How to Buy Operations Manager 2007 R2.

What is a Management Pack?

A management pack (MP) contains predefined monitoring rules and other settings to work with System Center Operations Manager. Each product defines its own MP. You must import the product’s MP into System Center Operations Manager to use it. After it is imported, the monitoring agent of System Center Operations Manager will run on the computers to monitor the health of a specific service or application based on the monitoring settings that are defined in the MP.

The predefined settings in the MP include the following:

· Discovery information that makes it possible for System Center Operations Manager to automatically detect and begin monitoring services and applications

· Monitoring and alert rules that change the health state of the monitored services or applications in System Center Operations Manager and generate alerts when the corresponding health condition is detected

· A knowledge base that contains error and troubleshooting information that is associated with the alerts

For more information about the MP concept and System Center Operations Manager, see Microsoft Systems Center Operations Manager.

Benefit of using a Management Pack

We mentioned that an MP provides the monitoring mechanism for services and applications. The audience for a MOM Pack is primarily IT operators. They care about whether their application is healthy, the users of their application are happy, and how well the parts of their applications work together. IT operators can use the MP to pinpoint what is broken so that they do not need to do a manual diagnosis. By using an MP, the IT operators can have a central view of the health of multiple services or applications that they are monitoring, and they can make sure that such health information is up to date as things change. Also, the MP provides a knowledge base, which IT operators can use to quickly troubleshoot a problem without looking at other resources.

So, we talked about some basic concepts of MP; let’s take a look at AD FS 2.0 MP. As you may know, AD FS 2.0 is a security token service that authenticates users and generates security tokens. We can logically divide AD FS 2.0 into different parts. You can use the AD FS 2.0 MP to monitor the health of each part of AD FS 2.0 service as well as the overall health of AD FS 2.0 service. The primary mechanism that the AD FS 2.0 MP uses for health monitoring is the AD FS 2.0 events. Of course, you may think “I can use Event Viewer to do the same thing.” However, there are benefits of using AD FS 2.0 MP instead of using Event Viewer:

· First, the AD FS 2.0 MP does the filtering and analysis of the events for you. It alerts you only when it is very likely that there is something broken (compared to intermittent problems). Also, it alerts you only once so that you won’t be flooded with hundreds of events, which makes it hard to figure out the root cause of a problem.

· Second, besides reactive monitoring, AD FS 2.0 MP also provides proactive monitoring, which can detect a problem before it happens. For example, AD FS 2.0 MP proactively monitors the expiration status of the Secure Sockets Layer (SSL) certificate that is configured for the federation passive website.

· Third, the AD FS 2.0 MP separates and scopes down the issues to a particular AD FS 2.0 component and provides rich knowledge about the issues, all of which help you troubleshoot quickly.

· Fourth, AD FS 2.0 MP also integrates performance monitoring and provides a diagram view of the performance. It is very easy for you to tell the performance pattern from the diagram.

The AD FS 2.0 MP provides 10 localized versions, one for each supported language, including the following: Spanish, French, Italian, Japanese, Korean, Chinese (China), Chinese (Taiwan), Russian, German, and Portugese-Brasilian.

Ok, that’s enough conceptual talk. Let’s look at this stuff in action!

What’s in the AD FS 2.0 MP?

We have talked about what an MP is and what the benefits of using an AD FS 2.0 MP are. So, what’s in an AD FS 2.0 MP, and how do we use it? Let’s take a closer look at the AD FS 2.0 MP.

The AD FS 2.0 MP provides an intuitive way for IT operators to get an overview the topology of AD FS 2.0 deployments in a farm, as well as the AD FS 2.0 configurations of a single instance. It also makes it possible for IT operators to monitor the health of AD FS 2.0 deployments and diagnose and fix the issues that affect AD FS 2.0 health.

In detail, the AD FS 2.0 MP has the following functionality:

• Discovers AD FS 2.0 deployment (in either the federation server role or the federation server proxy role) in a farm or on a single, monitored computer

• Discovers different AD FS 2.0 parts that have been deployed on the monitored computer

• Monitors the health of different AD FS 2.0 parts and generates appropriate alerts

• Monitors the performance of AD FS 2.0

• Provides diagnostic knowledge for each alert

AD FS 2.0 Views

The following illustration shows what the AD FS 2.0 views in System Center Operations Manager 2007 looks like. As you can see, the views include the State View, Alerts View, Events View, and Performance View. All of these views are defined for each AD FS 2.0 role—federation server or federation server proxy. In the topmost State View, you can see the overall health state of the AD FS 2.0 service, as shown below. In this example, there is no federation server proxy discovered; so, the health state column for Federation Server Proxies is empty.

The following illustration shows the Performance View of one of the AD FS 2.0 federation servers being monitored. The performance area of the AD FS 2.0 service that is being monitored is Token Request per second.

AD FS 2.0 Discovery

The AD FS 2.0 MP can discover all the AD FS 2.0 instances in a farm. The following illustration shows an example of a State View of two AD FS 2.0 federation servers in a Windows Internal Database (WID) farm. As you can see, the parts that AD FS 2.0 is monitoring for the federation server are Trust Management and Authentication, which contain token issuance and token acceptance monitoring; WID Sync for the synchronization among primary and secondary computers, Web Sites, and Certificate Management. For the federation server proxy, the parts that AD FS 2.0 MP monitors are Authentication and Web Sites.

Besides monitoring the health of these parts, the AD FS 2.0 MP also retrieves the important configuration information for each part (shown in the detail view in the previous illustration). In the previous example, the AD FS 2.0 MP detects that those two computers belong to a WID farm and that the highlighted computer in the farm is the primary computer in the farm.

You can also open the Diagram View to get an idea of the overall deployment topologies of the AD FS 2.0 servers and proxies. All the stand-alone federation servers are grouped under a single federation service node, and each farm has its own node. The following illustrationi shows an example. The AD FS 2.0 MP has detected an AD FS 2.0 farm that consists of two federation servers and one stand-alone AD FS 2.0 instance on the Adfsidentity computer.

The following illustration shows all the monitored AD FS 2.0 parts on one of the federation servers in the AD FS 2.0 farm.

AD FS 2.0 Monitoring

The AD FS 2.0 MP monitors the AD FS 2.0 service, based on two mechanisms: Events and Scripts. If any monitored event occurs, it changes the health state of the related AD FS 2.0 component or generates an alert or both. AD FS 2.0 also has its own PowerShell based scripts that run periodically to monitor the health of different AD FS 2.0 parts proactively (See AD FS 2.0 MP Guide for a complete set of AD FS 2.0 monitoring scripts). Also, we have defined custom overrides in the MP for different script-based objects apart from the standard objects that System Center Operations Manager provides. Users can override the default values, such as the frequency, to run the scripts.

The health state of AD FS 2.0 parts are changes, based on the rules that are defined in the MP. It is reset to Healthy state in two cases automatically:

1. When there is a clear counter event that indicates that the issue has been resolved.

2. After some period of time, if there is no indication that this problem still persists, the health state resets.

The default time for 2 is 15 minutes, which the user can override. Besides these two conditions, you have to manually reset the AD FS 2.0 health state after you make sure that the corresponding issue has been resolved.

The following is an illustration of the Alert View that shows the Alerts that the AD FS 2.0 MP generated. The following example is an alert for Trust Management because AD FS 2.0 failed to create the Federation Metadata document. The knowledge for this alert contains a summary of this monitoring, a description of the cause of this alert, and the detailed steps for resolution.

To avoid duplicate alerts, the AD FS 2.0 MP has implemented a monitoring mechanism, provided by System Center Operations Manager 2007, called Alert Suppression. In events occur, the same events may be generated multiple times for the same issue and continue to be generated as long as the issue still exists. For example, federation passive requests may fail because the web.config file is corrupted. When this issue is mapped to an alert in the AD FS 2.0 MP, only one alert is generated, even when this issue triggers a lot of events. Basically, the AD FS 2.0 MP analyzes the events per root cause and generates an alert per root cause accordingly.

Also, to avoid over-alerting, AD FS 2.0 refrains from generating alerts for issues that may be caused by intermittent problems. For example, the AD FS 2.0 MP waits for multiple occurrences of events that indicate that the AD FS 2.0 service cannot reach a domain controller before it generates an alert. For a detailed look at how the AD FS 2.0 MP implements alert suppression and event counting for key monitoring scenarios, see the AD FS 2.0 MP Guide.

To summarize:

· The AD FS 2.0 MP uses events and scripts to monitor the health of the AD FS 2.0 service. Scripts are used for proactive monitoring, such as detecting whether the federation passive website is up and running and whether the SSL certificate is expiring.

· The health state of the AD FS 2.0 service and its parts may be autoreset or need manual reset, depending on the conditions.

· The AD FS 2.0 MP generates alerts when an issue is detected. An alert contains rich knowledge that can help troubleshooting.

· The AD FS 2.0 MP implements alert suppression and event counting so that your Alert View is not flooded with duplicate alerts or alerts that may not indicate a persistent issue.

Where to download AD FS 2.0 MP

Feel like you have a good understanding of what AD FS 2.0 MP has to offer? Give it a try! You can download the AD FS 2.0 MP and AD FS 2.0 MP Guide at Active Directory Federation Services 2.0 (ADFS) Monitoring Management Pack.

The AD FS 2.0 MP supports localization of 10 languages. Choose the language of the MP in the drop-down list when you download the MP. This action redirects you to the localized download page where you can download the localized MP guide as well.

Have fun trying it out! J

AD FS 2.0 Step-by-Step Guide: Federation with Oracle Identity Federation

2010-08-02T22:56:37Z

We have published a step-by-step guide on how to configure AD FS 2.0 and Oracle Identity Federation to federate using the SAML 2.0 protocol. You can view the guide either as a web page or in docx format. This is the second in a series of these guides; the guides are also available on the AD FS 2.0 Step-by-Step and How To Guides page.

AD FS 2.0 Step-by-Step Guide: Federation with CA Federation Manager

2010-07-16T19:10:13Z

We have published a step-by-step guide on how to configure AD FS 2.0 and CA Federation Manager to federate using the SAML 2.0 protocol. You can view the guide either as a web page or in docx format. This is the first in a series of these guides; the guides are also available on the AD FS 2.0 Step-by-Step and How To Guides page.

The Federated Identity Forum

2010-07-15T19:12:52Z

In order to consolidate our support for our Federated Identity platforms, we are removing the 'Email the Blog Author' functionality of this blog and reccomending that anyone with questions related to the AD FS, WIF, or CardSpace head over to our forum, located here.

This forum is actively monitored by members of the product group, as well as MVPs and the community. We hope that we will better be able to provide support and answer your questions by directing them all through this single forum.

-The AD FS, WIF, and CardSpace teams

WIF Workshops, June 2010 update for Identity Training Kit, and a Patterns & Practices Guide on “Claims-based Identity”

2010-06-30T18:26:22Z

Vittorio in DPE (Developer Platform and Evangelism) team has been touring the world evangelizing claims based identity model and WIF. As a result, there is an excellent set of resources for you to learn WIF! Check out the 10-part WIF Workshop recordings that cover the topics such as basics of claims-based identity and WIF, the scenarios that WIF enables, how WIF plugs into the ASP.NET pipeline, how WIF plays with WCF, and how WIF plays a key role for identity management in Azure. If you want to grab the presentation decks of these WIF Workshops, check out the latest June 2010 update of the Identity Developer Training Kit.

Eugenio Pace in Patterns & Practices team has published a guide on “Claims-based Identity and Access Control”. It is an excellent guide to understand the benefits of claims-based identity model when you are planning a new application or making changes to existing applications that require user identity information. You can also purchase a hard copy of this guide from your favorite online book stores.

Other References and Resources:

Azure team’s recent blog post on WIF in Azure

WIF Product Documentation on MSDN

WIF Whitepaper for Developers

Happy coding with WIF!

Sesha Mani

On behalf of WIF Team

Using Federation Metadata to establish a Relying Party Trust in AD FS 2.0

2010-06-25T00:38:28Z

Trust relationships are of course the sine qua non of AD FS 2.0. Relying Party Trusts or Claims Provider Trusts are necessary before AD FS 2.0 can provide benefit to any organization. That said, the establishment and maintenance of these relationships can be a time consuming task. Fortunately there are methods available that make this job significantly easier. AD FS provides three methods for creating Relying Party Trusts and Claims Provider Trusts. Manual entry of the necessary information is the most familiar method, but also the most time consuming and difficult to maintain. Additionally a trust can be created by importing "federation metadata", that is, data that describes a Relying Party or Claims Provider and allows for easy creation of the corresponding trust. A federation metadata document is an XML document that conforms to the WS-Federation 1.2 schema. Federation metadata may be imported from a file, or the partner may make the data available via https. The latter method provides the most straightforward method for creating a partnership and greatly simplifies any ongoing maintenance that may be required.

Manually creating a Relying Party Trust requires that the Administrator supply a fair amount of information that must be obtained from the partner organization through some out of band communication. This information includes the URLs for the WS-Federation Passive protocol and\or the SAML 2.0 Web SSO protocol, one or more relying party identifiers and, typically, the X.509 Certificate used to encrypt any claims sent to the relying party. Figure 1 below shows the various pages of the Add Relying Party Trust Wizard that must be navigated in order to create a relying party trust.

Figure 1 - Manually adding a relying party trust.

Once the relying party trust is established, it must also be maintained. It is possible that one or more of the URL's that identify the relying party may change, or the set of claims that the relying party will accept might change, but more likely, the X.509 Certificate used for encryption will have to be replaced, either because it has expired or because it has become compromised. Managing the updating of encryption certificates across an organization that might contain hundreds, or thousands, of relying parties presents a daunting challenge.

Lets explore how we create a Relying Party Trust using federation metadata.

Figure 2 - Options for entering data for a Relying Party Trust

As you can see from figure 2, it is possible to provide the metadata in the form of a file, as well as by specifying an https address. For purposes of this article I will confine our discussion to the case where the metadata is provided via https.

Each AD FS 2.0federation servers configured by default to publish metadata describing itself via https. If you click on the Service\Endpoints folder in the AD FS 2.0 snap-in you can see the highlighted endpoint in question as shown below:

Figure 3 -Showing the federation metadata endpoint provided by AD FS 2.0

To see what the actual XML looks like you can enter the endpoint into your web browser, as shown below:

Figure 4 - Example of a Federation Metadata document describing the information that is published about a specific Federation Service

I'm not going to review the structure of the federation metadata document here, except to note that it is a signed document and should not be edited or reformatted by hand. Anyone who is interested in the details of the schema, can find the specification at . http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf Instead I want to walk through an example of how to establish a Relying Party Trust using federation metadata.

The first step, of course is to launch the Add Relying Party Trust Wizard and navigate to the select data source page:

Figure 5 - Providing a federation metadata endpoint to the Add Relying Party Trust wizard

If you are interested in creating a trust using federation metadata but don't have a partner handy that provides metadata, it is perfectly feasible to have AD FS create a trust with itself. Of course, this is obviously of little use in the real world, but it's perfectly suitable for purposes of illustration. The first step is to provide the https address of the metadata document. If you know the full URL you can provide it, or you can simply enter the host name, and AD FS will attempt to find the data at the most common location. In this case enter the name of your host machine (not fs.contoso.com) and hit the next button. AD FS will read the available metadata and use it to construct the Relying Party Trust.

Figure 6 - Prompting for the relying party display name after reading federation metadata

As we can see the wizard path is considerably shorter than in the manual entry case. SAML metadata does not typically provide a display name for the relying party trust, so we are prompted to provide one, along with any comments we want to make about the relying party. Then we hit the Next button, which takes us to the Choose Issuance Authorization Rules page.

Figure 7 - The Choose Issuance Authorization Rules page

In this case, we're going to deny all users access to the relying party for now. Later we can add some issuance authorization rules to enable access to the relying party. We hit the Next button to go on to the review page.

Figure 8 - Reviewing the relying party trust that was created from metadata.

Here we can review the Relying Party Trust that we are about to create. If we examine the various tabs on the page, we can see that the Identifier URLs, encryption and signature certificates, list of accepted claims, endpoints etc., have all been provided via the metadata.

Figure 9 - The encryption certificate provided by the federation metadata

Figure 10 - The list of accepted claims provided by federation metadata

After reviewing the configuration of the relying party trust, we hit the Next button to add it to the database. In figure 11, below we see the successfully created relying party trust.

Figure 11 - Showing the newly created relying party trust

Now I mentioned previously that federation metadata not only facilitates the creation of trusts, but also their maintenance. To show this in more detail, let’s open the properties dialog for the Contoso relying party.

Figure 12 - The properties page for the Contoso relying party trust

In figure 12 above we see the properties dialog, with the Monitoring tab displayed. This tab governs how AD FS manages the updating of this relying party trust. You can see that the Monitor relying party check box is checked. This indicates that AD FS will periodically check the Federation Metadata URL shown in the dialog and compare it with the current state of the relying party trust. You will also notice that the Automatically update relying party checkbox is checked. This tells AD FS to automatically update the relying party trust in responses to changes in the metadata. With this option enabled, we do not have to worry about certificates expiring or being replaced - any changes made to the partner will be reflected in the metadata and automatically moved into the database. The Monitoring tab also displays the date on which the metadata was last checked as well as the date upon which the last update was performed. Events are also logged when an update is performed.

Note that if the Automatically update relying party check box was unchecked, then the monitoring would still continue, but AD FS would not be updated. Instead those relying parties that are no longer in sync with their metadata would be indicated in the UI, as well as in the event log.

Figure 13 - Notification that a relying party trust needs to be updated.

If you refer to figure 13, you will notice that one of the actions available for the Contoso relying party is Update from Federation Metadata... This command allows the Administrator to force an update from metadata at will.

Federation Metadata is a powerful tool for managing AD FS 2.0. In future posts we will explore other aspects and techniques for using this data.

For more information about how to create trusts via federation metadata, see the following topics in the AD FS 2.0 Deployment Guide:

A Quick Walkthrough: Setting up AD FS SAML Federation with a Shibboleth SP

2010-06-21T17:57:00Z

Shibboleth is an open-source software project that provides SAML and WS-Federation protocol support, and is commonly found throughout the higher education market. Since it talks standard protocols, AD FS can be configured to grant access to resources protected by Shibboleth.

At the end of this blog post, you'll have a lab machine with an ASP.Net web page protected by Shibboleth and federating to your AD FS identity provider. We'll start from scratch and quickly build a functioning federation.

This is a great way to explore Shibboleth/AD FS interoperability in a test environment before making the corresponding changes on your live Shibboleth site.

Prerequisites

AD FS 2.0 installed and working at https://your-domain/adfs/ls/

For simplicity's sake, this post will install Shibboleth onto the same machine as AD FS. It also assumes the default AD FS identifier is used: https://your-domain.com/adfs/services/trust

Install Shibboleth

Visit the Shibboleth download site and install the 32-bit or 64-bit SP package as appropriate to your server. Restart your computer when prompted.

Configure Shibboleth

Edit c:\opt\shibboleth-sp\etc\shibboleth\shibboleth2.xml as follows (bold indicates text you'll need to change to reflect your environment):

Replace <Site id="1" name="sp.example.org"/> with <Site id="1" name="your-domain.com"/>
Replace <Host name="sp.example.org"> with <Host name="your-domain.com">
Enable request/response signing (necessary for single logout to work) by setting the signing attribute of the ApplicationDefaults element to true
Set the entityID attribute of the ApplicationDefaults to https://your-domain.com/shibboleth
Under the Sessions element, change the first SessionInititator example to refer to your AD FS instance by setting the entityID attribute to https://your-domain.com/adfs/services/trust
Tell Shibboleth where to find AD FS's metadata. Under the MetadataProvider element, add:

<MetadataProvider
type="XML"

uri="https://your-domain.com/FederationMetadata/2007-06/FederationMetadata.xml"

backingFilePath="federation-metadata.xml"

reloadInterval="7200"
/>

7. Restart IIS and the Shibboleth Windows service.

a. iisreset
b. net stop shibd_Default
c. net start shibd_Default

Configure AD FS

We'll use PowerShell to add the Shibboleth SP to AD FS. First, create a file in the current directory called "rules.txt" with the following content. This rule is authored in the AD FS claims policy language, and configures a SAML NameID to be emitted for the Shibboleth SP. If you are interested in configuring transient and persistent NameIDs, refer to our previous blog post on the subject.

@RuleTemplate="LdapClaims"

@RuleName="Send E-mail as Name ID"

c:[Type="http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
    Issuer == "AD AUTHORITY"]
=> issue(
    store = "Active Directory",
    types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"),
    query = ";mail;{0}",
    param = c.Value);

Next, run the following PowerShell commands:

Add-PSSnapIn Microsoft.Adfs.PowerShell
Add-ADFSRelyingPartyTrust -Name "Shibboleth SP" -MetadataUrl https://your-domain.com/Shibboleth.sso/Metadata
Set-ADFSRelyingPartyTrust -TargetIdentifier https://your-domain.com/shibboleth -IssuanceTransformRulesFiles rules.txt -SignatureAlgorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1 -IssuanceAuthorizationRules '=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true"); '

This will create an AD FS entry for the Shibboleth SP using its metadata. Additionally, it configures the user's e-mail address to be sent as their Name ID and specifies that Shibboleth will be using the SHA-1 hash algorithm for signing its requests.

Test Shibboleth

Visit https://your-domain.com/secure/. Shibboleth should redirect you to AD FS for authentication. Upon success, you'll see... a 404 page.

Create a default page at c:\inetpub\wwwroot\secure\default.aspx, with the following content:

<%@ Page Language="C#" %>

<html>

<head>

<title>Shibboleth Echo Page</title>

</head>

<body>

You are logged in using Shibboleth!

<hr />

<table>

foreach( string key in Request.ServerVariables )

{

if( key.StartsWith("HTTP_SHIB" ) )

{

<tr>

<td>

<%= key %>

</td>

<td>

<%= Request.ServerVariables[ key ] %>

</td>

</tr>

}

</table>

<hr />

<a href="http://blogs.msdn.com/Shibboleth.sso/Logout">Logout</a>

</body>

</html>

Hit refresh. You'll see the server variables that Shibboleth has populated based on your authentication, as well as a Logout link that you can use to test single logout. Congratulations, you have a working federation with Shibboleth!

Common Issues

Of course, in the real world, you'll want to send more than just a NameID. Read on for two common issues you may encounter, and how to work around them.

Attribute Name Format

Shibboleth expects SAML attribute names to have a format of urn:oasis:names:tc:SAML:2.0:attrname-format:uri. By default, AD FS issues attributes with a name format of urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified. If there's a mismatch, Shibboleth will ignore the attribute.

You can fix this on the Shibboleth side by editing the attribute-map.xml file. Rather than:

Specify the nameFormat attribute to be unspecified:

Alternately, you can fix this on the AD FS side by writing a custom claim rule to set the name format. Rather than one rule:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(
    store = "Active Directory",
    types = ("urn:oid:1.3.6.1.4.1.5923.1.1.1.6"),
    query = ";userPrincipalName;{0}",
    param = c.Value);

Write two rules, one to retrieve the claim from AD, the other to issue it with a modified NameFormat:

c:[
    Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
    Issuer == "AD AUTHORITY"]
=> add(
    store = "Active Directory",
    types = ("urn:oid:1.3.6.1.4.1.5923.1.1.1.6"),
    query = ";userPrincipalName;{0}",
    param = c.Value);

c:[
    Type == "urn:oid:1.3.6.1.4.1.5923.1.1.1.6"]
=> issue(
    Type = c.Type,
    Value = c.Value,
    Issuer = c.Issuer,
    Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri");

If you would like more information about the AD FS policy rules above, have a look at the following TechNet articles for details:

Scoped Attributes

Shibboleth supports "scoped attributes". These are attributes in the form of "user@scope". The Shibboleth SP will only process the attribute if the scope portion matches a scope defined in the IdP's metadata.

This is done via a custom Shibboleth extension element. For details, see the Shibboleth Metadata Profile.

Other Issues?

If you run into issues, you may wish to check Shibboleth's log files, located at

var\log\shibd.log
- This contains SAML-specific log messages.
var\log\native.log
- This contains IIS-specific log messages.

Still stumped? Check out the SP Troubleshooting document at the Internet2 site.

AD FS 2.0 Proxy Management

2010-06-02T18:12:20Z

Overview

Since the AD FS 2.0 release candidate (RC), the AD FS product team got feedback that the experience of setting up AD FS proxy server and making it work with AD FS Federation Service is cumbersome, as it involves multiple steps across both AD FS proxy and AD FS Federation Service machines.

In AD FS 2.0 RC, after IT admin installs AD FS 2 proxy server on proxy machine, she runs proxy configuration wizard (PCW) and needs to:

Select or generate a certificate as the identity of the AD FS 2 proxy server.
Add the certificate to AD FS Federation Service trusted proxy certificates list
Outside of AD FS management console, make sure the certificate’s CA is trusted by AD FS Federation Service machines.

Such above steps are needed to set up a level of trust between AD FS proxy server and AD FS Federation Service. The AD FS proxy server might live in DMZ and provides one layer of insulation from outside attack.

AD FS administrator need to keep track of the proxy identity certificate life time and proactively renew it to make sure it does not expire and disrupt its service.

There are several pain points around AD FS proxy setup and maintaining experience for AD FS 2 RC version:

Setting up proxy involves touching multiple machines (both proxy and Federation Service machines)
Maintaining AD FS proxy working state involves manual attention and steps

In RTW, above issues are addressed by:

Easy provisioning: AD FS admin set up proxy with AD FS Federation Service by specifying username/password of an account that is authorized by AD FS Federation Service to issue proxy trust token to identify AD FS proxy servers. The proxy trust token is a form of identity issued by the AD FS Federation Service to the AD FS proxy server to identify established trust. By default, domain accounts which are part of the Administrators group on the AD FS Federation Service machines or the AD FS Federation Service domain service account are granted such privilege to provision trust by proxy from AD FS Federation Service. Such privilege is expressed via access control policy and is configurable via powershell. By default proxy trust token is valid for 15 days.
Maintenance free: Over time, the AD FS proxy server periodically renews the proxy trust token from the AD FS Federation Service to maintain AD FS proxy server in a working state. By default AD FS proxy server tries to renew proxy trust token every 4 hours.
Revocation support: If for whatever reasons, established proxy trust needs to be revoked by AD FS Federation Service, AD FS Federation Service has both powershell and UI support to do that. All proxies are revoked at the same time. There is no support for individual proxy server revocation.
Repair support: When proxy trust expires or is revoked, AD FS administrator can repair such trust between AD FS proxy server and AD FS Federation Service by running PCW in UI mode or command line mode (fspconfigwizard.exe).

Management support

Several management aspects are involved in the new trust mechanism. Events are added to proxy server for:

AD FS proxy is set up correctly with AD FS Federation Service
AD FS proxy server has renewed trust with AD FS Federation Service
AD FS proxy failed to talk to Federation Service due to expired or invalid trust

Events are added to Federation Service server for:

AD FS proxy trust is established from a proxy machine
AD FS proxy trust is renewed from a proxy machine

Generic authorization event will be logged when:

Some party tries to establish or renew proxy trust using invalid credentials.

Proxy trust token issuance is audited just as any other issued token when AD FS audit is turned on. There are several knobs to turn to configure various proxy trust parameters:

AD FS proxy trust token lifetime
AD FS proxy trust renew frequency

Work flow

Provisioning

The following picture shows AD FS admin running PCW and setting up trust from proxy server to Federation Service.

The following screen shows that trust is established from proxy server to AD FS Federation Service.

From event log on proxy machine, you can see proxy server has successfully established trust with AD FS Federation Service.

On the Federation Service machine, you will see following related events.

(Note: There are two 395 events created corresponding to provisioning of one proxy machine. It is a side effect of PCW validating user name and password and establishing trust at the end of the wizard.)

Proxy server automatic trust renewal

Proxy server automatically renews trust with AD FS Federation Service. When that happens, you will see following event in event log on proxy machine.

Revocation

When a proxy server is compromised, the administrator of the AD FS Federation Service needs to revoke trust for all proxy machines. The following picture shows how AD FS admin could do it from UI. After proxy trusts are revoked, all proxy machines need to provision again to gain access to AD FS Federation Service.

Related powershell cmdlets

Several PowerShell cmdlets have been updated to provide PowerShell management of this new functionality:

On the proxy machine:

Get-ADFSProperties, Set-ADFSProperties: (ProxyTrustRenewPeriod) get or set how often proxy server renew proxy trust with AD FS Federation Service

On the Federation Service machine:

Get-ADFSProperties, Set-ADFSProperties: (AddProxyAuthorizationRules, ProxyTrustTokenLifeTime): as property names suggest.

Revoke-ADFSProxyTrust: revoke issued proxy trust. Proxy machines need to provision again to gain access to AD FS Federation Service.

Announcing the RTW of Federation Extensions for SharePoint 3.0 !!

2010-06-01T17:11:29Z

It is our pleasure to announce the general availability of Federation Extensions for SharePoint 3.0 package today. This package enables federation for existing SharePoint 3.0 deployments, both Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Services (MOSS) 2007. Using this package, enterprise SharePoint administrators can configure their deployments to trust any WS-Federation STS, such as AD FS 2.0, so that an enterprise can offer their services to federation partners.

The setup package of Federation Extensions for SharePoint 3.0 can be downloaded from here.

This package is available in the following 24 languages:

Arabic, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English, Finnish, French, German, Greek, Hebrew, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese (Brazil), Portuguese (Portugal), Russian, Spanish, Swedish, Turkish

Here are the additional resources that are helpful to you:

1. Product ReadMe for Federation Extensions for SharePoint 3.0 package

2. Step by Step Guide and VMs for Federated Document Collaboration Using MOSS 2007 and AD FS 2.0

3. AD FS 2.0 Getting Started Guide

4. AD FS 2.0 Design, Deployment, and Troubleshooting Guides

Windows Identity Foundation Whitepaper For Developers – by Keith Brown & Sesha Mani

6. A guide to claims-based identity – by Patterns & Practices Team

If you have questions, don’t hesitate to hop on the forum and ask.

See how easy it is to enable federation for your SharePoint 3.0 applications by deploying this package today!

WIF Product Team

Announcing the Windows Identity Foundation SDK 4.0 targeting Visual Studio 2010!

2010-05-11T15:03:00Z

It is our pleasure to announce the availability of Windows Identity Foundation SDK 4.0 package, which is tailored for .NET Framework 4.0 and Visual Studio 2010. We heard your feedback on the necessity for out of the box WIF templates that work with Visual Studio 2010 and samples that work with .NET Framework 4.0. This package addresses these two requests.

You can download the WIF SDK 4.0 setup package from here.

Note that this package is only available in US-English language. Localized versions of this package will be delivered later.

Here are the additional resources that are helpful to you:

WIF Whitepaper For Developers – by Keith Brown & Sesha Mani

2. New release of the Identity Developer Training Kit – by DPE Team

3. WIF Product Documentation on MSDN – by WIF User Assistance Team

4. A guide to claims-based identity – by Patterns & Practices Team

Enjoy coding with WIF!

WIF Team

Announcing the localization support for WIF SDK 3.5!

We are glad to announce the complete localization support for Windows Identity Foundation SDK 3.5 today. Following are the languages we have localized the SDK to:

1. French (fr-FR)

2. German (de-DE)

3. Japanese (ja-JP)

4. Spanish (es-ES)

5. Italian (it-IT)

6. Russian (ru-RU)

7. Chinese-Simplified (zh-CN)

8. Chinese-Traditional (zh-TW)

9. Korean (ko-KO)

You can obtain the localized WIF SDK setup packages from here.

Happy coding with WIF!!!

WIF Team

AD FS 2.0 is here!

2010-05-05T16:38:00Z

We are very happy to announce the general availability of AD FS 2.0! It is our pleasure to offer this release for Windows Server 2008 and 2008 R2 that makes it easier to work across companies, leverage the cloud, and develop secure applications all while using industry standard interoperable protocols. We listened to your feedback from the release candidate and have made AD FS 2.0 even easier to manage by simplifying proxy management. Finally, we’ve hammered this build to ensure you’ll see the rock solid reliability and screaming fast performance that you’d expect from Microsoft.

The setup package for AD FS 2.0 can be downloaded here.

The team behind making AD FS 2.0 can be seen in several Channel 9 videos discussing the features and capabilities of the release.

Check out the following resources to learn more about AD FS 2.0:

· Our official website

· AD FS 2.0 Getting Started Guide

· Step by Step Guide and VMs for Federated Document Collaboration Using MOSS 2007 and AD FS 2.0

· AD FS 2.0 Design, Deployment, and Troubleshooting Guides

· AD FS 2.0 developer documentation and PowerShell reference

· Resources for developing claims based applications with Windows Identity Foundation (WIF)

We’d like to give a big thank you to everyone who’s helped us by providing feedback since we had our first Beta. Stay tuned here as we will continue to blog about AD FS 2.0 features over the coming weeks and months. If you have questions, don’t hesitate to hop on the forum and ask.

See how you can use claims to unleash the power of your identity infrastructure by deploying AD FS 2.0 today!

The AD FS 2.0 Product Team

Update on Windows CardSpace

2010-04-27T15:55:00Z

We have decided to postpone the release of Windows CardSpace 2.0. This is due to a number of recent and exciting developments in technologies such as U-Prove and Open ID that can be used for Information Cards and other user-centric identity applications. We are postponing the release to get additional customer feedback and engage with the industry on these technologies. We will communicate additional details at a later time.

As part of our continued investment in these areas, we will deliver a Community Technology Preview in Q2 2010 that will enable the soon-to-be-released Active Directory Federation Services 2.0 (AD FS 2.0) in Windows Server to issue Information Cards.

Microsoft remains committed in the development of digital identity technologies, interoperable identity standards, the claims-based identity model, and Information Cards. AD FS 2.0 is on track for release shortly. We also continue to actively participate in industry groups such as the Information Card Foundation, the OpenID Foundation, and standards bodies such as OASIS.