|
|
Browse by Tags
All Tags » Indigo » HTTP » Security (RSS)
-
Security and streaming are two features that often do not get along with each other. Although the concepts are not inherently in conflict, their implementations often do things that cause problems for the optimal execution of the other. You may have seen that the message security channel, like the reliable messaging channel, in its native mode likes to buffer messages. This is because signing is one of the aspects of message security. The message signature is typically computed based on the contents of the message to allow detection of any changes. Although you could still achieve some benefit from streaming on the network and on the client, buffering of the message requires storage space on the server even though that storage space doesn't have to be in memory. Pre-computation of the message also negates one of the major benefits of streaming: the interleaving between computation and transmission of the data. A stream security mechanism, such as SSL, is one way to avoid this buffering problem. Stream to stream transformations tend to be less likely to assume complete knowledge of the data than message to message transformations. One popular combination to use streaming with message security is to secure transmission of the messages with stream security and to use message security only for passing credentials. HTTP authentication is another implementation that in some cases needs to buffer messages. HTTP defines a challenge and response for its basic authentication model. You might be able to predict the challenge and send the appropriate response as part of the request. If not, then the request needs to be transmitted from the beginning when the challenge response is supplied. In most cases it would be difficult to completely regenerate the request. Instead, the transmitted portion of the request is buffered so that it can be transmitted again. It is unpredictable how much of the request needs to be buffered since the challenge is asynchronous with respect to the response. This leads to many implementations that either do not work with streaming or only work when the HTTP server behaves nicely. The server may read as little or as much of the request as it likes before deciding to initiate the challenge. In practice though, the server most likely would like to issue the challenge sooner rather than later so that it can stop processing the request. Next time: Working with Session State Read More...
|
-
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...
|
-
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...
|
-
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...
|
-
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...
|
-
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...
|
-
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...
|
-
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...
|
-
This article covers some of the advanced topics that I left out of the earlier piece on configuring HTTP for Windows Vista . In addition to having gone over the basics article, it would also be helpful to have at least a little background knowledge about Windows security descriptors. The standard command for giving a user permission to make reservations in an HTTP namespace looks like netsh http add urlacl url=http://+:8000/ user=MYMACHINE\UserName All of these commands are going to assume that you're running as an account that has sufficient privilege to give away a piece of the HTTP reservation namespace (by default, such as the elevated Administrator account). Here are three additional options that I didn't talk about before. There are actually two separate permissions for using a registration (listen=yes/no) and for further delegating pieces of that namespace (delegate=yes/no). The ability to use a registration is GENERIC EXECUTE while the ability to delegate the namespace is GENERIC WRITE. The combination of these permission is represented by GENERIC ALL. A namespace ACL can represent either a positive permission (Allow ACE) or a negative permission (Deny ACE). Setting a negative permission explicitly denies someone the ability to make use of a reservation or perform delegation. You can create an ACL that both denies the ability to use a registration (listen=no) and denies the ability to delegate within that namespace (delegate=no). Most other uses of this command will result in a positive permission to do something. There's a new concept for a stable per-service SID in Windows based on the name of the service. This SID is the same across machines so you can actually use it in setup scripts. Using this feature allows you to ACL a namespace to a specific service even if that service has an account that is shared with lots of other services (such as NETWORK SERVICE). These service SIDs look like S-1-5-80 followed by a GUID and show up with a friendly name as NT SERVICE\MyServiceName. Additionally, netsh allows you to just use SDDL to describe your ACLs, although I'm not sure if you'll ever need to do that for WCF. Next time: Design Pattern for Building Channel Factories and Listeners Read More...
|
|
|
|