Vista is coming soon, and one of its new security features bears special mention due to its effect on the execution of Http-based services. User Account Control is a new feature that will have many former administrators running as a “standard user” by default. Running as a non-admin, developers can hit a permissions issue when opening an Http standalone service:

AddressAccessDeniedException: HTTP could not register URL http://+:80/myService/. Your process does not have access rights to this namespace (see http://go.microsoft.com/fwlink/?LinkId=70353 for details).

That is because http.sys restricts the root namespace (i.e. “/”) to administrators only. By using the http.sys namespace security mechanism, you can delegate portions of the global namespace to be accessible by different groups (i.e. all local Users, Power Users, a single user such as REDMONDkennyw, etc). Traditionally this security integration would be done by your setup program at install time.

System.Net does not currently expose any managed APIs to manipulate http.sys security reservations, but Keith has posted some sample code on using these APIs from managed code.

In addition, on Vista administrators also have access to a brand new netsh extension. This extension is very useful for both diagnostics and configuration issues such as namespace delegation. It also takes care of simple SDDL conversion, so you can now have commands such as:

netsh http add urlacl url=http://+:80/myService user=DOMAINuser

Rather than having to use oh so readable SSID strings like D:(A;;GX;;;S-1-5-20).

Note that your code which is running either the netsh extension or the configuration APIs needs to be running under an administrator account in order to setup this reservation. Once the reservation (ACL delegation) has been made, future registrations (usages) of your URI can occur while running under any account that was authorized by the reservation.

End to end (E2E) tracing is a very useful tool for tracking down bugs that occur in a distributed system (such as Indigo). You can learn more about it from a new Channel 9 video on WCF tracing that features Laurence from the Tracing product team.

This question came up a few times while I was away for my honeymoon: “If I am using BasicHttpBinding or WsHttpBinding, how do I setup the credentials for my proxy?”

In my earlier post on HTTP proxies I noted that all of our transport security implementations (including HTTP proxy authentication) leverage the shared WCF-wide credential provisioning framework. As a result, it’s pretty straightforward to configure your proxy credentials. I think what trips people up is that we don’t have a separate “ProxyCredentials” object. Rather, both the proxy authentication and the ultimate server authentication access credentials from the same location (such as ChannelFactory.Credentials).

One limitation of this approach is that if you are using the same authentication scheme for your proxy and your server, then you have to use the same credentials (e.g. the same username and password for Basic Auth). This was a concious tradeoff we made for V1. If any of you have a scenario that is broken by this limitation I’d love to hear about it.

In my description of HostNameComparisonMode I neglected to explicitly mention how the wildcard-ness affects your port#. In short, we will ignore the port# in our match if you have chosen StrongWildcard or WeakWildcard, and we will include the port# in our match if you choose Exact.

This behavior is especially useful when using network monitoring intermediaries. Let’s say you have an intermediary listening on TCP port 8080 that forwards traffic to your service on port 8081. The Via on the wire for net.tcp would be net.tcp://mymachine:8080/a/b/. When this intermediary forwards the packets to your service listening at port 8081, the request would succeed only for Wildcard bindings.

Actually setting up a intermediary takes a few more tweaks to your service and client that I’ll go into more detail about next week.

When listening on any socket-based protocol (http, net.tcp, UDP, SMTP, etc), there are ultimately two items that contribute to where we listen: IP Address and Port.

Your port# is usually specified in the URI of your endpoint (see RFC 2396, section 3.2.2). If a port# is not specified then each URI scheme has the option of supporting a default port# (HTTP uses 80, HTTPS uses 443, net.tcp uses 808, etc.). You can also configure a WCF endpoint to listen on
any available port# for client-side or Discovery/registry purposes.

For WCF transports, your IP Address is specified in the same manner, though this may not be obvious on the surface. If you specify an IP Address in the hostname of your URI, then we will listen on that exact IP Address. For example, net.tcp://127.0.0.1/myservice/ will only receive traffic received on the IPv4 localhost interface.

If you do not specify an IP Address in your endpoint URI, then the transport will provide a set of default IP Addresses for listening. For net.tcp, we will listen on IP_ANY (both V4 and V6 where available). For http, we will use the http.sys IP Listen List, which also defaults to INADDR_ANY and INADDR6_ANY.

For routing traffic, wildcard semantics are in effect, which means that net.tcp://localhost/a/b and net.tcp://127.0.0.1/a/b will match the same set of incoming Messages. The difference is that the first URI is exposed to all interfaces/IP Addresses while the second URI is limited solely to 127.0.0.1.