https://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

https://www.codeplex.com/WCFSecurity/

 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 https://+:80 reserved. Run netsh http show urlacl from a command window. If this shows an output similar to

     Reserved URL            : https://+: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 https://localhost calls. Go ahead and remove this URL reservation by running the following command,

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

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("https://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 https://contoso.com/InvalidUsernameClaim to the AuthorizationContext. For more information on how to plug custom authenticators in WCF you can take a look at https://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 https://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("https://contoso.com/InvalidUsernameClaim", true, Rights.PossessProperty)))

                    {

                        return false;

                    }

                }

                return true;

            }

        }

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

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

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.

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 https://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.

<configuration>

  <system.web>

    <webServices>

      <soapExtensionImporterTypes>

        <add type="Microsoft.Web.Services3.Description.WseExtensionImporter, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      </soapExtensionImporterTypes>

    </webServices>

  </system.web>

</configuration>

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

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!

WCFConfig.xsd

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

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!