Compartilhar via


Windows Identity Foundation SDK

[Starting with the .NET Framework 4.5, Windows Identity Foundation (WIF) has been fully integrated into the .NET Framework. The version of WIF addressed by this topic, WIF 3.5, is deprecated and should only be used when developing against the .NET Framework 3.5 SP1 or the .NET Framework 4. For more information about WIF in the .NET Framework 4.5, also known as WIF 4.5, see the Windows Identity Foundation documentation in the .NET Framework 4.5 Development Guide.]

The Windows Identity Foundation (WIF) Software Development Kit (SDK) should be used with the following considerations.

WIF SDK Considerations

Note

If you are looking for information on the SharePoint extensions, see Microsoft Federation Extensions for SharePoint 3.0

Please note the following considerations as you prepare to use the WIF SDK.

Side by Side Installation

If you try to install the WIF SDK on a computer that has both .NET Framework 3.5 and 4 installed, you may run into the following situation:

  1. On Windows Server 2003, if the WIF SDK for .NET Framework 3.5 is installed, the samples involving ASP.Net may fail with a RequestValidation error.

    This is because IIS will default the framework version to .NET Framework 4 when .NET Framework 4 is installed.

  2. On Vista/Windows Server 2008/Windows 7/Windows Server 2008 R2, if both the WIF SDK for .NET Framework 3.5 and WIF SDK for .NET Framework 4 are installed, and SamplePreReqSetup.bat from both SDK are run, then only the samples from the last-installed SDK will work.

    This is because SamplePreReqSetup.bat creates an application pool, WifSample, for use with the samples, and the SamplePreReqSetup for the different SDKs set different framework versions on the application pool. For example, SamplePreRequSetup.bat from the .NET Framework 3.5 SDK sets the framework version to 2.0, while the SamplePreReqSetup.bat from the .NET Framework 4 SDK sets the framework version to 4. Since the application pool name is the same for both SDKs, whichever SamplePreReqSetup.bat that is run last prevails in setting the framework version for the WifSample application pool.

    If customers decide to try both samples on the same computer, they need to re-run SamplePreReqSetup.bat for whichever sample set they want to run.

  3. On Vista/Windows Server 2008/Windows 7/Windows Server 2008 R2, if both WIF SDK for .NET Framework 3.5 and WIF SDK for .NET Framework 4 are installed, and customers are trying to run the same sample from WIF SDK for .NET Framework 3.5 and WIF SDK for .NET Framework 4 for comparison, running setup.bat may fail for the second sample.

    This is because the samples are identical in both SDKs; therefore, the vdir/application names that are used are identical as well. Therefore, if you want to run a sample in both SDKs, running setup.bat for the first sample will work normally, but you will need to run cleanup.bat for the first sample before moving on the second sample to remove the vdir/application. If this step is skipped, when you are running setup.bat for the second sample, setup.bat will fail with the following error: ERROR ( message:Failed to add duplicate collection element "/CustomerUserNameCardStsHostFactory". )

Note

This does not happen on Windows Server 2003; instead, a prompt is displayed allowing you to choose to remap the VDIR.

WIF Samples Updates

The following are updates to the samples collection for WIF:

  • Using Managed STS – There are currently no updates for this sample.

WIF and WS-* Standards

WIF implements several WS-* standards. Accordingly, classes in many of the WIF namespaces either wrap SOAP message XML elements defined by one of the WS-* standards or provide constants for URIs, element names, attribute names, and other artifacts defined by them. The following table provides a list of the relevant WS-* standards for each namespace and a link to the specification for each standard. You can refer to these specifications for more detailed information about the XML elements and other artifacts represented by relevant classes in each namespace. This list provides links to only the most relevant specifications; it is not meant to be exhaustive.

Namespace Standards Specifications

Microsoft.IdentityModel

WS-Addressing 2004

WS-Addressing 1.1

WS-SecureConversation 1.3

WS-Security 1.0

WS-Security 1.1

Web Services Addressing (WS-Addressing), W3C Member Submission, 10 August 2004

Web Services Addressing 1.0 - Core, W3C Recommendation, 9 May 2006

WS-SecureConversation 1.3

WS-Security 1.0

WS-Security 1.1

Microsoft.IdentityModel.Protocols.WSFederation

WS-Federation

Web Services Federation Language (WS-Federation) Version 1.2

Microsoft.IdentityModel.Protocols.WSFederation.Metadata

WS-Federation

Web Services Federation Language (WS-Federation) Version 1.2

Microsoft.IdentityModel.Protocols.WSTrust

WS-Trust Feb 2005

WS-Trust 1.3

WS-Trust 1.4

WS-Trust Feb 2005

WS-Trust 1.3

WS-Trust 1.4

Microsoft.IdentityModel.Protocols.XmlEncryption

XML Encryption

XML Encryption Syntax and Processing, W3C Recommendation, 10 December 2002

Microsoft.IdentityModel.Protocols.XmlSignature

XML Signature

XML Signature Syntax and Processing (Second Edition), W3C Recommendation, 10 June 2008

Microsoft.IdentityModel.SecurityTokenService

WS-Trust Feb 2005

WS-Trust 1.3

WS-Trust 1.4

WS-Trust Feb 2005

WS-Trust 1.3

WS-Trust 1.4

Microsoft.IdentityModel.Tokens.Saml11

SAML V1.1 Core

Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V1.1 on the SAML specifications website

Microsoft.IdentityModel.Tokens.Saml2

SAML V2.0 Core

SAML V2.0 Profiles

SAML V2.0 Authentication Context

Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 on the SAML specifications website

Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 on the SAML specifications website

Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0 on the SAML specifications website