Unprotected Metadata

The idea of metadata is to provide a description of your service such that someone, with no other information about you or your service, can come along and build a client. If the metadata has sufficient detail, then the client and service can intelligibly exchange messages with each other. That doesn't mean the two sides can communicate. The client may have no idea what the server's Zykwygzle method does. However, it's a start.

Even though metadata is very useful in this way, that doesn't mean that you want to share your description with just anyone. In the same way that error pages started on by default and later got turned off, metadata has long been on by default but was disabled during the beta. Again like error pages, there's a certain amount of potentially sensitive information in the metadata that you might not like an attacker to have. If you're comfortable with revealing the service metadata, then you can enable the metadata provider. I've already talked about how to flip the switch that turns metadata back on.

Enabling metadata adds another endpoint to your service that supports the IMetadataExchange service contract. This endpoint is an infrastructure endpoint, meaning that while it supplies a web service, its service is in a supporting role to another endpoint. Since metadata is available on its own endpoint, you can supply any binding you choose for serving this content. There are two popular configurations.

The first configuration is to restrict the metadata to exactly the same group of people that have access to the service. You probably have everything you need to take care of this because you've already defined a web service with that level of protection.

The second configuration, and probably the more popular one, is to simply make the metadata widely available regardless of the level of protection of your service. In this case it seems like you need a configuration that's totally separate from the service. However, we can do most of the work for you. For instance, suppose you've got an HTTPS service hosted in IIS at https://mydomain.com/service. You've had to create an SSL certificate, configure IIS, and setup the security in the service configuration. Releasing the metadata to the world is still really simple. You need to add a single behavior to the configuration.

 <serviceMetadata httpGetEnabled="true" httpGetUrl=""/>

Now, you have automatically generated service metadata available at https://mydomain.com/service?wsdl that anyone can come up and consume.

Next time: Basics of Failure

Comments

• Anonymous
  December 11, 2006
  The story from yesterday: there is an important setting for composite duplex that is only settable through