Govind's WebLog

Patterns and Practices: WCF Security Guidance available online

2008-04-01T23:00:00Z

The Microsoft Patterns and Practices team has created a guide for WCF security.

http://blogs.msdn.com/jmeier/archive/2008/03/27/patterns-and-practices-wcf-security-guidance-now-available.aspx

You can find more information at the root site

http://www.codeplex.com/WCFSecurity/

503 Server Unavailable failure with IIS 7.0

2007-08-30T21:22:00Z

When working with IIS 7.0 in Vista if you are seeing this failure trying to access the webserver, there are couple of things to look for.

1. Check if the Application Pool is running. You can click on the Application Pools option on the Left Pane of IIS 7.0 and check all running App pools.

2. You might have the URL http://+:80 reserved. Run netsh http show urlacl from a command window. If this shows an output similar to

     Reserved URL            : http://+:80/
        User: BUILTIN\IIS_IUSRS
            Listen: Yes
            Delegate: Yes
        User: BUILTIN\Administrators
            Listen: Yes
            Delegate: Yes
        User: NT AUTHORITY\NETWORK SERVICE
            Listen: Yes
            Delegate: Yes
            SDDL: D:(A;;GA;;;IS)(A;;GA;;;BA)(A;;GA;;;NS)

Then you have this port reserved which takes precedence over your http://localhost calls. Go ahead and remove this URL reservation by running the following command,

netsh http delete urlacl url=http://+:80/

Reliable Messaging and SecurityToken validation

2007-08-28T02:04:00Z

One of the things that have come up many times is how the service could stop a client from retrying a request for a valid security validation error while Reliable Messaging is enabled. If you are not familiar with the situation the essence of the problem is this,

Binding on the Service has Reliable Messaging (RM) enabled. You can do this using WsHttpBinding and setting the ReliableSession.Enabled property to true. What this would mean is that the client will re-try the request when the service responds with any random failure, after a session has been established. By random failure I mean failures that does not close the RM session while sending back the response. A fault sent back with proper RM headers to close the message would not result in a retry of the failed request. Unfortunately all SecurityToken validation and SecurityHeader validation exceptions are treated random exceptions as the response does not contain any required header or is the response secured.

One of the most common cases when this happens is when RM is enabled and a Username/Password validation fails. WCF provides extensibility points to plug in your Custom Username/Password validator, but any exception from the validator does not close the RM session and hence the client keep retrying the request until it finally times out. The post discusses a work around to close the RM session when such failures occur.

Write a Custom Username/Password Authenticator and plug this into the service using a Custom ServiceCredentials. The Custom Authenticator should add a specific failure claim to the AuthorizationContext. A sample code for the Custom Username/Password Authenticator is shown below.

class CustomUsernamePasswordAuthenticator : UserNameSecurityTokenAuthenticator

{

protected override ReadOnlyCollection<IAuthorizationPolicy> ValidateUserNamePasswordCore(string userName, string password)

{

Claim claim = null;

if (String.CompareOrdinal(userName, password) == 0)

{

claim = Claim.CreateNameClaim(userName);

}

else

{

claim = new Claim("http://contoso.com/InvalidUsernameClaim", true, Rights.PossessProperty);

}

List<IAuthorizationPolicy> policies = new List<IAuthorizationPolicy>();

List<ClaimSet> claimsets = new List<ClaimSet>();

claimsets.Add(new DefaultClaimSet(claim));

policies.Add(new ClaimFactoryPolicy(claimsets.AsReadOnly()));

return policies.AsReadOnly();

}

As you can see the above code is adding a specific claim of type http://contoso.com/InvalidUsernameClaim to the AuthorizationContext. For more information on how to plug custom authenticators in WCF you can take a look at http://msdn2.microsoft.com/en-us/library/ms730079.aspx.

The next we would do is to write a Custom Service Authorization Manager (SAM). The SAM gets called when the request has finally passed through all the binding elements so the RM header on the Request has been consumed. When an Access Denied result is returned by the SAM the failure response returned will be returned as Access Denied fault with the RM header enabled in the response that closes the RM session. Our Custom SAML will look for the specific Claim of type http://contoso.com/InvalidUsernameClaim to check whether to Authorize the user or not.

class CustomServiceAuthorizationManager : ServiceAuthorizationManager

{

public override bool CheckAccess(OperationContext operationContext)

{

ReadOnlyCollection<ClaimSet> claimsets = operationContext.ServiceSecurityContext.AuthorizationContext.ClaimSets;

foreach (ClaimSet claimSet in claimsets)

{

if (claimSet.ContainsClaim(new Claim("http://contoso.com/InvalidUsernameClaim", true, Rights.PossessProperty)))

{

return false;

}

return true;

}

Custom SAM can be plugged into the ServiceCredentials as shown below,

service.Authorization.ServiceAuthorizationManager = new CustomServiceAuthorizationManager();

The fault returned by the Custom SAM will stop the client from retrying when a token validation failure happens on the Service end.

Handling Mismatched Trust Versions on the Client

2007-08-22T00:47:00Z

Federation Clients might have scenarios where it is talking to a Service and STS that don't have the same trust version. The Service WSDL can contain a RequestSecurityTokenTemplate with Trust elements that are in different version than the STS. In these cases a WCF client will convert the Trust elements received from the Service's RequestSecurityTokenTemplate to match the STS Trust version. WCF will handle mismatched Trust version only for Standard Binding. All algorithm parameters that we recognize as standard are part of the Standard Binding. Below is our behavior under various Trust settings between the Service and the STS.

In the below description RP refers to "Relying Party" or the "Service" and STS refers to "Security Token Service".

RP Feb 2005 & STS Feb 2005

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

1. CanonicalizationAlgorithm
2. EncryptionAlgorithm
3. EncryptWith
4. SignWith
5. KeySize
6. KeyType

Client Config contains a list of parameters.

WCF cannot differentiate between client and service parameters. We just add all the parameters and send them over the RST.

RP Trust 1.3 & STS Trust 1.3

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

1. CanonicalizationAlgorithm
2. EncryptionAlgorithm
3. EncryptWith
4. SignWith
5. KeySize
6. KeyType
7. KeyWrapAlgorithm

Client config contains a "secondaryParamters" element that wraps the RP specified parameters.

WCF removes the EncryptionAlgorithm, CanonicalizationAlgorithm and KeyWrapAlgorithm from the top-level element under the RST if these are present inside the SecondaryParameters. We append the SecondaryParamters element as is to the outgoing RST.

RP Trust Feb 2005 & STS Trust 1.3

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

1. CanonicalizationAlgorithm
2. EncryptionAlgorithm
3. EncryptWith
4. SignWith
5. KeySize
6. KeyType

Client Config contains a list of parameters.

WCF cannot differentiate between the Service and Client parameters in this case from config on the client side. So we convert all the parameters to Trust 1.3 namespace.

Our handling of KeyType, KeySize and TokenType elements in this case is as follows,

We download WSDL and create the binding and assign KeyType, KeySize and TokenType from RP's parameters and the client config is generated.
Client can now change any parameter in the config.
During Runtime WCF will copy all parameters specified inside the AdditionalTokenParameters section of the client config except KeyType, KeySize and TokenType as they were accounted for during config generation.

RP Trust 1.3 & STS Trust Feb 2005

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

1. CanonicalizationAlgorithm
2. EncryptionAlgorithm
3. EncryptWith
4. SignWith
5. KeySize
6. KeyType
7. KeyWrapAlgorithm

Client config contains a "secondaryParamters" element that wraps the RP specified parameters.

WCF converts only EncryptionAlgorithm and CanonicalizationAlgorithm specified inside the "SecondaryParameters" and move them as top-level under the RST and replace the client specified values. The "SecondaryParameters" element is dropped from the AdditionalRequestParameters.

Security element and "actor" attribute.

2007-07-17T09:15:00Z

SOAP 1.1 defines the attribute "actor" that can be on any SOAP header which will indicate who the ultimate processor of the header is going to be. It also defines a standard URI value for this actor attribute that is "http://schemas.xmlsoap.org/soap/actor/next" which implies that the header is intended for the very first SOAP application that processes the message. The absence of the actor attribute would mean the same as well.

SOAP 1.2 renamed this attribute to "role". But the semantics remanis the same as SOAP 1.1.

WCF Security does not recognize this attribute. WCF will not emit this attribute in the Security header element in any messages it emits. If a received message contains a actor attribute in the Security header the header will not be recognized even if the value is set to http://schemas.xmlsoap.org/soap/actor/next. You will see an exception that says "No Security header present in the message.". To work around this do not emit this attribute in the Security header in your messages to WCF.

Updated Re-Serialize SAML token

2007-05-03T20:57:00Z

There has been a lot of interest around this and hence I have attached some code listing to this post. Check it out!

WSE VS addin fails to generate WSE proxy in 64-bit machine

2007-03-07T09:42:00Z

If you are using WSE and are a VS developer, you would be familar with the WSE Visual Studio Addin that automatically generates WSE Proxy when a Web Reference is added to the project. But if you are a developer in 64-bit machine you will not have this experience due to a bug in WSE setup. It fails to add the necessary entry in devenv.exe.config to enable this automatic generation of proxy. To work around this you can add the following XML to the devenv.exe.config which can be found at %Program Files(x86)%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe.config

<system.web>

</soapExtensionImporterTypes>

</webServices>

</system.web>

</configuration>

Save the config and restart VS. You will have the same experience as in x86 machines.

Using Visual Studio Intellisense to Edit WCF Configuration files.

2007-03-07T02:33:00Z

If you are using Visual Studio 2005 below is how you can enable intellisense to edit your WCF config files.

Copy the Attached WCF Configuration schema file to your VS installation folder at %Program Files%\Visual Studio 8\Xml\Schemas. You will find DotNetConfig.xsd in the same directory. Open this file in notepad and following right after the xs:schema element add the below line,

<xs:include schemaLocation="WCFConfig.xsd" />

You will now have intellisense support for your WCF configuration files in VS!

Trouble Installing .NET 2.0....

2007-02-25T00:13:00Z

If you had a Beta version of Framework 2.0 installed on your machine and are moving to a the RTM version, then you might have some trouble with getting the correct version of mscoree.dll in place. The reason is Microsoft Installer's resilence feature will restore the old version of mscoree.dll in your system directory even if you delete it. To fix this follow the belwo support article from Microsoft.

http://support.microsoft.com/kb/908077

Daylight savings changes and WCF Security Processing

2007-02-21T07:26:00Z

I had a question today from a customer who was concerned that his WCF application might start to behave erratically due to the new Daylight savings schedule. Then I realized that there has been quite some noise around this area and people are predicting systems to stop responding when the new Daylight savings goes into effect. It reminded me of the Y2K days which was hyped as the doomsday of the Millennium.

In actual fact you don't have to worry about anything. WCF security has been tested for daylight savings time changes and the fact that the change happens earlier is not of concern. To be specific, WCF is using UTC time in all its code that the local time really doesn't affect us. As long as you have the Windows patch to adjust your clock at the correct time you should be fine. So, Enjoy! Keep coding with WCF!