Web Services[c] Theory and Practice

7.2 Security considerations for Web services

There are three very distinct sides to Web-services security if one looks at this pivotal issue from a holistic, all-inclusive standpoint. Web services by design only work per a strict client/server model (albeit within a larger n - tier architecture) ”where, depending on one s perspective, the calling application can be considered to be the server while the Web service being invoked becomes the client, or vice versa, where the calling application is deemed to be the client of a Web service. In reality it does not matter which is the server and which is the client, as long as one recognizes that there will always be two independent software components at play ”with asynchronous (i.e., not session based) communication between them. Thus, from a security standpoint, to guarantee total coverage one has to look at both software components and the connection between them. It means that it can be counterproductive to focus on just one side of the model only to discover down the road that the other side is relatively exposed. Figure 7.4 highlights all of the perimeters that have to be safeguarded when it comes to Web services.

Figure 7.4: All of the Web services “ related entities that need to be protected to guarantee adequate end-to-end security.

Enterprises already have policies and technology in place to protect their networks (e.g., firewalls, SSLs, virus scans , intrusion detection alarms) and applications (e.g., authentication). Web services “related security measures do not in any way displace any of the existing security policies, procedures, and technologies in use by enterprises. That is a given. Instead, they require that existing technology (e.g., authentication, digital signatures) be extended, as well as the addition of a whole new Web services “specific layer of safeguards (e.g., XML application gateways and software validators such as WebInspect), if one wants to deal with remotely invoked services.

Given that enterprises have now relied on computerized, mission-critical applications for over four decades, the access control and user validation mechanisms needed to deter unauthorized access are well known. Much of these mechanisms now fall into what is referred to as identity management or the technology of trust. Stringent authentication, whether it be with user ID/password schemes, digital certificates, or two-factor token-based authentication such as RSA Security s SecurID scheme, is the basis for identity management. New applications that intend to invoke Web services should continue to rely on proven identity management and access control mechanisms to ensure that they can be accessed only by authorized users. This is standard application-level security and is independent of whether an application has any Web-services affiliations or not.

The introduction of Web services, however, mandates that application-specific security has to be extended to encompass the new application Web-services interface ”if one intends to pursue the remote Web-service model over the Web. At a minimum, there are at least seven different types of security measures that may need to be enforced at each individual application Web-services interface ”though the need for some of them (e.g., nonrepudiation) will depend on the nature of the data and transactions involved. These security measures are as follows :

  1. Stringent service provider/service requester authentication between the application and each Web service it invokes

  2. Access control, possibly at both ends, to determine the functions that may be requested ”per invocation, based on the authentication instance

  3. Digital signatures to ensure the validity of contents

  4. Nonrepudiation to preclude either side from disowning a transaction once it has been executed

  5. XML application firewall, such as IBM s Web Services Gateway, to decouple the end-to-end communications connection at the enterprise network boundary

  6. Proven data encryption end to end ”most likely with the industry standard SSL or its successor TLS

  7. Denial-of-service/replay attack detection and diversion mechanisms ”which typically come with powerful traffic pattern sampling, analyzing, profiling, and reporting tools that will continually monitor the network interface to spot any unusual trends

None of these security measures can or is meant to identify rogue or compromised Web services ”though bidirectional authentication could make it harder to surreptitiously hijack transactions being sent to one Web service and divert them to a rogue service. Consequently, it is still of paramount importance to unequivocally establish the credentials, trust-worthiness, and technical competence of a Web-service provider by using traditional, time- tested methods before one ever gets around to worrying about implementing any of these measures. One course of action is to consider only Web services from well-known, well- funded entities that can reasonably be expected to run a tight ship with all necessary safeguards to prevent Web services from being hijacked, hacked into, or otherwise compromised.

Once a service provider and the necessary Web services from that provider have been adequately validated and chosen , authentication, particularly in the form of digital certificates, can be used to make sure that calls to a specific Web service are in fact being responded to by the expected service. This authentication will typically be done in both directions: the application authenticating the Web service and the Web service authenticating the application. Depending on the sensitivity of the transactions involved, one could consider multilevel authentication ”for example, an initial digital certificate “based authentication followed by a two-factor authentication using RSA s widely used SecurID. (For the record, it is worth noting that at present this RSA SecurID technology is being used by over 10 million Web users around the world for secure application access, VPN utilization, Web server protection, and corporate portal partitioning.)

Proven authentication technology, including digital certificates, existed well before the advent of Web services. The success of corporate portals, e-commerce, and b2b applications was contingent on the availability of relatively impregnable authentication ”always keeping in mind that, as with any type of security, total 100 percent infallibility is next to impossible to guarantee. But it is safe to say that this technology is mature, widely used, and well understood by those whose job it is to safeguard corporate assets.

Over the last 2 years there have been considerable effort, led by IBM, Microsoft, BEA, and security stalwarts VeriSign and RSA, to come up with new XML-based standards to more tightly align this prerequisite technology with Web services “related methodology ”in particular, SOAP.

The key specifications on this front, spearheaded by the overarching WS-Security initiative, are listed in Table 1.1. This, however, as one should be able to appreciate, is a very dynamic and fluid arena at present, with new specifications being added and many updates to the existing ones. For the latest status on these specifications visit www.xmlweb.org, a new portal committed to promulgating the latest status on Web services “related technology.

The good news is that existing authentication, digital signature, SSL/ TLS, and nonrepudiation solutions can be easily used very effectively, at the application Web-service interface ahead and independent of the XML-centric security standards. The goal of the new standards is to facilitate tighter integration. But waiting for these standards and products that comply to them should not be used as an excuse for not exploiting Web services. The exact security measures, from the previous list, that should be implemented on a particular application “Web-service interface will depend on a number of factors, including:

Suffice to say that determining the appropriate cocktail of security measures for any given application Web-service interface will be a complex and multifaceted exercise that will have to be undertaken on a per-service basis. In addition, there will invariably be pressures to consider optional refinements, such as adopting single sign-on schemes to minimize the amount of individual authentication required each time a service is invoked or when invoking different services offered by the same provider. Single sign-on is always a double-edged sword. Though it simplifies and expedites repeated access to the same provider or the same service, at the same time it lowers your authentication barrier , albeit by a smidge, increasing the chances of it being breached by a determined perpetrator.

The bottom line here is that there are plenty of well-proven security measures to adequately safeguard most enterprise-level Web-services scenarios ”but you have to be diligent in working out exactly what you need to implement per interface, and you need to be continually vigilant to make sure that all the security measures are functioning as they are supposed to. In many cases it might be best to work with established enterprise security experts, such as RSA, VeriSign, or IBM/Tivoli, to determine an appropriate security architecture for Web services. Plenty of consulting firms, such as Accenture, EDS, BearingPoint, Deloitte, and individual consultants , will trip over each other trying to help you formulate Web services “related security strategies for a fee.

7.2.1 Digital certificates and PKI

Digital certificates (DCs) are now routinely and transparently used on the Web for e-commerce, online banking, electronic trading, and corporate portal access applications ”so much so that the properties option of popular Web browsers now includes a button that will show the DC that is in force at any given time. Figure 7.5 shows the DC details available from Microsoft s Internet Explorer ”in this instance for a secure connection with electronic trading powerhouse Charles Schwab.

Figure 7.5: Details of digital certificate usage shown by Microsoft's Internet Explorer ”in this case, for a secure, authenticated connection with the Charles Schwab portal.

Digital certificates are an electronic credential (in the form of a small file) issued by a trustworthy organization such as a large company (e.g., IBM, Microsoft) or a security-specific entity such as VeriSign. Figure 7.6 shows a page from VeriSign s portal providing an introduction to one its public-key infrastructure-based digital certificate programs. A DC vouches for an individual s, a business s, or an application s identity and authority to conduct secure transactions over the Web. DCs are in essence the Internet equivalent of a travel passport. They are a universally accepted means of establishing one s identity and thus gaining entry to a protected resource. DCs are meant to replace traditional user IDs and passwords, which are not as secure or trustworthy ”hence, their applicability in the Web-services arena.

Figure 7.6: One of VeriSign's public-key infrastructure (PKI)-based digital certificate solutions.

The issuing organization of a DC is called a Certificate Authority (CA). Consequently, VeriSign is an example of an existing and well-known CA. Refer to www.pki-page.org for an extensive list of CAs around the world as well as products that can be used to set up a CA. A CA can issue a DC to individual users, a server, or an application ”where application in this context will also include a Web service, which is but a mini-application. If your company currently does not have any DCs, you may want to contact a CA and begin the process of acquiring a valid DC for use in Web services as well as other scenarios (e.g., corporate portals).

The acceptance of a DC as a valid credential is totally contingent on the recipient s trust in the CA. Therefore, just having a DC is not enough. You need to have confidence in the CA that issued it, especially since there are no uniform requirements, at least at present, as to what information a CA checks before issuing a DC. Some public Internet CAs may only ask the user for name and e-mail address in order to issue a DC. This is totally inadequate.

Fortunately, DCs today are closely tied in with PKI. CAs that support the PKI Exchange (PKIX) standards typically insist that the requester s identity information is further validated by a Registration Authority (RA) prior to a DC being issued. RAs are an integral part of a public-key infrastructure. There are proven PKI-specific products, such as RSA s Keon and IBM s Tivoli Trust Authority, that can be used by companies so that they can act as RAs. These systems allow companies to set up centralized or distributed electronic enrollment centers that validate user requests for DCs on behalf of the CA. Figure 7.7 shows a section from RSA s portal introducing the PKI capabilities offered by Keon.

Figure 7.7: RSA's Keon, one of several products now available that would enable a company to act as a certificate authority (CA).

The key thing to bear in mind here is that a DC, in the end, is only as good as the CA that issued it. So all DCs are not necessarily equal. If you are going to use DCs as a base-level security measure to establish the ongoing bona fides of a previously selected service provider, then you will have to check which CAs meet your security criteria. For example, you may not want to accept DCs from unknown CAs. Invariably it would be best to formally agree on which DCs you will accept from a provider up front when evaluating and validating the provider.

DCs leverage public-key cryptography. Public-key cryptography relies on the use of a pair of associated keys for encryption and decryption ” known as public and private keys. There is a mathematical relationship between these two keys that guarantees that anything encrypted with one key can be cleanly decrypted by using the other key. Which key is made public and which is kept private is totally arbitrary. With public-key cryptography, one can freely distribute the public key without in any way compromising or revealing the nature of the private key. The public key can even be stored in a public directory or a Web page. The private key, true to its name, must, however, be kept guarded and secret.

The public and private keys only work in tandem. That, so to speak, is the key. In other words, a document encrypted with the public key can only be decrypted with the private key. The document cannot be decrypted with the openly available public key, since this would nullify the whole point of encryption. The same applies the other way around. A document encrypted using the private key can only be decrypted using the public key. This makes sense because the private key is kept secret and should not be available for use by other parties. Figure 7.8 provides an overview of how public-key cryptography works, and Table 7.2 summarizes which keys are used for which operations. A DC will include the certificate holder s public key.

Figure 7.8: The overall big-picture depiction of the dual-key concept of public-key cryptography.

Table 7.2: Summary of Which Keys Are Used for Which Operations

Operations

Key Used

Send an encrypted document

Receiver s public key

Send an encrypted digital signature

Sender s private key

Decrypt a received encrypted

document Receiver s private key

Authenticate received digital signature

Sender s public key

Digital certificates are defined by the X.509 standard. An X.509 certificate is typically a small file that contains:

Today, there are several different types of DCs, each for a specific security scenario. Some of the main types of DCs include:

  1. CA certificates, which digitally validate the identity of the CA; they contain identifying information as well as its public key. CA certificates can be signed (i.e., further validated) by another CA (e.g., VeriSign) or be self-signed if the CA does not require additional validation. A self-signed certificate is referred to as a trusted root for obvious reasons. Self-signed certificates, unless from large corporations, may not be appropriate for Web-service applications.

  2. Server certificates to validate a server s identity and provide information as to who owns the server. They will contain the public key of the server s owner. These could be used by both sides to make sure that the servers on which the application and the Web service are running have not been changed without adequate notification.

  3. Client or user certificates, which validate the client s identity and contain the client s public key. Authentication of server and client certificates can be used as the basis for encrypted, client/server communications per the SSL protocol.

  4. Object signing certificates, which are used as the basis for digital signatures that vouch for the integrity of the accompanying object as well as the originator of that object.

The widespread use of DCs as well as digital signatures to validate the authenticity of a document (e.g., XML document) is made considerably easier by PKI. PKI, as indicated by the inclusion of the term infrastructure in its name, provides an incisive framework for facilitating secure but at the same time accessible and easy-to-use public-key encryption and digital signatures. The term public in the title, however, can be deceptive. PKI is not a centralized, public service for distributing and managing keys. The term public in this context refers to the public key in the public-private key combination. Today, PKIs are typically implemented on a corporate basis with PKI facilitating products from a variety of vendors , including IBM, VeriSign, and Entrust. IBM now even includes a comprehensive PKI on its flagship z/OS operating system for mainframes.

PKI sets out to hide the intricacies involved in providing a robust public-key encryption system so as not to intimidate users. In the true spirit of an infrastructure sustaining a utility such as that of the electric power grid or the cable TV network, PKI is a nonintrusive, transparent service. You can use PKI without actually knowing or caring that it is there, what it does, or how it does it.

There is a three-way, symbiotic relationship between PKI, digital certificates, and digital signatures. The current use of digital certificates for Internet applications is contingent on PKI. Without PKI, DCs would not be as convenient to use or administer. PKI consists of four primary components:

  1. CAs that issue and validate digital certificates

  2. One or more registration authorities (RAs), which work with the CA to verify a requester s identity prior to the issuance of a digital certificate

  3. One or more public directories (typically based on LDAP), where digital certificates, which will contain the public keys of their owners , can be stored

  4. A comprehensive and foolproof certificate management system

As an infrastructure scheme, PKI is expected to cater to key backup and recovery. Users typically have to enter a password to access their public-key encryption keys. But users forget their passwords or may leave the company. If there is no way to recover encryption/decryption keys in such instances, valuable company information, which has been previously encrypted, may be forever lost. Thus, it is essential to have a secure and reliable way whereby a designated and fully validated security administrator can recover encryption key pairs through the PKI system. Since such recovery will be possible only if the key pairs are properly backed up, it is assumed that the CA will automatically keep a backup of keys that have been issued.

In this context of backup and recovery, it is, however, important to note that recovery is only required for the key used for encryption/decryption. Keys used for digital signatures are not expected to be backed up or recoverable. The reason for this is that having duplicate (i.e., backed up) and thus recoverable signing keys undermines the overall integrity of a PKI. This has to do with something called nonrepudiation.

Repudiate means to disown or reject an action. Thus, denying involvement in a transaction is known as repudiation. Disowning a hotel charge made to a credit card via the signature-on-file scheme favored by North American hotels is an example of a repudiated transaction. Nonrepudiation precludes a person from being able to disown having participated in a transaction. In the digital world this means ensuring the sanctity of digital signatures. A prerequisite for this is the inability of a user to deny using his or her digital signature ”hence, the undesirability of having backups of signing keys.

If there are no backups and the user has sole and secure custody of the signing keys, then the latitudes for repudiating a digital signature are considerably reduced. However, just as in the nondigital world, with pen and ink “based signatures, there will still occur situations where users will try to repudiate digital signature “backed transactions. At this point, other electronic logs and traces will have to be used to enforce nonrepudiation.

The loss of a signing key, unlike that of an encryption key, is not catastrophic to business. The user will just have to obtain new keys to use with future signatures. The desirability of keeping backups of encryption keys but not those of signing keys means that users should not be allowed to use the same keys for both purposes because this will again mean that there will be more than one copy of the signing keys. A PKI must support two key pairs per user: one pair for encryption and the other for digital signatures.

Then there is the issue of the longevity of key pairs. To maximize security, key pairs should be periodically updated. A PKI can enforce this based on key expiration thresholds. However, since users may need to go back and decrypt documents encrypted with older keys, the PKI also needs to maintain a history whereby prior keys can be securely recovered. Again, this would not apply to signing keys. The PKI should destroy the old signing key pair each time a new pair is assigned.

Another issue pertaining to PKI and DCs relates to certificate revocation. In the event of a security compromise, DCs may have to be immediately revoked in advance of their built-in expiration setting. This may happen, for example, if the private key corresponding to the public key published in a DC gets into the hands of an unauthorized individual. Another instance would be when a user leaves a company. To cater to certificate revocation, a PKI must maintain a scalable mechanism to publish the status of all certificates, whether they are active or revoked. Application software validating a DC will first make sure that it has not been revoked.

The final topic related to PKI has to do with cross-certification, given the current absence of a global PKI scheme. Cross-certification is also referred to as PKI networking. Cross-certification permits multiple, autonomous CAs to work cooperatively so that they have a mutual trust relationship. One scenario for this might be that of CAs for trading partners having the ability to validate DCs issued by the other CAs. Another scenario might be that of a large multinational enterprise that decides to implement CAs on a geographical basis for scalability and management purposes. Yet again, today s leading PKI solutions are typically able to address all such requirements.

7.2.2 Two-factor authentication

Two-factor authentication, as with DCs, is another powerful and proven authentication system that can be used by itself to authenticate Web services and applications to each other, or in conjunction with another scheme (e.g., DCs). Two-factor authentication gets its name from the fact that it requires users (or applications in this instance) to identify themselves by using two unique factors, one on top of the other. One of the factors would be something users know (e.g., password or PIN), while the other factor would be something they have. Automated teller machine (ATM) cards, though not based on RSA s SecurID, are an easy-to-understand example of two-factor authentication, where your personal PIN is the factor that you know, while the ATM card with its encoded magnetic stripe is the factor that you have.

In reality, RSA does offer an ATM card “type system based on a chip-embedded smart card and a smart card reader connected to the user s PC. Such a smart card “based system, though offering exceptional security, is obviously not applicable for application to Web “service interactions. Fortunately, RSA s SecurID can be and is widely used very effectively by millions of users on a daily basis, without the use of this smart card system.

RSA s SecurID system, in general, works with a user-specific secret password and a token. The password is the factor that a user/application knows , while the token becomes the factor that the user has. The token is a time-synchronized code, which is periodically generated, typically every minute, starting with a unique seed code supplied by RSA. RSA can determine the validity of the token based on the time-sensitive code entered by the user. A valid token proves that the user has access to the factor he or she is supposed to hold. This token in effect becomes the equivalent of the magnetic stripe on an ATM card. To be successfully authenticated, a user/application has to enter this continually updated code (i.e., the token) and the user-specific secret password. RSA tokens can be generated by using RSA supplied software, which can be run on many different platforms. Obviously in a Web-service scenario it is important that this token-generation software and the user-specified passwords are safeguarded to ensure total security.

Since it is essentially an extension to normal password-based security schemes, applications can be modified to use two-factor authentication relatively easily and quickly. Typically a system administrator would have to enter a regularly changed password, as a seed, to activate the token-generation software. If this password is valid, the security software will automatically generate the token, append it to the entered password, and then send this combined key, suitably encrypted, to the security server for authentication. Despite its simplicity from an end-user perspective, two-factor authentication is obviously a significantly more powerful security scheme than a password-only (i.e., one-form) authentication scheme. Large and high-profile high-tech companies such as Cisco have been successfully using two-factor authentication, initially with hardware tokens but with a rapid transition to software tokens, since c. 1995 to partition and safeguard their employee-only intranet portals.

7.2.3 Secure Sockets Layer

SSL, or its successor TLS, should be considered a mandatory prerequisite technology for any Web service that deals with sensitive information. SSL, a client/server-based security mechanism developed by Web browser pioneer Netscape Communications in 1996, is the accepted and trusted basis for most of today s secure transactions across the Web. SSL is so widely used that it appears to be ubiquitous. It is supported by all popular commercial Web browsers and Web servers (e.g., Microsoft s Internet Information Server [IIS], the open software Apache Software Foundation s Apache HTTP Server, IBM s HTTP Server, etc.). In the context of Web servers it is used between a browser and the Web server. It can also easily be used in other scenarios ”in particular, application-to-application setups.

The little locked padlock icon that gets displayed at the bottom of a Web browser window whenever a secure transaction is being performed (e.g., credit card purchase or online stock trading) indicates that the security in force has been supplied via SSL technology. Figure 7.9 shows an example of the locked padlock icon indicating that SSL security is in force. Whenever the locked padlock icon is on display, the address field at the top of the browser showing the URL invoked is likely to say https://www. etc. etc., rather than http://www. etc. etc. The s following the HTTP denotes SSL ”in this case HTTP with SSL, or HTTP over SSL. HTTPS transactions are usually conducted across port number 443, while HTTP typically uses port 80. SSL, consequently, is not something new or rare. It is a scheme that most people have already encountered and have successfully used even without realizing that they were doing so. Ports 80 and 443 will typically also be the ports used by Web services if they are relying on SOAP over HTTP/HTTPS as their transport mechanism.

Figure 7.9: The locked padlock signifying a secure SSL connection ”in this instance, for online banking with the Meredith Village Savings Bank in New Hampshire ”along with a superimposed browser properties window showing that SSL 3.0 with encryption is in use.

SSL is a Transport Layer (i.e., Layer 4) protocol. As such it provides authentication, integrity, and data privacy for applications running above the TCP Layer (i.e., Layer 3). SSL supports digital certificates. Given its client/server orientation, SSL uses digital certificates to authenticate the server and the client ”in this case the application and the Web service it intends to invoke. This authentication process, which is achieved via what is referred to as an SSL handshake, typically requires a user ID/password exchange ”with the user ID and password being conveyed in encrypted mode with a public key. Following this authentication process, the SSL protocol sets about negotiating a common encryption scheme acceptable both to the client and the server. SSL does not do end-to-end data encryption.

Providing end-to-end client-to-server encryption was never a goal of the SSL protocol. There are well-established industry standards (e.g., 56-bit DES and 168-bit triple DES) and commercial ciphers (e.g., RSA) for enforcing end-to-end security. What SSL does is negotiate an encryption scheme acceptable both to the server and the client (e.g., triple DES) ”and then invoke this mutually accepted encryption scheme for encrypting the data flowing between the client and the server. Thus, the security services provided by SSL can be summarized as server authentication via digital certificates, optional client authentication with digital certificates, acceptable encryption scheme negotiation between the server and the client, and invoking the accepted encryption scheme to ensure that the data flowing between the client and the server is indeed encrypted and tamperproof on an end-to-end basis.

The latest version of SSL is called Transport Layer Security (TLS). The two terms will get used interchangeably in the future, with SSL most likely being used more often, even when TLS is being referred to, given its current popularity. Figure 7.10 provides a high-level schematic of how a secure SSL connection is established between a Web server and a browser user.

Figure 7.10: High-level view of the process involved in setting up a secure SSL connection between a Web server and a Web browser user. This process is the same for secure SSL connections between other client/server pairs, including an application and a Web service.

Related

Категории