When you hear the word security, what comes to mind? SSL? Firewalls? Authentication? Authorization? B-52 bombers? Security means different things to different people, but in the context of securing applications, we can think of security in two parts: access control and secure communication.

Existing Measures
Access control encompasses a number of concepts, including identity management, authentication, authorization, and auditing. It includes knowing who your users are, knowing what they can do in your applications, and keeping a record of what they have done. There are a variety of products on the market today that provide cost-effective and manageable solutions for securing Web-based applications. Access control products work by integrating with a directory of user identities, typically stored in an LDAP directory or a relational database, and use the user identity and entitlement information to drive a set of shared services including user authentication and authorization. By centralizing access control as a set of shared services, security for all applications, regardless of the language or protocol, can be centrally managed in one place rather than in each application.

Secure communication involves keeping the conversation between two parties private. For example, when you purchase something at your favorite online store, your browser and the Web server it is interacting with is (hopefully) using an SSL connection to communicate. This technology prevents others on the Internet from "spying" on the transaction, ensures that your credit card information is transmitted securely, and guarantees that the order you enter in your browser can't be manipulated on its way to the online store.

Access control and secure communication are probably the two most important aspects of security that need to be addressed for Web services. While the concepts are the same, new technologies and products need to be developed to meet the requirements of this new Web services world. We'll take a closer look at the requirements that Web services imposes on these two areas and explore some of the solutions available by looking at a case study of an office supply company, PENS, Inc. PENS wants to create a set of Web services for its customers to use to place orders. Customers will then be able to submit purchase orders in the form of XML documents and send them electronically to the PENS Web service.

Authenticating and Authorizing Users of a Web Service
The first generation of the Web service will utilize PENS' existing access control infrastructure, invested in browser-based Web applications. These applications are typically protected by asking the users to identify themselves and provide some sort of a shared secret, such as a password. Because Web service requests aren't going through a browser, asking the user for their user name and password after receiving the XML document isn't possible. The information needed about the user has to be available when we receive the XML document.

SSL
This could be accomplished with an existing access control product, using client-side certificates for authentication. In order to send their XML purchase order, all of PENS' customers would require a certificate that they could attach to an SSL connection to the PENS server. The user's certificate information would be passed along with the XML purchase order. When the access control product intercepts the XML message, it authenticates users based on their certificate information. This solution isn't feasible for PENS, however, because it doesn't have a PKI infrastructure in place nor does the company want to start handing out or managing certificates for all its customers.

SOAP
Another solution might be to have the user's credentials inside the XML message itself. Utilizing SOAP, PENS could require that the sender put their user ID and password in the SOAP header. SOAP was designed to allow for this additional information without having to change the schema or DTD of the purchase order. This information can easily be taken out of the message once it has been processed. When the message arrives at PENS, the credentials would be extracted from the SOAP headers and used to authenticate and authorize the user.

Sounds simple enough, but extra care needs to be taken to ensure that the XML message is securely transmitted to the server. If someone were to intercept the message they'd now have the user's ID and password. In order for this to be a truly secure transaction, purchase orders must be transmitted directly from the user placing the order to the PENS server. This is not an acceptable long-term solution since that scenario may not always be true.

XML Signatures
A possible third solution is based on a new technology developed specifically for binding user identity to an XML document: XML signatures. XML signatures do just what their name implies, they allow someone to electronically sign an XML document, thereby binding their identity to it. This is no different conceptually what you do when you sign a paper purchase order: you give your approval by putting your identity on the document. PENS can now require that all purchase orders sent to the Web service be digitally signed with XML signatures. When the purchase order arrives, the signature can be used to determine who sent the document and prove that the document hasn't changed since the person signed it.

XML signatures depend on private and public key pairs. The signature itself is created using the sender's private key information and can be verified by the recipient of the message using the sender's public key. The only requirement for this solution is that PENS has to know the user's public key. While there are several ways to do this, one of the simplest is that the user's public key could simply be part of the user's profile in the PENS directory. (While XML signatures allow for the public key information to be passed along with the message, there still needs to be some mechanism to identify the holder of this public key with the user record in the PENS, Inc. directory.)

Moving Beyond Existing Measures
The three examples above represent what will most likely be the prevalent security models for the first generation of Web services. The element they share is that the provider of the Web service maintains the user identity information and knows how to authenticate each of its users. It requires that anyone who wishes to use the Web service establish an identity and provide some information so that the Web service can authenticate them. But as Web services evolve, these assertions may not be true or practical.

Hosted Identity Services
As PENS, Inc., becomes more popular, it becomes more difficult for the company to manage the thousands or millions of user identities in its directories. Most of the information maintained about each of its users is identical to the information that other Web sites and Web services maintain about their users. If there were a single user profile somewhere that could be shared across all these Web services, it would not only make it easier for users to manage their own profile information, it would also mean that each of the individual sites would no longer have to manage all the information. In addition, if this service were to provide the ability to authenticate those users, you would have a very valuable service for PENS' Web service.

Passport
This model is known as a hosted user identity and authentication service and is the goal of Microsoft's Passport technology. It's already in use in many Web sites to provide a single user identity and authentication service. While today it's limited to browser-based applications, the Passport technology holds the promise of working with XML-based Web services as well. With Passport, users create and manage their user profile in one place only. Sites or Web services that integrate the Passport service are able to access this profile information once the user has been properly authenticated by Passport. This means that the Web service provider no longer has to provide profile management or authentication services for these users.

The requirements for this model to work are straightforward. First, the Web service provider will need to integrate the shared service software into their Web service infrastructure. Second, the Web service provider must trust the hosted service to perform this functionality on their behalf, and have confidence that the information provided is accurate and secure. Finally, the Web service provider needs to believe that users are willing to use the Passport service to store and manage their information. Since this service would be the only source of user identity, only users of that service would be able to place orders at PENS. Because of these requirements, these solutions tend to not completely replace a site's own identity and authentication service, but rather augment it to reduce the overall burden and provide a convenience feature for the users willing to use the shared service.

Hosted identity services like Microsoft Passport hold great promise but they don't eliminate the need for a Web service provider to centrally maintain user identities. They're not geared towards addressing enterprise identity management. Companies need to maintain full control over their employee identities. They need to be able to decide who, if anyone, gets to see what data. Combine that with the fact that many companies have already made major investments in identity management systems and we see that these hosted identity solutions are not a complete solution for sharing user identity.

Sharing User Identity
Companies will also need the ability to exchange user information with their partners. How can this be achieved securely if the information is stored inside an enterprise's identity management system?

Let's illustrate this. PENS has created a corporate account program for its Web service. This enables authorized users from member companies to place supply orders directly using the Web service. The decision as to who is an authorized user and who isn't, and what spending limit each authorized user has, needs to be managed by the member company and not by PENS. The member company is the one that truly knows the users within their organization and the roles they should have. PENS needs a solution that will allow their corporate customers to manage their own user information while at the same time still allowing the Web service to authenticate and authorize the users of the Web service.

One of those companies, Widgets, Inc., has 35,000 employees and wants every employee to utilize this Web service when ordering office supplies. It wouldn't be practical or secure to copy the 35,000 employee records from the Widget user directory to the PENS user directory. PENS doesn't really need to know each of the 35,000 people personally, all it needs to know is that the Web service request is coming from a valid employee of a company with a corporate account.

SAML
A new XML standard called SAML (Security Assertions Markup Language) is being developed to help solve this problem. The SAML specification is currently being finalized within the OASIS XML-Based Security Services Technical Committee. SAML allows two entities to share identity, authentication, and authorization information. SAML is based on the concept of assertions. These assertions effectively allow one entity, an authentication authority, to state facts they know about a user to another entity, in our case the Web service provider. With SAML and Web services, the trust relationship is between the Web service provider and the authenticating entity, and not the user of the Web service directly.

The way SAML would work in our use case is that the employee of Widgets who wants to place an order with PENS would authenticate himself or herself using the Widgets authentication provider (using whatever mechanisms are in place). Once authenticated, the user would ask the authentication provider for a set of SAML assertions to send to PENS, along with the purchase order. These assertions, which are nothing more than XML fragments, would state that Widgets, Inc., authenticated the user. They would also contain basic information about the user, along with entitlement information, such as what their authorized spending limit is. To ensure that these assertions can't be modified and to prove who generated them, they're digitally signed by the authentication engine. These assertions would be sent along with the XML purchase order to PENS.

When the message arrives at PENS, the SAML assertion is found in the message and used for authentication. Rather than authenticating the end user, PENS is really ensuring that the SAML assertion was created by a trusted partner, in this case Widgets, Inc., and that the assertion hasn't been modified. Once authenticated, the spending limit information about the user can be extracted from the SAML assertion to determine if the user is authorized to make this purchase.

This example covers only one aspect of SAML's power. Along with identity sharing, SAML in addition seeks to address issues like remote authentication, remote authorization, single sign-on, and other business-to-business security issues. Access control, security, and infrastructure vendors are actively incorporating SAML into their products and usable solutions should become available throughout 2002. A toolkit called the JSAML toolkit is available from Netegrity, Inc., (see references at the end of this article for the URL). Downloading this will allow you to test this new technology and get a better understanding of its features and power.

Liberty Alliance
Another solution is the Liberty Alliance project. Started in September 2001, this organization is working to deliver a solution to the concept of "federated" user identity. While there appears to be a lot of muscle behind the effort, at the time of this writing there was little more than a set of white papers, marketing slides, and a press release available. Hopefully the alliance will work well together to quickly deliver a solution.

XML Key Management
Finally, another new effort originating from the W3C to address sharing identity information is the XML Key Management working group. Based on an early effort known as XKMS (XML Key Management specification), this group is chartered with creating a solution that will simplify the integration of PKI solutions with Web services. Many of the new XML technologies dealing with security, such as XML Signatures, SAML, and XML Encryption, leverage public/private key pairs as part of their implementation. XKMS provides a convenient and standard mechanism for transporting, locating, validating, and registering key information. There are various toolkits available that illustrate the use and functionality of XKMS. It's not clear, however, how much of this specification will survive the W3C process.

Keeping Content Secure
Another aspect of security is how to keep the conversations between a client and a Web service secure. Given that these XML messages may contain confidential information, it's critical that there be mechanisms in place to keep the content private. Just as SSL has been the primary means for securing communication between a browser and a Web service, it can provide a similar service for Web services. Enabling server-side-only SSL on the Web service platform ensures that the messages between the client and Web service are protected from prying eyes. The only limitation to the use of SSL with Web services is that SSL secures a single client-to-server communication channel. While this is acceptable for securing browser-to-Web-server communication, it may not be enough for Web service-based applications. As these applications evolve, they will go beyond a simple request to a single service. Web service-based applications will consist of a number of disparate Web services aggregated together to work over the same XML message. These Web services may be distributed across the Internet, hosted by different providers, or have different rights over the information within the message. While SSL could certainly be used to secure the communication from one service to another, once the message has arrived at a particular Web service, the service has equal rights over the content of the message and is expected to keep the content of the message secure in its environment. What's really needed is the ability to secure the content - not just the communication.

XML Encryption
To address some of these issues, a working group within the W3C is working on a new XML-based standard called XML Encryption. This standard will provide the ability to encrypt digital content such as entire XML documents or selected portions of them. The encrypted document could be sent through unsecured protocols, handed to untrusted intermediate services, or stored indefinitely in unsecured repositories. Only the intended recipient of the document will be able to decrypt it and see the protected content. Different portions of the document can also be encrypted for use by different recipients. This would be very useful for protecting sensitive documents like medical records. Your entire medical record could be captured as digital content but only certain portions of the record would be made viewable to authorized medical or insurance personnel. XML Encryption will protect the content being transmitted rather than just securing the communication channel between two parties, as SSL does.

Conclusion
The biggest issue with the various technologies and solutions described above is their immaturity and the present lack of commercial products to support these technologies and ease the process of integrating them. To take advantage of any of these technologies today requires a fairly significant integration effort. This situation will certainly improve as vendors integrate these technologies into their products and as the standards solidify. The good news is that the first generation of Web services currently in development doesn't necessarily require all of these solutions to be in place in order to deploy them. These first-generation Web services will utilize existing technologies like SSL, PKI, and access control products for security.

The most important thing you can do to prepare for securing Web services in the future is to ensure that you have a scalable and flexible security infrastructure in place that will continue to grow with you as new technologies emerge. Centralized access control and identity management products have proven themselves to be invaluable in securing Web applications and reducing maintenance costs of the current generation of Web-based applications. These products must continuously evolve to support the new application models and provide the same level of protection, if not greater, and cost savings for these next generation applications. The model of how to secure applications doesn't need to change with the arrival of Web services, but there just may need to be new technologies to help support the model.

References:

SAML: www.oasis-open.org/committees/security
JSAML Toolkit: www.netegrity.com/products
JSAML Whitepaper: www.netegrity.com/files/JSAMLwhitepaper.pdf
Securing Web Services Whitepaper: members.netegrity.com/access/files/TransactionMinder.pdf
Microsoft Passport: www.passport.com
Liberty Alliance project: www.projectliberty.org
XML Signature: www.w3.org/Signature
XML Encryption: www.w3.org/Encryption/2001
XKMS: www.w3.org/2001/XKMS

Author Bio
Jim Ducharme is a director of development at Netegrity, Inc., the leader in securely managing e-businesses. He is responsible for the development of new product initiatives at Netegrity aimed at securing Web services and XML-based B2B infrastructures.

JDUCHARME@Netegrity.com