So now the question becomes how do we build such a mechanism. To do so, we are faced with many decisions. Since it's almost always a good idea to be aware of the boundaries for our decision, let's review our criteria

1. Passwords must not be transmitted in cleartext
2. Having a valid set of credentials (in our case, a company code, user id and password) is sufficient to gain access. It is unlikely, given the requirements that we place on the password (minimum of six characters, including at least one number), that the credentials could be guessed so long as they are maintained securely by the client.
3. The shipment rating request can be made using either SSL or standard HTTP, depending on the requirement of the client
4. It should be easy for a client to connect our service to their security environment
5. It should be easy for a developer to use the security mechanism implemented by our web service

Given these boundaries, what thought process do we go through? First, let's address the requirement that password not be sent in cleartext means that encryption will be part of the solution. And given our encryption choices, it seems that SSL is be best solution to make it easy on both the client and developer. And do we really need to have SSL used on every message? Certainly not if we're willing to have other messages sent in the clear. Although I'm not usually in favor of designing features for a user to turn on and off (I believe that it is actually a form of laziness on the developer's part), in this case we will leave it up to the client as to whether they feel comfortable having their shipping information sent across the Internet without the benefit of SSL.

Next up. How do we get the credentials from the client to our server. Our options? We could put them into the SOAP header. We could put them into the SOAP body. The reality is that it doesn't make a difference. We actually have them in the body because it seems more natural. But this is one case where the choice is more a matter of style then technique.

So where does that leave us. What we will be implementing is as follows. First, we will add a Login method to our web service. The parameters are the company code, the user id and the password. The result will be a security token (specifically a sort-of GUID that gets generated upon successful validation). This token will be used in subsequent calls to the web service. That way we can use SSL for the first call only while leaving the remainder in HTTP.

How are we going to generate our token. The obvious choice is to use a GUID as generated by Windows. But that does expose us to a subtle risk. If we use just a plain GUID, then every time we get a request that contains a 32-character string in the Token parameter, we need to validate it against the list of tokens that we maintain in the database. If someone wanted to launch a denial of service attack against us, they would just need to send multiple requests all having a 32-character token. Our database servers would go mad trying to identify all of them.

Our solution is to add a check digit to the token. In our example, it is placed at the end of the token, but the location is not important. The reason for including the check digit is that it allows us to validate the token before hitting the database, thus reducing the threat.