Web Service Authentication Issues
"The openness of Web services is such that you can't really deploy them, especially going
out of the intranet cloud, without some security mechanism in place," Adams said.
Perhaps the biggest misconception about Web services security is in understanding the
nature of the problem. It's not a matter of preventing outsiders from sneaking in the IT
department's back door; it's a matter of preventing the key from falling into the wrong
hands after you've given keys to all of your friends.
When people think of Web services security issues, they tend to think of hacking or other
forms of traffic snooping, said Ron Schmelzer, founder and senior analyst of Waltham,
Mass.-based consulting firm ZapThink LLC. But those problems are solved easily, he
said, using SSL at the protocol layer, and encrypting SOAP messages.
Schmelzer said the most significant external Web services security problems lie in the
realm of authentication and identity management, because Web services transactions are
conducted between two computers.
For instance, Schmelzer said, many companies, like Deutsche Bank, are building portals
that call on Web services to gather data from back-end applications. The problem is that
those applications don't know where the request is coming from.
As a Web services provider, Schmelzer said, "you're not providing access to a human; it's
another system. If we expose an interface to our SAP system, how do we know whoever
is making that Web service request is authorized to make it?"
So how can a requester's identity be verified? It's tricky, Schmelzer said, because there's a
lack of context in public, machine-to-machine communication, making it difficult to track
what company or system is initiating a Web service call. "Plus, the request may not be
made directly," he said. "It may be made through a portal or other composite application.
It gets complicated very quickly."
While there's no easy answer, standards groups are working to mitigate the issues. This
summer, both the Liberty Alliance Project and the Web Services Interoperability
Organization (WS-I) introduced specifications to enable federated identity beyond the
walls of a company's own data center, effectively setting the ground rules for how Web
services present themselves to one another.
However, Schmelzer said, even the best standards are ineffective unless vendors latch
onto them and build useful products. "Creating specs is one thing, but how do you get
digital certificates and identity management to work? You can't build an identity
management system on your own," he said.
Adams, who is now a director with New Delhi-based financial services consultancy Indus
Valley Partners, said Deutsche Bank's answer was to implement third-party authorization
software from Westbridge Technology Inc. of Mountain View, Calif.
The Westbridge software imposed rules on authorization, giving Adams the option to
verify only certain types of Web service requests. It also provided a transaction audit
trail, making it easier to identify where requests originated.
Without the third-party application, Adams said, he would have probably been forced
into hard-coding rules for many different types of requests, which would have been
"cumbersome work."
"With a tool like Westbridge's, it's just a matter of setting up your rules. That way,
Application A can be pre-approved to talk to Application B, instead of having to figure
out what Application B wants and then granting the request," Adams said.
Schmelzer said there are a host of other vendors, including Netegrity Inc., VeriSign Inc.,
RSA Security Inc., and Oblix Inc., offering identity management products for use with
Web services.
Looking at the big picture, Schemelzer said, Web services aren't going away, and
companies need to develop comprehensive identity management strategies to deal with
the security implications of Web services.
"We've done a lot of research, and we've found you can't implement Web services in any
widespread way without identity management," Schmelzer said. "Things break very
quickly when you have no idea who is accessing your applications."
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 server or an actual string of characters. For our application, we are using a 33character character string.
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 vernacularchallenged. 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.
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.
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.