Security Patterns for Web Services

1
Security Patterns for Web Services

• 02/03/05
• Nelly A. Delessy

2
Pattern Language
3
XML Firewall

• Intent To filter XML messages to/from enterprise
  applications, based on business access control
  policies and the content of the message.
• Context Enterprise applications executing in
  distributed systems accessed through a local
  network, from the Internet, or from external
  networks.
• Problem Some enterprise applications use
  tunneling into authorized flows (HTTP, SMTP,) to
  communicate with the outside. They use higher
  level protocols such as SOAP and communicate
  through XML documents or XML-wrapped remote
  procedure calls. The XML content of these
  messages can contain harmful data and can be used
  to perform attacks against applications.Network
  firewalls provide infrastructure security but
  become useless when these high level protocols
  and formats are used.

4
XML Firewall
5
XML Firewall

• advantages higher level of security than the
  Application Firewall for inputs which are XML
  documents or requests.
• liabilities
• bottleneck in the network
• intrusive for existing applications that already
  implement their own access control or their own
  filtering.
• The application firewall needs to manage the
  corresponding cryptographic keys necessary to
  encrypt/decrypt data, or verify digital
  signatures.

6
Multiple Agent

• Intent To enforce an organizations security
  policies for every valuable resource of the
  computer system (applications, hosts,
  subnetworks).
• Context Computer systems logically consisting of
  several applications executing on various hosts
  and partitioned in subnetworks. The applications
  are executing in distributed systems and are
  accessed from the local subnetwork, the Internet,
  or other subnetworks.
• Problem It is crucial that these security
  policies are enforced throughout the computer
  system. A Security Reverse Proxy can enforce
  access security policies at the boundaries of a
  subnetwork, by typically filtering requests going
  through it. But each application and each host
  may be accessed through internal networks and a
  reverse proxy could not be sufficient to block
  attacks coming from them. Besides, how do we
  enforce other types of security policies?

7
Multiple Agent
Resource
Client
accesses



1

Application Level
Implementation Level
Policy Referential

uses

enforcesPolicyOn
Support Agent
Enforcement Agent
1
Security Agent

protects
accessesThrough
Security Multiple Agents System


8
Multiple Agent

• Advantages
• The solution is non-intrusive for the computer
  system.
• The security checks can be applied to a variety
  of specific technologies by the means of
  specialized agents. The solution is flexible.
• The enforcement system is separated from the
  referential for the business policies. Thus a
  change in business policies wont affect the
  enforcement of these policies.
• The security checks wont create a bottleneck in
  the network.
• Computer System is more secure, as the
  application is protected from the calls coming
  from all internal networks.
• Liabilities
• The number and the variety of agents necessary
  may make the system expensive to develop, deploy,
  and administrate.
• The system is not scalable, as for each new
  object to be protected, we need to add a new
  agent.

9
Trust Negotiation

• Intent To establish a trust relationship between
  a consumer and a web service.
• Context Consumers use automatic service
  discovery to access a web service.
• Problem The service or the consumer could both
  be malicious. How is it decided whether or not
  the consumer should access the web service?
• Forces
• The identity of the consumers may not be known in
  advance by the web service.
• The security policies of the user and the web
  service could be expressed in different ways.

10
Trust Negotiation
11
Trust Negotiation

• Consequences
• Consumers do not need to be identified to access
  a web service.
• A variety of policies could be processed.
• Known uses
• WSPL
• WS- Policy ??

12
Federation

• Intent To realize propagation of the trust among
  separate web services.
• Context A set of web services in different
  security domains are accessed by a variety of
  consumers.
• Problem A consumer could be malicious. How can
  he be authenticated or authorized to access a
  service whereas he is not known in the security
  domain?
• Forces
• The identity of the consumers may not be known in
  advance by some of the web services.
• A consumer may have used several other web
  services

13
Federation

• Add OCL constraints A user must be trusted by at
  least one web service

14
Federation

• Consequences
• Consumers do not need to be identified to access
  a web service.
• A trust relationship must exist between the web
  services.
• Known uses
• Liberty
• WS- Federation

15
Confidential Message 1

• Intent
• Provide a confidential message.
• Context
• Threat eavesdropping
• Solution
• Make it impossible for attackers to get or read
  any message content by encrypting it and
  transmitting an encrypted message instead of the
  original message.
• Implementation Options
• SSL or XML ENCRYPTION

16
Message with Integrity1

• Intent
• Provide a message with integrity.
• Context
• Threat falsification
• Solution
• Make it impossible for attackers to get any
  messages, or make it possible for the receiver to
  detect any changes to the messages by attaching
  digital signatures to a message.
• Implementation Options
• SSL, DSIG or MAC

17
Authenticated Message Source 1

• Intent
• Authenticate the message source.
• Context
• Threat masquerade
• Solution
• Perform authentication and make it impossible for
  attackers to get or reuse any authentication
  information.
• Implementation Options
• PASS SSL , PASS NONCE ENC, DSIG NONCE,
  MAC NONCE, DSIG SSL or MAC SSL

18
Non-Repudiated Message1

• Intent
• Provide a message that cannot be repudiated.
• Context
• Threat repudiation
• Solution
• Add versions for every message to be sent and
  attach digital signatures to messages using a
  private key.
• Implementation Options
• DSIG NONCE or DSIG SSL

19
References

• 1 M. Tatsubori, T. Imamura, Y. Nakamura,
  "Best-Practice Patterns and Tool Support for
  Configuring Secure Web Services Messaging,"
  Proceedings of the IEEE International Conference
  on Web Services (ICWS04)
• 2 "Security in a Web Services World A Proposed
  Architecture and Roadmap," Apr 7, 2002.
• 3 H. Skogsrud, B. Benatallah, F. Casati,
  "TrustServ Model-Driven Lifecycle Management of
  Trust Negotiation Policies for Web Services"