This section discusses security and privacy considerations.

• Privacy Considerations
  
  
• STS Security Considerations
  
  
• RP Security Considerations
  
  
• WS-FAM Security Considerations
  
  

RP security considerations include the following:

• Availability of Bootstrap Tokens
  
  
• Cross-Site Request Forgery
  
  
• ProofEncryption
  
  
• RP Applications Must Verify Token Issuer
  
  
• Transforms Replacing the ProtectedDataCookieTransform Must Provide Encryption
  
  
• Use Bootstrap Tokens When Using ActAs with Username Token
  
  
• Wctx Parameter Should Not Contain Sensitive Information
  
  
• WindowsClaimsIdentity.CertificateLogon Does Not Require Certificate to be Issued by a Root Trusted by Active Directory
  
  

WS-FAM security considerations include the following:

• Native Resources and Static Files Not Protected by WS-FAM by Default
  
  
• User Can Be Signed Out of RP by Malicious Web Site
  
  

Developers who create applications that use Windows® Identity Foundation (WIF) should create their own application-specific privacy statements, as the WIF privacy statement does not cover these applications. The WIF privacy statement can be found at Windows Vista Privacy Statement and Windows 7 Privacy Statement

A security token service (STS) should take the following security precautions:

• Validate the address and identity of the value in the AppliesTo property of the incoming RequestSecurityToken.
  
  
• Encrypt SAML token proof keys for the intended RP when issuing tokens. The RP should reject tokens whose proof keys it cannot decrypt.
  
  
• Encrypt symmetric proof keys. This is the default setting for WIF, and can be set in EncryptingCredentials.
  
  
• Consider collaboration threats, such as two malicious or compromised RPs colluding to track a user or assemble a user’s private information.
  
  
• Prefer combined entropy for symmetric keys.
  
  
• Sign issued tokens. By default, an STS built with WIF signs issued tokens using SHA-256.
  
  
• Treat the values in the incoming RequestSecurityToken as untrusted input. For example, if a value is used as a database lookup key in GetOutputClaimsIdentity, the value could be used in a SQL injection attack. A malicious user could do this by modifying the query string’s wrealm parameter that is sent to an ASP.NET STS.
  
  
• Maintain a cache of Information Cards that it issues. This way, when it receives a request to issue a token, it can verify that the request contains a reference to a known and current Information Card. If the reference is to an unknown Information Card, or to an Information Card that has expired, the STS can handle the request accordingly.
  
  
• Handle exceptions in a secure way. An exception might contain small pieces of code, stack traces, and file paths that could be useful to attackers. One mitigation strategy is to write the exception data to a database and simply report an internal server error, including the ID of the database record (without identifying it as such).
  
  
• Well known domain name suffixes such as “com”, “net”, “org”, and so on, should not be used as host names for the STS if they are being used in an intranet. This might open up the RP to phishing attacks through the wreply parameter of the WS-Trust SignOutCleanupRequest message. For example, “fabrikam.com” will be considered as a valid subnet of the issuer "com", and will pass through the wreply validation filter on the RP. The client could then be redirected to a malicious site at this URL when the RP actions the wreply parameter. The likelihood of such an attack is low because the request must come from a machine that is already on the same intranet, but you should still follow this guideline to mitigate the risk.
  
  

A relying party (RP) application should take the following security precautions:

• Validate the addresses in the audience restriction of the incoming security token to make sure that the token is targeted at the relying party. WIF does this by default for tokens that do not contain a proof-of-possession key.
  
  
• Validate the token issuer.
  
  
• Verify that the issuer is trusted to issue the claims in the token.
  
  
• Treat the claims in the token as untrusted input.
  
  

Relying party applications should verify the token issuer before using tokens and the claims in them. For tokens signed using an X509 certificate, the issuer can be verified in multiple ways, such as peer or chain trust. Tokens issued through personal cards are signed using a self issued RSA key, which is typically accepted as is. The application's policy configurations need to verify that issuers are trusted to make the claims contained in the tokens they issue. By default, WIF requires issued tokens to be signed, and verifies the issuer's signature.

A bootstrap token is the original token used to authenticate the client. In previous versions of WIF, there was no consistent way for the RP application to access this token. Once the claims were extracted, this token was destroyed.

In the current version, the bootstrap token is preserved and is made available through ClaimsPrincipal and can be accessed using the BootstrapToken property. This is helpful for applications that need to implement the ActAs scenario.

In ASP.NET or WCF, you can access the bootstrap token as follows:

	Copy Code
// Get the Bootstrap Token SecurityToken bootstrapToken = null; IClaimsPrincipal claimsPrincipal = Thread.CurrentPrincipal as IClaimsPrincipal; if ( claimsPrincipal != null ) { IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity; bootstrapToken = claimsIdentity.BootstrapToken; }

ProofEncryption is used to communicate information about how to encrypt the requested proof token and how to encrypt the entropy in the Request for Security Token Response (RSTR). It is intended for cases in which the transport or message is not using a security feature If it is used when the transport or message is using a type of security, it can create double encryption of the token and the entropy; that is, one time at the token and entropy level and again at the message and transport level. Windows Communication Foundation (WCF), for example, allows you to choose a type security for the channel communication between the client and the STS. therefore, in this case, ProofEncryption can safely be set to null.

When using ActAs with a username token, you must be careful not to leak the client’s password. WCF exposes the UserNameSecurityToken object in the OperationContext.Current.IncomingMessageProperties.Security.IncomingSupportingTokens property when secure conversation is disabled. If this token is used directly with either the WSTrustChannel or FederatedClientCredentials, the client's password will be written out to the wire.

To prevent this, clients should always use the bootstrap tokens from BootstrapToken. WIF nulls out the password when saving the bootstrap tokens.

A specification-compliant STS is required to preserve the value of the wctx parameter and return it to the RP upon redirection. An RP uses this parameter to preserve state after it redirects a client to the STS. The RP must protect this information itself, as WIF will send the wctx parameter out in cleartext. An STS might also inadvertently expose the information in this parameter through message logs.

WIF, by default, offers ProtectedDataCookieTransform that provides encryption for session tokens. If you choose to replace it with a custom transform, make sure that the custom transform provides encryption capability.

WIF uses cookies when authenticating a client to a Web site in order to maintain an authenticated session. Cookies might exist both for the STS domain (for single sign-on across multiple websites), or for the relying party domain (for single sign-on within the pages of a federated application). This use of cookies presents a risk of cross site request forgery, in which the cookies are used to authenticate and perform some action when the user visits a third-party Web page with malicious content. Developers of both STSes and RPs should be aware of this risk and implement the appropriate mitigations.

In operating systems prior to Windows Vista and Windows Server 2008, CertificateLogon creates a Windows identity based solely on the SubjectAltName in the certificate. It does not require the certificate to be issued by a root that is trusted by Active Directory. This makes it possible to impersonate any domain user by using a certificate that chains up to a root that is trusted by the local machine, but not by Active Directory.

CertificateLogon is also called by the Claims to Windows Token Service (c2WTS), so the same issue arises if a relying party application is running on an operating system prior to Windows Vista and Windows Server 2008 and it calls CertificateLogon and passes in a certificate from the client.

The SignOut and SignOutCleanup messages defined in the WS-Federation specification do not enforce authentication. This makes it possible for a malicious Web site (RP) to sign the user out of an STS by redirecting the users to the STS with a SignOut message. One possible mitigation is to have the STS ignore the WS-Federation SignOut/SignOutCleanup message and instead serve the user a page that gives the user the option to sign out.

For an RP that uses the WS-FAM, even though the SignOutCleanup message is not authenticated, it is possible for a malicious Web site to create a link that sends a SignOutCleanup message from an authenticated user to the RP. The WS-FAM OnSigningOut event is invoked before the user is actually signed out, and it is possible to block the action or take some other action at this point. WIF does perform validation on the wreply parameter of the message in order to block any phishing attacks that would redirect the user to a fake site after signing out from the RP. The user is redirected to wreply only if the URL is in the same domain as the issuer. If it is not, then the user is simply redirected back to the issuer.

Native resources and static files, such as those with extensions .TXT, .GIF, .HTML, and .XML, will be returned by IIS without invoking ASP.NET by default, so they will not be protected by WIF. By default, FedUtil and the Visual Studio project templates offered by ASP.NET add the Federated Authentication Module to the application’s app.config or web.config file in a way that enables only the protection of managed resources. This is by design. To enable protection of native resources, remove the preCondition = “managedHandler” attributes from the <system.webServer>/<modules> elements that add WSFederationAuthenticationModule and SessionAuthenticationModule.

Note that while you are debugging your Web-hosted applications using Visual Studio’s built-in Web server, the preCondition="managedHandler" attribute is ignored and both managed and native resources are protected. However, when you access the Web application through IIS, the precondition attribute is honored and hence only managed resources are protected by the WS-FAM.