Browse by Tags

• Answers
• Bindings
• Channel Extensibility
• Channels
• Hosting
• Indigo
• Security
• Standard Bindings
• Transports

• Configuring SSL Host Headers

  Host headers in IIS are a way to associate multiple names with a single address. The typical use of host headers is to be able to host more than one web site at a single IP address by giving each of the web sites a distinct DNS name. Host headers also play a role in WCF beyond the definition of a web site. Metadata for a web service, such as that appearing WSDL, uses host headers as a way to pick a preferred name when talking about the service. The user interface for setting host headers is relatively straightforward when the web site is hosted over HTTP but becomes a challenge when the web site is hosted over HTTPS. Here are the command line equivalents that you can use to set HTTPS host headers. On IIS 6, you need to know the id of the web site. Assuming that SSL is taking place on the default port, the command looks like this. cscript.exe adsutil.vbs set w3svc/<id>/SecureBindings ":443:<header>" On IIS 7, the command line looks very different due to the more flexible but complicated support for different web site bindings. You can also use a name that's meaningful for you to distinguish web sites. appcmd set site /site.name:<name> /+bindings.[protocol='https',bindingInformation='*:443:<header>'] To keep the example simple, I'm assuming that you're adding a new binding rather than modifying an existing binding. Next time: Transaction Header Magic Read More... Posted Wednesday, July 09, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Transport Security, HTTP, Security, Hosting

• Custom Password Validation for HTTP

  Phil Henning has written about creating a custom username/password validator for HTTP , which is another new feature in Orcas. Like getting access to client IP addresses , creating a custom password validator is a feature added as a result of direct customer feedback. In fact, the two features were added during the same week and were among the last features we did in Orcas for messaging. Before Orcas you could only create a custom password validator if you were using message security. Read More... Posted Monday, January 14, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Transport Security, HTTP, Security

• Mapping Credentials to Authentication Schemes

  You may have noticed that an HTTP binding is configured with an HttpClientCredentialType whereas an HTTP binding element is configured with an AuthenticationScheme. How are these two settings related? If you want to switch between a custom binding and a standard binding for HTTP, then you need to know how to do the translation. Here's how client credentials map to authentication schemes: HttpClientCredentialType.None becomes AuthenticationSchemes.Anonymous HttpClientCredentialType.Certificate also becomes AuthenticationSchemes.Anonymous. Certificates are used with HTTPS rather than as authentication credentials on top of HTTP. This will be caught in validation if you try to use certificates with the TransportCredentialOnly security mode. HttpClientCredentialType.Basic becomes AuthenticationSchemes.Basic HttpClientCredentialType.Digest becomes AuthenticationSchemes.Digest HttpClientCredentialType.Ntlm becomes AuthenticationSchemes.Ntlm HttpClientCredentialType.Windows becomes AuthenticationSchemes.Negotiate Translation works the same way with proxy credentials and the proxy authentication scheme except that proxies don't have to worry about the issue with certificates. Next time: Get a Real XML Parser Read More... Posted Monday, December 31, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 1 Comments Filed under: Indigo, Bindings, Transports, Transport Security, HTTP, Security, Standard Bindings

• Configuring SSL Certificates for Windows Vista

  The documentation for configuring a port with an SSL certificate shows example commands using the httpcfg.exe program. Starting with Windows Vista, httpcfg.exe was replaced in function by the netsh program that comes with the operating system. This is more convenient than having to download a separate tool, but it means that the syntax that you need to use changes slightly. Let's assume that you've created a certificate and have already installed it using either the command line or the MMC certificate snap-in. Now, through the MMC snap-in, get the thumbprint of the certificate you want to install to a port if you don't already know what the thumbprint is. This process hasn't changed much so your existing directions should continue to work. The thumbprint for the test certificate I generated was 45d08a92798460d84e4ce157f31662b36c4edbff. When you copy the thumbprint from the snap-in, don't forget to remove all of the spaces. You'll need to run netsh from an elevated command prompt. This first command installs my generated test certificate to port 8000 for the wildcard IP address. netsh http add sslcert ipport=0.0.0.0:8000 certhash=45d08a92798460d84e4ce157f31662b36c4edbff appid={00112233-4455-6677-8899-AABBCCDDEEFF} The only new thing here is the appid, which is a guid that can be used to associate the certificate with a particular application. You can check the installed certificates with the following command. netsh http show sslcert That gives me the following certificate description. SSL Certificate bindings: ------------------------- IP:port : 0.0.0.0:8000 Certificate Hash : 45d08a92798460d84e4ce157f31662b36c4edbff Application ID : {00112233-4455-6677-8899-aabbccddeeff} Certificate Store Name : (null) Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled Finally, you can remove the certificate associated with a particular address to undo the earlier changes. netsh http delete sslcert ipport=0.0.0.0:8000 Next time: Shutting Down a Channel Read More... Posted Monday, October 15, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Transport Security, HTTP, Security

• Preventing Anonymous Access

  How do I prevent clients from accessing my service anonymously? I've changed the settings in IIS from Anonymous Access to Integrated Windows Authentication. However, now I'm getting the error message: "Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service." Disabling anonymous access requires coordinating the settings in IIS and in your service configuration. Those two sources must be in agreement about whether anonymous access is expected. IIS is already using Windows authentication in this case, so let's look at what needs to happen to the service configuration file. I'm assuming that this is IIS6 so the only network transport we're talking about here is HTTP. There are two cases depending on whether you want the protocol that gets exposed to be HTTP or HTTPS. The simplest is to keep using HTTP since that's probably what you were using if anonymous access was allowed in the past. To switch off anonymous access with HTTP, you need to set the security mode to TransportCredentialOnly. < basicHttpBinding > < binding > < security mode ="TransportCredentialOnly" > < transport clientCredentialType ="Windows" /> </ security > </ binding > </ basicHttpBinding > Note that TransportCredentialOnly is not supported for every binding (in this case we're using BasicHttp). For WSHttp, the only choice is going to be to use HTTPS. To switch off anonymous access with HTTPS, you need to set the security mode to Transport. < wsHttpBinding > < binding > < security mode ="Transport" > < transport clientCredentialType ="Windows" /> </ security > </ binding > </ wsHttpBinding > Other bindings can be made to work in this situation as well, including custom bindings. I'm just showing you the most common examples. The key in both cases though is that we're getting transport security with the right kind of credentials associated. Next time: Writing Binding Element Essentials Read More... Posted Friday, March 23, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Bindings, Transport Security, HTTP, Answers, Security, Hosting, Standard Bindings

• Faking Channel Security

  I occasionally see people asking how they can fake the security capabilities of a binding. These questions often start off with "I'm getting an error message that a message's required protection level is not being met". Now, I'm not precisely sure why you'd want to fake the security capabilities in this case. After all, the application developer is in charge of both specifying the protection requirements of the messages and choosing what channels to use. If they're getting this error message, then it more than likely means that this helpful check has detected a problem somewhere in their design. There are a few rare reasons why you'd want to fake this, but they mainly involve transmitting over specially secured networks. However, it turns out that faking security capabilities is exactly the same as legitimately specifying the capabilities of a custom channel so I might as well explain that! Security capabilities are found by querying the channel stack with GetProperty for an instance of ISecurityCapabilities. This call should be supported on the binding element of channels that implement message or transport security. Transport channels should respond with something, even if it is to say that they don't support any kind of security. Everyone else can just delegate the call to their inner channel (which is typically what you do by default for any type you don't know about). public interface ISecurityCapabilities { ProtectionLevel SupportedRequestProtectionLevel { get; } ProtectionLevel SupportedResponseProtectionLevel { get; } bool SupportsClientAuthentication { get; } bool SupportsClientWindowsIdentity { get; } bool SupportsServerAuthentication { get; } } The fields here should be self-explanatory, you either support a particular feature or you don't, but let's look at examples from some of the existing channels. HTTP doesn't support any protection on requests and responses, neither encryption nor signing. HTTP supports client authentication when in any security mode but Anonymous. It only supports server authentication when using Negotiate security. Windows identities are supported whenever client authentication is. On the other hand, HTTPS provides both encryption and signing for both requests and responses. HTTPS always does server authentication. It supports client authentication and Windows identities whenever HTTP would plus whenever client certificates are turned on. You can quickly get a sense of the differences between HTTP and HTTPS by looking at Read More... Posted Wednesday, January 17, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Transports, Channels, Transport Security, HTTP, Answers, Channel Extensibility, Security

• Dealing with SSL Certificate Validation Failures

  Here's a quick list of things to try when debugging a non-functioning SSL server certificate. Has the certificate expired or been revoked? Does the MMC Certificate Manager say that the certificate is valid? Is the certificate in the LocalMachine store? Have you registered the certificate to the address and port of your service? Does the registered thumbprint match the SHA1 thumbprint of the certificate? Does the certificate address match the address in your service URI? Is the root certificate valid and in the trusted root store? Is the certificate revocation server reachable and functioning? Next time: When to Wait for Messages Read More... Posted Tuesday, November 07, 2006 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Transport Security, HTTP, Answers, Security