| |
|
|
 |
 |
5870 West Jefferson Blvd., Suite A
Los Angeles, CA 90016
Tel: 310.815.8855
Fax: 310.815.8808
info@OnlineSecurity.com
© 2008 Online Security
All rights reserved.
|
|
|
SUCCESS STORIES
Authentication for Web Services | | Introduction
Consider authentication of your web service to be like a door on your house. It needs to be wide enough to allow people to enter, but only if they've knocked first. Getting away from the cutesy analogies, authentication is the process of making sure that the person who is asking to use the web service is really the person that they claim to be. This is done by requiring the user (also known as the "principal") to provide a set of credentials. In return, they will receive a security token that can be used to access the server.
The credentials usually take the form of a user id and password. However, what is really required is everything necessary to uniquely identify the user. For example, in our sample web service, we require that a company code be supplied along with the user id and password. The reason for this additional information is that the data we use to rate a shipment is different for each company.
On the other hand, the security token that is returned is usually more conceptual than physical. It can take the form of a cookie placed on their browser, a session id stored on the serveror an actual string of characters. For our application, we are using a 33-character character string. The reason for our choice will be detailed later in this article. And before we get to that, let's look at the tools that are available to assist with the authentication process.
Operating System Options
One of the easiest ways to implement an authentication mechanism for a web service is to integrate it with the operating system. In this case, that would be Windows 2000. Windows allows for four different types of authentication:
Basic
As the name implies, this is the lowest level that security goes short of letting everyone in uncontested. The process involves transmitting both the user id and password that make up the credentials in cleartext to the web server. That's unencrypted, for the vernacular-challenged. This information is then validated against the security information maintainted by Windows.
The real beauty of using Basic authentication is how easy it is to set up. For IIS, you start by opening the Interset Services Manager and right click on the web site to view its properties. Under the Directory Security tab, click on the Edit button that is associated with Anonymous access and authentication control. Make sure that Anonymous Access is unchecked and Basic Authentication is checked, as well as Integrated Windows Authentication checked. This last field ensures that the user id and password that is provided must resolve to a valid user on this server.
Basic over SSL
This level of security follows the same steps as Basic authentication, with the exception that all of the transmissions are encrypted using the SSL protocol. The configuration steps are the same as with Basic, except that the web site is also configured to use SSL (the setup of which is beyond the scope of this article). Unfortunately, if every message is encrypted, there will be a performance impact. I have heard stories of a fifty-fold increase in response time, but studies that are much more rigorous in their methodology have indicated that you should expect a 60-80% increase.
Digest
The Digest authentication mechanism solves the performance issue by reducing some of the exchanges that SSL requires. The credentials are hashed on the client instead of going through the gyrations of requesting the necessary information from a certificate authority. The downside is that you will be limiting your list of valid browsers to Internet Explorer. This mechanism is not natively supported by the others.
Integrated
In this methodology, the user's credentials are transmitted to the web service using either NTLM or Kerberos. For the uninitiated, these are security mechanisms that are integrated into Windows 2000/XP. In other words, the service leaves it up to the operating system to determine who is valid and who isn't. While this is an efficient method, it again restricts your clients to using Internet Explorer. Not to mention that you must be using an intranet. Both NTLM and Kerberos are local authentication methods, so this option is not available if you want to expose your web service to the public at large.
Client Certificate
For really high end security, you could have your clients configure their browser to use certificates. The user would request and install a certificate from a trusted third party (i.e Verisign, Entrust, etc.). Then the web service could query their system to verify credentials as required. In order to function correctly in our web service context, the certificates must be linked on the server side to an existing user account.
While these are all valid choices and might very well be appropriate for your environment, there are drawbacks to utilizing any one of these options in our sample service. For example, since the Internet (and therefore web services) is stateless, the authentication information would need to be transmitted with every message. To me, this seems like a waste of both bandwidth and processing power. Perhaps the way to go would be to utilize a prepackaged solution from a third party.
Third Party Choices
When I suggest the idea of utilizing a third party to support authentication for a web service, I'm talking about Microsoft Passport or the Liberty Alliance Project. The premise behind the single sign-on functionality that is offered by these tools is quite simple. The first time that a user hits the web site, they will be prompted for their credentials. Then as the user nagivates from page to page, their credentials follow along. Not their password, you understand, but a token that can be used by the page to retrieve relevant information.
The problem with using third party services for web service validation lies in how web services can be used. Let's say that you have a web service that rates shipments (This is the web service that we'll be building in this series. Check out the Getting Started With Design link in the References section to the right for more details.) If people who use your service are your only clients, then using Passport or Liberty is feasible. But if your clients repackages your web service functionality and passes it on to their clients, there is a problem. Neither Passport nor Liberty have the ability to automatically 'passthrough' credentials. In other words, if your client requires their users to log in using Passport, they will have to write additional code in order to pass the Passport credentials to your service. Otherwise, the user would need to log in again to access the service, pretty much obliterating the concept of a single sign-on. While I expect that we will see tools like this added to the single sign-on
arena in the near future, at the moment, it makes them ackward to use for some web services.
Roll Your Own Authentication
When you take advantage of the authentication methods made available through the operating system or a third party, you get the benefit of using tools that have already been developed and tested. Okay, we're making an assumption about that tested part, but play along with me here. Still, even with these tools at our disposal, there are situations where more is required. If your application maintains is own user list or requires additional information above and beyond the user id and password, you are forced to create your own technique. And that is what we are faced with in our sample web service. Along with the user id and password, we need to gather a company identifier. In other words, none of the 'standard' techniques will be sufficient for our purposes, leaving us with no choice but to create our own authentication system.
The Choices We Made
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.
Our Process Flow
Now let's take a look at the details of how we implemented the authentication method that we just outlined. The code necessary to create the databases, populate the tables with some sample data, as well as the code for the Login method and the aspx file used to test it are in a .ZIP file accessed through the Source Code link in the References section to the right. The flow through the process is as follows
1. The initial call to the web service is made through the Login method. The company code, user id and password are provided as parameters. For security reasons, this call will take place over SSL.
2. The web service uses the Login method of the CLogin object to validate the credentials. The parameters to the method are the same as the initial call to Login. The result will be either a 33-character token or a blank string.
3. The Login method invokes the stored procedure called prcValidateUser on the Token server. The result will be a recordset (or more accurately, a Data Reader) containing either a 33-character token or a blank string.
4. The stored procedure prcValidateUser using the information in the Company table to identify the server on which the database can be found and the name of the database itself. This information in turn is used to build the statement that gets executed on the remote server.
5. Through the stored procedure called prcValidateUser that is in each company's database, we validate the credentials that have been provided.
6. If a match has been found, then a token gets generated and returned up the chain. As mentioned in the previous section, we use a check digit as part of the process. The value of the token, along with the company and user associated with it gets stored in the Tokens table.
At this point, we have the security token that we need to make the rest of the functions work. You will see it put to use in future articles. As for the next segment, we will discuss the technique that we use to support the authorization portion of the server. As always, any suggestions or improvements are greatly appreciaed. Keep those cards and letters coming. :)
For more information, email tag@tagconsulting.com
|
|
|
|
>> Full SUCCESS STORIES Archive
|
