Standards and strategies of security for the service oriented architecture
Sponsored Links
This presentation is the property of its rightful owner.
1 / 41

Standards and Strategies of Security for the Service Oriented Architecture PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Standards and Strategies of Security for the Service Oriented Architecture. Christopher Irish David Orr Sophya Kheim Adam Lange Daniel Palma. Agenda. Overview Current Problems Current Strategies WS Standards Future Areas of Research References Questions. Web Services Definition.

Download Presentation

Standards and Strategies of Security for the Service Oriented Architecture

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Standards and Strategiesof Security for the Service Oriented Architecture

Christopher Irish

David Orr

Sophya Kheim

Adam Lange

Daniel Palma


  • Overview

  • Current Problems

  • Current Strategies

  • WS Standards

  • Future Areas of Research

  • References

  • Questions

Web Services Definition

  • From World Wide Web Consortium (W3C)

    • is the programmatic interfaces made available for application to application communication

Types of Web Services


  • Key Concepts for Strategies

    • Authentication

    • Authorization

    • Integrity

    • Non-repudiation

    • Confidentiality

    • Privacy

Current Problems

  • SOAP monitoring and regulation

Current Strategies

  • IP Blocking

  • XML Firewall


  • Virtual Private Networks (VPN)

  • XML Digital Signature

  • WS-Security


  • SAML

IP Blocking

  • Process of identifying those IP addresses from which Web requests will be accepted

  • Achieved by specifying a list of acceptable IP addresses

  • Pros

    • Simple and easy to implement

  • Cons

    • Valid users with invalid IP addresses will be blocked

    • Clients will not be able to access any part of the Web site until you have added their IP to the accepted list

Traditional Firewalls

  • Filters out unauthorized requests by IP Address

  • Pros

    • Easy to implement and maintain

  • Cons

    • IP Address can be spoofed

    • Does not perform authentication, authorization, auditing and validation on web service traffic

    • Can not encrypt or decrypt

    • If web service uses Port 80, difficult to implement

    • Not XML aware

XML Firewalls

  • Filters out Unauthorized requests by inspecting XML content

  • Pros

    • Can perform authentication, authorization, auditing and validation on web service traffic

    • Protect against buffer overflows and denial of service

    • Message routing, encryption and forwarding are available

    • Includes features of traditional firewall

  • Cons

    • Difficult to setup

    • Limited vendors

    • No standardization


  • Endpoint to endpoint encryption of web service traffic over TCP

  • Pros

    • Easy to implement

    • Standardized protocols

    • Protects against network sniffing

  • Cons

    • Does not perform authentication, authorization, auditing and validation on web service traffic

    • Messages can not have multiple transports

    • No Element-Wise Signing

    • Data stored on disk before processing can not be protected

    • Not XML aware

Virtual Private Networks

  • Enables the creation of secure data tunnels among remote sites or hosts for web service traffic

  • Pros

    • Uses several technologies

    • Standardized protocols

      • Secure VPNs - IPSec, SSL/TLS, PPTP, L2TP

      • Trusted VPNs – MPLS, L2F

    • Easy to implement

    • Protects against network sniffing

    • Web service can join or leave dynamically

    • A web service can be invoked dynamically

    • Frees web service from managing access control, auditing and encryption

  • Cons

    • Does not perform validation on web service traffic

    • Data stored on disk before processing can not be protected

    • Not XML aware

XML Digital Signature

  • Provide

    • Authentication

    • Data Integrity

    • Non-repudiation support

  • Can sign many types of resources

    • HTML, binary, XML-encoded data

  • Can be applied to specific portions of XML tree rather than complete document

Web Services Standards

  • OASIS Web Services Security Standard

  • SAML


OASIS WS Security Standard

  • Developed by OASIS on April 29, 2004.

  • Revised and republished February 17, 2006 as version 1.1.

  • Currently the most comprehensive guide to Web Service security.

  • Main purpose is to allow the exchange of secure SOAP messages by protecting its confidentiality and integrity


  • Focuses on “Tokens” that are added to the SOAP messages to provide different kinds of security.

  • Is built to be extensible and flexible by allowing different types of token formats to be used in the same message.

WS-Security: Username Token

  • The username token provides a way for a sender to present a claimed identity to the receiver:

WS Security: Binary Security Tokens

  • Used to encode non-XML security token, like x.509 and kerberos.

e.g. x.509

Encoding Format

WS-Security: XML Signature

  • The WS-Security standard incorporates the use of XML signatures into SOAP messages

Begin signature

Reference to signature value

Algorithms used to form the signature

End signature

WS-Security: Timestamp

  • Allows the freshness of the security features to be determined. Time synchronization is not accounted for.

WS-Security: The big picture

WS-Security: The big picture cont.


  • Covers subjects such as authorization, access control, and privacy policies that is often overlooked in other standards.

  • XACML (Extensible Access Control Markup Language) is an XML-based policy language that allows for the description of access control requirements.


  • Request sent to Policy Enforcement Point (PEP).

  • the Policy Information Point (PIP), will use XACML to describe requestors in terms of attributes.

  • PDP actually makes the decisions.

  • Current policy is retrieved

  • Return response to the PEP and ultimately to the user.]


  • Uses “Assertions” to validity and authenticiy.

Service to Service Authentication

  • Verify if a service should be allowed to communicate with another

  • Authorization Methods:

    • Tokens

      • PK certificates

      • Kerberos tickets

      • SAML assertions

    • SSL certificates

  • Most web services follow the OASIS WS-Security standard for any of these methods

Establishing Trust Between Services

  • Trust relationships need to be established between remote web services in order to be useful on a large scale

  • Involves a Trusted Third Party (TTP)

  • Uses Public Key Infrastructure to pass keys through the TTP

Distributed Authorization and Access Management

  • Web Service Access Controls

    • Role-Based

    • Policy-Based

    • Risk-Adaptive

Role-Based Access Control

  • Associates a set of access privileges with a particular user role

  • Allows access based on membership in a group or by id

  • Simplifies security management by providing a role hierarchy

Role Based Example

Policy Based Access Control

  • Enforces strict environmental-level access control policies

  • Use notion of a Policy Authority

  • Focuses on automatically enforcing Mandatory Access Controls

Risk Adaptive Access Control

  • Access control decisions are based on a relative risk profile of the subject

  • Predefined policy rules aren’t as strictly enforced as role based

  • Requires real-time information to base risk assessment on with each authentication request

Enforcing Least Privilege Access

  • Users and services should never be given more than the minimum privileges needed to perform an operation

  • Give privileges only when needed

  • Relinquish privileges immediately upon completion

  • Divide complex functions into simple ones, with separate minimal required privilege for each function

End to End Accountability

  • Auditing essential to ensure operations/transactions occurred as expected

  • Dynamic services make it difficult to implement auditing

  • No auditing standard has been defined

  • Web Server logging most common


  • Simple Object Access Protocol

  • A SOAP message is fundamentally a one-way transmission between SOAP nodes, from a SOAP sender to a SOAP receiver, but SOAP messages are expected to be combined by applications to implement more complex interaction patterns ranging from request/response to multiple, back-and-forth "conversational" exchanges.

  • Pros

    • Powerful, can perform RPC.

    • Widespread industry support and acceptance

  • Cons

    • Tunnel’s through other protocols, circumventing security.

    • Application programmer responsible for protocol functionality.


  • Representational State Transfer

  • REST strictly refers to a collection of architectural principles. The term is also often used in a looser sense to describe any simple interface that uses XML (or YAML, JSON, plain text) over HTTP without an additional messaging layer such as SOAP.

Block Extensive Exchange ProtocolBEEP

  • DTD and XML aware generic application protocol kernel for connection-oriented asynchronous interactions (web services) using Simple Authentication and Security Layer for authentication and authorization

  • Pros

    • Very extensible and simple

    • Built in profiles for security

    • Provides single application user-identity

    • Gaining popularity

    • Implements standardized technologies

    • Sits at transport layer

  • Cons

    • Limited support

    • Development costs can be expensive

    • Can become complicated quickly

Future areas of research

  • Focus on standardization

  • Performance of Web Services security mechanisms

  • Scale of Web Services security

Future Areas of Research cont..

  • Possible future configuration of a web services security system in which an XML Firewall and EASI framework are both implemented together


  • Overview

  • Current Problems

  • Current Strategies

  • New Strategies

  • WS Standards including OASIS, SAML, XACML

  • References


  • Login