Q: What is the difference between ActAs and OnBehalfOf?

From a WS-Trust procotol standpoint, an ActAs RST element indicates that the requestor wants a token that contains claims about two distinct entities: the requestor, and an external entity represented by the token in the ActAs element. An OnBehalfOf RST element indicates that the requestor wants a token that contains claims only about one entity: the external entity represented by the token in the OnBehalfOf element.

ActAs is typically used in scenarios that require composite delegation, where the final recipient of the issued token can inspect the entire delegation chain to perform access control, auditing and other related activities. The ActAs feature is commonly used in multi-tiered systems to authenticate and pass information about identities between the tiers without having to pass this information at the application layer.

OnBehalfOf is typically used in scenarios where only the identity of the original client is important and is effectively the same as identity impersonation in Windows. When OnBehalfOf is used, the final recipient of the issued token can only see claims about the original client, and the information about intermediaries is not preserved. OnBehalfOf is often used in the proxy pattern where the client cannot access the STS directly but is instead communicating through a proxy gateway. The proxy gateway authenticates the caller and puts the caller’s information into the OnBehalfOf element of the RST message that it sends to the STS for processing. The resulting token contains only claims related to the client of the proxy, making the proxy completely transparent and not visible to the receiver of the issued token.

Note that WIF does not support <wsse:SecurityTokenReference> or <wsa:EndpointReferences> as a child of <wst:OnBehalfOf>. The WS-Trust specification allows for three ways to identity the original requestor (on behalf of whom the proxy is acting). These are:

1. Security token reference. A reference to a token, either in the message, or possibly retrieved out of band).
   
   
2. Endpoint reference. Used as a key to look up data, again out of band.
   
   
3. Security token. Identifies the original requestor directly.
   
   

WIF supports only security tokens, either encrypted or unencrypted, as a direct child element of <wst:OnBehalfOf>.

Q: Why do I get a 400 Bad Request - Request Too Large error when using Cardspace or WS-Fed?

A: Please see http.sys Registry Settings for IIS. This article describes IIS settings. The two settings of interest are:

• MaxFieldLength: Sets an upper limit for each header. This limit translates to approximately 32k characters for a URL.
  
  
• MaxRequestBytes: Determines the upper limit for the total size of the Request line and the headers. Its default setting is 16KB. If this value is lower than MaxFieldLength, the MaxFieldLength value is adjusted.
  
  

Q: When is the claims authentication manager invoked?

A: The claims authentication manager is typically invoked once per session, with the following exceptions:

• For transport security, tokens present at the transport layer will invoke the claims authentication once per call, even if sessions are present.
  
  
• If there is more than one token at the message security layer, each token will invoke the claims authentication manager separately. For example, two tokens in the security header will invoke the claims authentication manager twice per session.
  
  
• The claims authentication manager is not invoked when no tokens are present: that is, for all the AnonymousForxxx authentication modes. Here, the recommendation is to use the claims authorization manager as a gatekeeper.
  
  

Note:
It is recommended that you do not call Thread.CurrentPrincipal in the claims authentication manager or claims authorization manager. Rather, you should use the incomingPrincipal parameter on the Authenticate method:

	Copy Code
class CustomClaimsAuthenticationManager : ClaimsAuthenticationManager { public override IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal incomingPrincipal) { return base.Authenticate(resourceName, incomingPrincipal); } }

Q: How does WIF handle duplicate RSTs and duplicate elements within RSTs?

A: If an RST is duplicated, only the first RST is parsed; all other RSTs are ignored. If an RST contains duplicate elements, only the last element's value is used; all other element values are ignored.

Q: What is a deny-only Security Identifier (SID)?

A: For more information, see SID Attributes in an Access Token

Q: How does a relying party application validate the trust relation with an issuer?

A: WIF has the concept of an IssuerNameRegistry which is an extensibility point for validating the trust relationship with an issuer. There are two ways this extensibility point can be used:

1. ConfigurationBasedIssuerNameRegistry, where you configure the signing certificate of the issuer in the relying party application’s configuration file.
   
   
2. A custom IssuerNameRegistry that can be derived from the IssuerNameRegistry class exposed in WIF. Refer to Samples\End-to-end\Authentication Assurance\AuthAssuranceRP\App_Code\TrustedIssuerNameRegistry.cs file for a sample implementation of custom IssuerNameRegistry.
   
   

Q: Under what registry key is WIF installed?

A: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsIdentityFoundation\setup\v3.5\.

Q: Can an STS instance be used for Issue calls across multiple token requests?

A: The WIF STS instancing model is per-call. This means that an STS instance is intended only for a single use: that is, you create a new instance of an STS, make the necessary method calls (such as Issue), and then clear that STS instance. If you try to use the same STS instance to call Issue across multiple token requests, rather than creating a new STS instance for each token request, the behavior is undefined.