Secure Web Services


" Security is wholesome its either full or null "

Security is a key factor for companies in adopting Web Services in their mission critical business transactions. Without security cared, companies could not use Web Services in the insecure Internet environment. The loose coupling of services - the Web Services ’ emblem - can play an active part in this insecure environment.

To secure Web Services, standard bodies such as World Wide Web Consortium (W3C), Organization for the Advancement of Structured Information Standards (OASIS), The Liberty Alliance,and others are developing XML-based security standards.

WS-Security and its family seem to be becoming parts of these standards. WS-Security defines a message security model and is designed to be so generic and composable to meet every existing security mechanism. Exploiting required portions from specifications like WS-Security family and composing them is, however, not easy. One of the reasons is that there are quite many choices, especially when designing the countermeasures, while it is unclear what to choose and how to use and/or implement them. To solve this problem, this post describes best practices for securing Web Services application using WS-Security

I abstract “idioms ” in WS-Security implementation and gives best practical combination patterns of these implementation idioms for protecting Web Service messaging from security threats.

Since a combination corresponds to a threat, given a threat, it is simple to pick up combinations with which systems are protected from the threat.

This post focus only on the messaging part of the WS-Security family though there are the policy part (WS-Policy, WS-Trust and WS-Privacy), and the federation part (WS-SecureConversation,WS-Federation and WS-Authorization) on top of the messaging part (WS-Security) in the protocol family.

SECURE WEB SERVICES

The family of WS-Security specifications is critical to secure cross-organization Web services. These specifications support authentication and message integrity, confidentiality, trust, and privacy. They also support federation of security between different organizations.

WS-Security Protocol Family

The WS-Security protocol family defines various facets of security for Web Services. Figure 1 shows the protocol stack of WS-Security related protocols. First, on top of the SOAP messaging protocol , WS-Security is the foundation of the protocol family and defines the dynamic model for securing Web Service messaging. The next layer of the stack consists of three security policy specifications: WS-Policy , WS-Trust and WS-Privacy.


The third layer supports federated security through three specifications: WS-SecureConversation , WS-Federation and WS-Authorization.

WS-Security

WS-Security is the basic building block for secure Web services. Today, most distributed Web services rely on transport level support for security functions. Examples are HTTP/S and BASIC-Auth authentication. These approaches to security provide the minimum necessary for secure communication. The level of function they provide, however, is significantly less than that provided by existing middleware and distributed environments.

Two examples highlight the deficiencies of BASIC-Auth and HTTP/S. Alice sends a message to service Bob. Bob partially processes the messages and forwards it to service Carol.

HTTP/S allows authentication, confidentiality and integrity between Alice-Bob and Bob-Carol. However, Carol and Alice cannot authenticate each other, or hide information from Bob. For Alice, Bob and Carol have to use BASIC-Auth for authentication. They must share the same replicated user and password information. This is unacceptable in many scenarios.

WS-Security solves these problems. It supports:

  1. Signed, encrypted security tokens. Alice can generate a token that Carol can verify as having come from Alice. Bob cannot forge the token.

  2. Alice can sign selected elements or the entire message. This allows Bob and Carol to confirm that the message has not changed since Alice sent it.

  3. Alice can seal the message or selected elements. This ensures that only the intended service for those elements can use the information. This prevents Bob from seeing information intended for Carol and vice-versa.

    WS-Security uses existing security models (Kerberos, X509, etc). The specifications concretely define how to use the existing models in an interoperable way. Multi-hop, multi-party Web service computations cannot be secure without WS-Security.


WS-Policy

WS-Policy enables a service to specify what it expects of callers and how it implements its interface. WS-Policy is critical to achieve interoperability at the higher-level functional operation of the service. From the security view point, WS-Policy allows services to describe the security assurance that they expect from and provide to callers. The WS-Policy framework provides a base model for defining policy expressions. It supports a grammar for aggregating policy statements and allows the construction of flexible and complete sets of security policy.

WS TRUST

Security relies on predefined trust relstionships. WS-Trust defines an extensible model for setting up and verifying the relationships. The key concept is WS-Trust is a Security Token Service (STS). An STS is a distinguished Web service that issues, exchanges and validates security tokens. WS-Trust allows Web services to set up and agree on which security servers they “trust,” and to rely on these servers.

WS-SecureConversation

WS-SecureConversation defines exchange of keys shared among web services. It uses public keys to perform a simple negotiation that defines conversation specific keys since sending many messages using the same cryptographic keys allows brute force attacks to “break the code.” This key exchange allows more efficient security implementations and also decreases the amount of information encrypted with a specific set of keys. Participants often use WS-Security with public keys to start a “conversation” or “session,” and use WS-SecureConversation to agree on session specific keys for signing and encrypting information.

WS-Federation

WS-Federation allows a set of organizations to establish a single, virtual security domain. For example, a travel agent, an airline and a hotel chain may set up such a federation. An end-user that “logs into” any member of the federation has effectively logged into all of the members. WS-Federation defines several models for providing federated security through protocols between WS-Trust and WS-SecureConversation topologies.

Additionally customers often have “properties” when they deal with an enterprise. An example is a preference for window or aisle seats, or a midsize car. WS-Federation allows the members to set up a federated property space. This allows each participant to have secure controlled access to each member’s property information about the end-users. Properties and information about individuals may be closely held for privacy protection or because the information provides a competitive advantage to a specific member. To support these  equirements, WS-Federation supports a pseudonym model. Users that have authenticated to the travel agency have agency generated “aliases” in their interactions with the airline or hotel. This protects the privacy of the end-user and the competitive advantage that the travel agency may gain by knowing user properties.

This protects the privacy of the end-user and the competitive advantage
that the travel agency may gain by knowing user properties.

Towards Secure Web Services

It is said that security is a process, not a product. That is because
security is provided by iterating the following steps:

  1. Identify resources to protect, assess their value, identify threats to them, and assess their damage if the threats are realized.
  2. Decide whether the risk is accepted, and if not, describe the policy
    required to protect the resources from the threats.
  3. Design countermeasures that enforce the policy, including protection,
    detection, and reaction mechanisms to attacks.
  4. Evaluate the effect of the countermeasures.








If this model works, that would be great. However, the model is too abstract to follow, and practice is not that straightforward. One of the reasons is that there are quite many choices, especially when designing the countermeasures, while it is unclear what to choose and how to use and/or implement them. To solve this problem, we believe that a pattern approach works well. In this post, I mainly focused on Web Services messaging and try to secure it, where we should encounter the same problem as is described above. Even though there is a preceding work for architectural patterns for secure application software , we need more comprehensive sets of patterns. Providing a comprehensive set of secure patterns for generic software systems requires hard work. Instead, we address in the specific domain of Web Services.

IDIOMS IN WS-SECURITY

Before pigeonholing best practice for securing Web Service messaging, it is better to abstract from somewhat confused protocol specifications and
define common notions for representing the functional features defined in the specifications. Each idiom is just a building block and does not provide a complete solution. By combining some of the idioms, secure messaging is implemented.

Protection by Lower Layer (PRO-LL)
Protect a channel between a sender and a receiver using security protocols provided by lower layers, such as SSL/TLS provided by the transport layer and IPSec provided by the network layer. The sender is either an initial sender or an intermediary. The receiver is either an intermediary or an ultimate receiver.

Note: though some protocols, such as SSL/TLS and HTTP, provide authentication mechanisms, we don’t assume them at this point for simplicity.

Threats: eavesdropping, falsification, masquerade

Encryption for Receiver (ENC-R)
Encrypt a message using a receiver’s key. The receiver is either an
intermediary or an ultimate receiver. The key may be obtained beforehand or when sending the message. If the key is of type public key, it is obtained from security token services (STSs) using
WS-Trust. If the key is of type secret key, it is exchanged with the receiver using WS-SecureConversation.The message is encrypted using WS-Security.

Threats: eavesdropping, masquerade




Encryption for Ultimate Receiver (ENCUR)
Encrypt a message with an ultimate receiver’s key. How to obtain the key and how to encrypt the message are the same as those in the ENC-R idiom.

Threats: eavesdropping, masquerade


Digital Signature by Sender (DSIG-S)
Attach a digital signature to a message using a sender’s private key. The sender is either an initial sender or an intermediary. The digital signature is attached using WS-Security.

Threats: falsification

MAC by Sender (MAC-S)
Attach a message authentication code (MAC) to a message using a sender’s
secret key. The sender is either an initial sender or an
intermediary. The key needs to be shared with a receiver.
The
key is exchanged between the sender and the receiver using
WS-SecureConversation. The key may be exchanged beforehand or when
sending the message. The MAC is attached using WSSecurity.

Threats: falsification

Digital Signature by Initial Sender (DSIGIS)
Attach a digital signature to a message using an initial sender’s private key. How to attach the digital signature is the same as that in the DSIG-S idiom.

Threats: falsification, masquerade, repudiation

MAC by Initial Sender (MAC-IS)
Attach a MAC to a message using an initial sender’s secret key. The key
needs to be shared with a receiver. How to exchange the key and how to attach the MAC are the same as those in the MAC-S idiom.

Threats: falsification, masquerade


Password of Initial Sender (PASS-IS)
Attach an initial sender’s username and password to a message.The pair of username and password is attached using WS-Security.

Threats: masquerade

Password of Proxy (PASS-P)
Attach an initial sender’s username and a proxy ’s username and password
to a message. The proxy attaches his username and password only if he
authenticates the initial sender in some ways. The username and the
pair of username and password are attached using WS-Security.

Threats: masquerade


Digital Signature by Proxy (DSIG-P)
Attach an initial sender’s username and a digital signature on the
username using a proxy ’s private key. The proxy attaches the
digital signature only if he authenticates the initial sender in some
ways. The username and the digital signature are attached using
WS-Security.


Threats: masquerade

MAC by Proxy (MAC-P)
Attach an initial sender’s username and a MAC on the username using a
proxy’s secret key. The key needs to be shared with a receiver. How to exchange the key is the same as that in the MAC-S idiom. The proxy
attaches the MAC only if he authenticates the initial sender in some
ways. The username and the MAC are attached using WS-Security.

Threats : masquerade

Security Token of Initial Sender (ST-IS)
Attach an initial sender’s security token issued by a STS. The STS issues
the security token only if it authenticates the initial sender in
some ways. The security token is issued using WS-Trust. WS-Federation
may be used as well. The security token is attached using
WS-Security.

Threat: masquerade

Nonce (NONCE)
Attach a nonce to a message. The nonce may be attached to a message ’s
part being processed, or if a digital signature or a MAC is
attached, to a manifest of the digital signature or the MAC. The
nonce can be attached using WS-Security if the data is a pair of
username and password or a username only, or a timestamp is used as
nonce.

Threats: masquerade, repudiation

Because in Web Services, there can be one or more intermediaries between an
initial sender and an ultimate receiver, not only third parties but
intermediaries may be considered as attackers. We assume two cases;
a case where only the third parties are attackers and the other case
where both the third parties and the intermediaries are attackers,
and present protection patterns in each case.


Encrypted Message
Synopsis: Provide confidential message content.

Context : Threat:
eavesdropping
Solution: Make it impossible for attackers to get or read any message content by
encrypting it and carries an encrypted message instead of the
original message.

Assumed attackers: third parties
· ET1: PRO-LL
· ET2: ENC-R
Assumed attackers: third parties and intermediaries
· EI1: ENC-UR


Signed Message
Synopsis: Provide a message with integrity.
Context : Threat: falsification
Solution: Make it impossible for attackers to get any messages by some way, or make it possible for the receiver to detect any changes on the messages by attaching digital signatures to a message.

Assumed attackers: third parties
· ST1: PRO-LL
· ST2: DSIG-S
· ST3: MAC-S
Assumed attackers: third parties and intermediaries
· SI1: DSIG-IS
· SI2: MAC-IS


Message with Authentication
Synopsis : Provide authenticated message source.


Context : Threat: masquerade
Solution: Perform authentication and make it impossible for attackers to get or reuse
any authentication information.


Assumed attackers: third parties

· AT1: PASS-IS, PRO-LL
· AT2: PASS-P, PRO-LL
· AT3: PASS-IS, NONCE, ENC-R
· AT4: PASS-P, NONCE, ENC-R
· AT5: DSIG-IS, NONCE
· AT6: MAC-IS, NONCE
· AT7: DSIG-P, NONCE
· AT8: MAC-P, NONCE
· AT9: DSIG-IS, PRO-LL
· AT10: MAC-IS, PRO-LL
· AT11: DSIG-P, PRO-LL
· AT12: MAC-P, PRO-LL
· AT13: ST-IS
· AT14: ST-IS, PRO-LL
Assumed attackers: third parties and intermediaries
· AI1: PASS-IS, NONCE, ENC-UR
· AI2: PASS-P, NONCE, ENC-UR
· AI3: DSIG-IS, NONCE
· AI4: MAC-IS, NONCE
· AI5: DSIG-P, NONCE
· AI6: MAC-P, NONCE
· AI7: ST-IS


Note: there are two ways to validate authentication information; by myself
and by a proxy. In the latter case, validation is requested using
WS-Trust. Validation may be done using WSFederation as well.
Validation on gateways can be regarded as a variation of this case.


Signed Message with Nonce
Synopsis :  Provide a non-repudiated message.
Context: Threat: repudiation
Solution: Add versions for every message to be sent and attach digital signatures
to messages using a private key.


Assumed attackers: third parties
· NT1: DSIG-IS, NONCE
· NT2: DSIG-IS, PRO-LL
Assumed attackers: third parties and intermediaries
· NI1: DSIG-IS, NONCE


Mappings between threats and implementation variations are shown in Table 1
and Table 2, where only third parties and both third parties and
intermediaries are assumed as attackers, respectively.


From the tables, we can see what variation to use to solve each threat. We
can also see what variations to combine to solve some of the threats
efficiently. For example, suppose we want to solve all the threats from both third parties and intermediaries. Using the NI1 variation, we can solve
repudiation as well as falsification and masquerade because that
variation is constructed from the DSIG-IS idiom and the NONCE idiom,
and from those idioms, the SI1 variation and the AI3 variation are
constructed. Therefore, using the NI1 variation in combination with
the EI1 variation, we can solve all the threats.


Table 1 and Table 2 are useful to find and analyze combinations of
variations that meet security requirements.

Not Covered in Post

Aspects other than secure messaging should be considered, other parts of the
WSSecurity protocol family are more important for secure Web Service
applications.

The policy part consists of WS-Policy, WS-Trust and WSPrivacy, and the
federation part consists of WSSecureConversation, WS-Federation and
WS-Authorization, in the WS-Security protocol family. Moreover, since
the protocols are growing and increasing, coming protocols should be
considered.

Tool Support

One of the main goals of this post is to provide a tool which generates
precise policies for Web Services according to given higher-level
security policies .

When securing a system, one first need to define a policy for the security
of the system. By balancing risks and rewards, what/how to protect,
that is a policy, is defined. According to the policy, system
developers implement/configure secure Web Service applications. They
can use the patterns presented in this paper at this stage. To make
the system meet requirements defined in the policy, they should pick
appropriate patterns and apply them to their system.

This might extend this to a semi-automated tool . Given some policies and
conditions as parameters, the tool should generate WS-Policy
descriptions for WS-Security and system-specific security
configurations appropriate to the underlying systems, such as
application servers.


blogs.sun.com/narayanaa/resource/1.gif" name="graphics1" />
Table 2 : Mapping between threats and implementation variations for third
party or intermediary attackers
EVD = Eavesdropping
FAL = Falsification
MAS = Masquerade
REP = Repudiation


blogs.sun.com/narayanaa/resource/2.gif" name="graphics2" />

Tabel 1:Mapping between threats and implementation variations for third
party or intermediary attackers
EVD = Eavesdropping
FAL = Falsification
MAS = Masquerade
REP = Repudiation





Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

I was part of Sun R&D in Java CAPS and later Glassfish ESB. I moved from R&D to Consulting. I am currently working as a Solution Architect in Oracle Consulting Services (India). I was sharing my experience w.r.t. Java CAPS and other technologies during Sun period. Now in Oracle world I share my experiences with Oracle FMW product line as well as other Oracle Technologies and products.

Search

Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today