Home arrow Security arrow Page 6 - Basic Concepts of Web Services Security

Security Concepts and Definitions - Security

Today we cover the basics of Web services and information security and the way Web services security builds on existing security technology. This is chapter 1 from Securing Web Services with WS-Security, by Rosenberg and Remy (ISBN 0672326515, Sams, 2004).

  1. Basic Concepts of Web Services Security
  2. XML, SOAP, and WSDL
  3. UDDI
  4. Security Basics
  5. Shared Key and Public Key Technologies
  6. Security Concepts and Definitions
  7. Web Services Security Basics
  8. Summary
  9. Footnotes
By: Sams Publishing
Rating: starstarstarstarstar / 10
October 04, 2004

print this article



Authentication, authorization, integrity, confidentiality, and non-repudiation are critical concepts for your understanding of Web services security, so the following sections provide a bit more detail on each one.


Authentication involves comparing provided identity information (a "challenge") to something already stored about this individual. Authentication is classically divided into three types: something you know, something you have, or something you are:

  • Something you know—Pin, password, pass phrase, shared secret

  • Something you have—Key, card, token

  • Something you are—Biometrics such as fingerprint, retinal scan, voice print, palm print

Single-factor authentication (using just one of the preceding types) is the simplest but is not very strong. Stealing or guessing a password is easy, and the rightful individual has no way to refute this is the case. Furthermore, because a password is something you know, you can tell it to someone or she can guess it, and with no other factor checked, that person is into the system with nothing stopping her.

Two-factor authentication, also known as strong authentication, is much stronger and is considered the standard when authentication is for anything of high value. Either something you have or something you are is added to the something you know category of shared secret. Something you have is typically a card, token, or device of some sort. Something you are is a biometric such as a fingerprint, retinal scan, or voice print. Outside military applications, authentication stronger than two-factor is rarely found. To strengthen two-factor authentication, you must strengthen the process used to create the individual factors.

How rigorous the authentication needs to be and what types of factors should be used in the one-, two-, or more factors of authentication require that you think about the level of trust needed. What is it that you are trying to protect? If the Web service is one that integrates vendors into your supply chain, and they have no access to critical corporate or customer data, the level of authentication may be lower than for a Web service that integrates an employer to its 401k provider and represents an employee requesting fund reallocation.


Authorization is the process of establishing what someone who has been authenticated is allowed to do. The entity receiving the request for service will be granting permissions for each identity to access certain items.

Most Web services coming in over the public network to an enterprise require authentication; it is not usually acceptable to provide services that you expect to be paid for without knowing who is using them. So fundamentally, authorization requires authentication. Additionally, Web services frequently expose vital business data to the requestor, who must be identified and not remain anonymous. Exceptions to this rule are free services that do not care who use them. If a service provides different levels of access depending on who is using it, that service also requires authorization to determine, based on identity, what services are accessible to whom.

One way that authorization is implemented is through a set of credentials that a subject identity carries and presents; those credentials are then mapped into access to certain restricted items. Alternatively, rights can be attached to restricted content, and these rights are mapped to identities and the permissions they will be granted to this content.

On the HTML-based Web, authorization has typically been very coarse grained and either gives access to entire sections of a Web site or denies access completely. With Web services, on the other hand, very fine-grained control specifying access to messages, parts of messages, or content carried by a message is possible. Unlike many security concepts, authorization is actually very easy to understand, but it turns out to be exceedingly complex technologically as well as socially. You will see why in Chapter 6, "Portable Identify, Authentication, and Authorization," which discusses standards such as SAML that are involved with this aspect of identity.


Integrity is an assertion that no one has tampered with a message since it was initially created. This assures the sender and the receiver that every bit produced by the sender is received by the recipient in precisely unaltered form. In cryptographic terms, data integrity is accomplished by using digital signatures. Messages in which data integrity is required (Footnote 7) must explicitly or implicitly include the identity and credentials of the sender to enable this kind of message-level security. Why? Because proving integrity means proving no bits have been changed in the message, which involves sending something with the message that no one in the middle could fraudulently create. That, in turn, requires signing that data with a key that only the sender could have had (more on this in Chapter 4, "Safeguarding the Identity and Integrity of XML Messages"). Message integrity- and identity-related issues (authentication and authorization) are often inter-related. Ironically, no matter how sophisticated your security technology becomes, the core security issue comes down to this: Do you know whom you are dealing with and do you trust those people?


Confidentiality is keeping the message secret. This process requires encryption, which scrambles the message in such a way that only authorized identities can decrypt and see the data. To do this, you exchange a shared secret and an algorithm for encrypting and decrypting the message. You could imagine Bob and Alice agreeing that they were going to encrypt their messages to each other by adding some number to each letter in the alphabet (the algorithm) and that number would be 2 for the next five days (the key). Thus, the message from Bob to Alice would look scrambled to a reader, and even if you knew the algorithm, you would have to do some analysis (not much in this case) to figure out how to decode the message. In the real world, these algorithms are very challenging mathematical functions with keys that are very large numbers, and the time to do the analysis is technically infeasible even with modern computers.

With typical contemporary encryption strategies, you provide the algorithm openly and rely on the strength of the key to keep the encryption secure. The trick is keeping the key secret. You could keep the key secret by giving it to the recipients in some way outside the message exchange, such as mailing it to them or phoning them. However, this approach doesn't scale up very well to large numbers of participants, so exchanging this key usually requires Public Key Infrastructure (PKI) technology, which is designed to manage and exchange keys. Chapter 3, "The Foundations of Distributed Message-Level Security," describes PKI in more detail, and Chapter 5, "Ensuring Confidentiality of XML Messages," goes into a lot of detail about encryption, specifically XML Encryption.


As digital transactions are used in more and more legal contracts and as the acceptability of digital signatures becomes commonplace, the legal aspects of identity will become critical for Web services. First and foremost among those legal aspects of identity is non-repudiation.

Non-repudiation proves that one identity sent the data only to another identity. This then proves that this specific transaction was entered into by the recipient, and neither party can refute or deny that it occurred later. If the transaction is challenged legally, a contract that was supposedly executed must be shown to have been entered into by both parties. Each party must have seen the contract as signed, and their identities—confirmed traditionally by validating "wet" signatures on paper and notary witnesses—must have been confirmed at the time of signing. These are difficult, and as yet legally unchallenged, tenants to uphold in a digital and anonymous world, but that day is coming.

Non-repudiation depends on public key cryptography technology. You prove that one identity sent the data only to another identity because the sender used the recipient's public key, and it is only the recipient with his secret private key who can decrypt the data. To achieve legal non-repudiation, more is needed, such as a separate time-and-date-stamp notary to prove when the transaction occurred as well as independent verification of the participants' identities.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

>>> More Security Articles          >>> More By Sams Publishing

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Secure Your Business for Data Privacy Day
- Google Testing Security Fob Password Alterna...
- Security News Highlights Concerns
- Going to Extremes for Data Security
- Skipfish Website Vulnerability Scanner
- Critical Microsoft Visual Studio Security Pa...
- US Faces Tech Security Expert Deficit
- LAN Reconnaissance
- An Epilogue to Cryptography
- A Sequel to Cryptography
- An Introduction to Cryptography
- Security Overview
- Network Security Assessment
- Firewalls
- What’s behind the curtain? Part II

Developer Shed Affiliates


Dev Shed Tutorial Topics: