Security for Web Services and Service Oriented Architectures

1
Security for Web Services and Service Oriented
Architectures
Bhavani Thuraisingham The University of Texas at
Dallas Lecture 4
2
Acknowledgement

• Professors Elisa Bertino and Lorenzo Martino
  Purdue University for much of the information and
  charts on web services security standards and
  digital identity management
• bertino_at_cs.purdue.edu
• lmartino_at_purdue.edu
• Others
• Dr. Frederica Pacci University of Milan for
  ideas obtianed when serving on her thesis
  committee on reserach in web services security
• Prof. I-Ling Yen and Wei-She University of Texas
  at Dallas for collaboration on web services
  security and the delegation model
• Book by Thomas Erl on Service Oriented
  Architectures, Prentice Hall, 2005

3
Objective and Scope

• The objective of this course is to provide an
  overview of the significant developments in SOA
  and Web Services Security Standards as well as
  directions for future developments
• Current work on SOA security is focusing mainly
  on access control as well as confidentiality and
  integrity.
• Solutions proposed for systems to address
  intrusion detection, denial of service and
  infrastructure attacks, insider threat analysis
  including data mining techniques for security
  applications are beyond the scope of this course.
  

4
Outline

• SOA and Web services Overview
• SOA and Web services security Overview
• WS-Security and WS- Security

5
Service Oriented Architecture (SOA)
http//en.wikipedia.org/wiki/Service-oriented_arc
hitecture

• Service Oriented Architecture (SOA) is an
  architectural style that guides all aspects of
  creating and using business processes, packaged
  as services, throughout their lifecycle, as well
  as defining and provisioning the IT
  infrastructure that allows different applications
  to exchange data and participate in business
  processes loosely coupled from the operating
  systems and programming languages underlying
  those applications
• SOA represents a model in which functionality is
  decomposed into distinct units (services), which
  can be distributed over a network and can be
  combined together and reused to create business
  applications
• These services communicate with each other by
  passing data from one service to another, or by
  coordinating an activity between two or more
  services.
• SOA concepts makes software development flexible
  and extensible
• Service oriented analysis is becoming key to
  modeling and analyzing software
• The concepts of Service Oriented Architecture are
  often seen as built upon, and the evolution of,
  the older concepts of distributed computing and
  modular programming
• While object-orientation views the world as a
  collection of objects, service orientation views
  the world as a collection of services
• SOA is technology independent however it is
  commonly realized using web services

6
Web service definition

• A Web Service is a software system designed to
  support interoperable machine-to-machine
  interaction over a network. It has an interface
  described in a machine-processable format
  (specifically WSDL). Other systems interact with
  the Web service in a manner prescribed by its
  description using SOAP messages, typically
  conveyed using HTTP with an XML serialization in
  conjunction with other Web-related standards.
• Source http//www.w3.org/TR/ws-arch/

7
SOA
8
Web Services (WS) Framework

• An abstract (vendor neutral) existence defined by
  standards organizations and implemented by
  (proprietary) technology platforms
• Core building blocks that include web sercices,
  service descriptions and messages
• A communication agreement centered around service
  descriptions and WSDL
• A messaging framework comprised of SOAP
  technology concepts
• A service description registration and discovery
  architecture sometimes realized through UDDI
• A well defined architecture that supports
  messaging patterns and compositions
• A second generation of web services extensions
  (also known as WS- specifications) continually
  broadening its underlying feature-set
• Concepts in WS- include Message Exchange
  Patterns (MEP), Service Activity, Coordination,
  Atomic Transaction, Business Activities,
  Orchestration (WS-BPEL), Choreography (WS-CDL)
• Reference Service Oriented Architecture, Thomas
  Erl, Prentice Hall, 2005

9
Standardization bodies related to Web Services
10
SOA Security

• Our approach is to implement SOA through web
  services therefore SOA security essentially is
  about web services security
• Three core specifications
• WS-Security, XML-Signature, XML-Encryption
• WS-Security is the second generation of
  technologies for SOA security
• Single sign-on (SSO) is a form of centralized
  security mechanism that complements the
  WS-Security extensions
• Related specifications for SOA security
• WS-Security, WS-SecurityPolicy, WS-Trust,
  
  WS-SecureConversation, WS-Federation, XACML,
  Extensibe Rights Markup Language, XML Key
  Management, XML, Signature, SAML, .NET Passport,
  Secure Socket Layer, WS-I Basic Security Profile

11
Basic Components of SOA Security

• Identification
• For service requestor to acces a secure service
  provider it must first provide information that
  expresses its origin or owner. This is referred
  to as making a claim
• Authentiaction
• A message being delivered to a receipient must
  prove that the message is in fact from the sender
  that it claims
• Authorization
• Once authenticated, the receipient of a message
  may need to determine what the requestor is
  alowed to do
• Singe sign on
• It is supported by SAML, .NET Passport and XACML
• Confidentiality and Integrity
• Confidentiality is concerned with protecting the
  privacy of the message content, Integrity ensures
  that the message has not been altered
• Transport level and Message level security
• Transport level securiy is provided by SSL
  (securing HTTP), message level confidentiality
  and integrity are provied by XML-Encryption and
  XML-Signature.

12
Web Services Security Requirements and Standards

• Securing Web services mainly requires to
• provide facilities for securing the integrity and
  confidentiality of the messages and
• ensure that the service acts only on requests in
  messages that express the claims required by
  policies
• Role of Standards
• Providing a Web Services Security Framework that
  is an integral part of the Web Services
  Architecture
• The framework is a layered and composable set of
  standard specifications

13
WS- security Standards framework
14
WS- security standards implementations

• Microsoft .NET Framework 2.0 / WSE3.0
• WS-Security (OASIS 2004 standard), WS-Policy,
  WS-SecurityPolicy, WS-Trust, WS-SecureConversation
  and WS-Addressing
• SUN Web Services Interoperability Technology
  (WSIT)
• IBM WebSphere
• Open Software The Apache Software Foundation Web
  Services Project (http//ws.apache.org/)

15
Securing the network traffic SSL/TLS and IPsec

• Secure Socket Layer SSL and Transport Layer
  Security are used to provide transport level
  security for web services applications.
• Security features
• authentication
• data integrity
• data confidentiality
• SSL/TLS enables point-to-point secure sessions.
• IP security (IPsec) security features
• secure sessions with host authentication
• data integrity
• data confidentiality

16
XML Encryption

• XML Encryption Syntax and Processing
• 10 December 2002
• Status W3C Recommendation
• Core standard
• Goals
• provide confidentiality for applications that
  exchange structured data by
• Representing in a standard way digitally
  encrypted resources
• separating encryption information from encrypted
  data, and supporting reference mechanisms for
  addressing encryption information from encrypted
  data sections and vice-versa
• providing a mechanism for conveying encryption
  key information to a recipient
• providing for the encryption of a part or
  totality of an XML document

17
XML Signature

• XML-Signature Syntax and Processing
• 12 February 2002
• Status W3C Recommendation
• Core standard XML Signature is a building block
  for many web services security standards (e.g.
  XKMS and WS-Security)
• Goals
• represent a digital signature as an XML element
• Processing rules for creating this XML element
• The signed data items can be of different types
  and granularity (XML documents, XML Elements,
  files containing any type of digital data)

18
Securing SOAP messagesWeb Services Security
SOAP Message Security 1.1
(WS-Security 2004)Status Approved OASIS
Standard Specification 1 February 2006

• Goals
• Provide single SOAP message integrity and
  confidentiality
• Using existing digital signature, encryption, and
  security token mechanisms
• Provide mechanisms for associating security
  tokens with message content (header and body
  blocks)
• Extensibility (i.e. support multiple security
  token format)

the recipient can trust the content of the
message and its sender
Security Token - a representation of
security-related information (e.g. X.509
certificate, Kerberos tickets and authenticators,
mobile device security tokens from SIM cards,
username, etc.). Signed Security Token - a
security token that contains a set of related
claims (assertions) cryptographically endorsed by
an issuer. Examples X.509 certificates and
Kerberos tickets.
19
What is WS-Security?

• WS-Security enhances SOAP messaging to provide
  quality of protection through
• message integrity,
• message confidentiality, and
• single message authentication.
• These mechanisms can be used to accommodate a
  wide variety of security models and encryption
  technologies.
• WS-Security also provides a general-purpose,
  extensible mechanism for associating security
  tokens with messages
• No specific type of security token is required
• support for multiple security token formats
• WS-Security describes how to encode binary
  security tokens( X.509 certificates and Kerberos
  tickets)

20
WS-Security mechanisms and considerations

• Mechanism(s)
• Mechanisms for message integrity digital
  signatures and certificates
• Mechanism for confidentiality encryption (XML
  Encryption)
• Digital signatures alone do not provide message
  authentication. To prevent replay attack (one can
  record a signed message and resend it), digital
  signatures must be combined with timestamps or
  sequence numbers to ensure the uniqueness of the
  message.
• When digital signatures are used for verifying
  the identity of the sending party, the sender
  must prove the possession of the private key. One
  way to achieve this is to use a
  challenge-response type of protocol.
• The combination of signing and encryption over a
  common data item may introduce some cryptographic
  vulnerability
• For example, encrypting digitally signed data,
  while leaving the digital signature in the clear,
  may allow plain text guessing attacks

21
WS-Security request example
1 ltsoapEnvelopegt 2 ltsoapHeadergt 3
ltwsSecuritygt 4 ltwsBinarySecurityToken
id"X509token" ValueType"X.509"gt 5
sdfOIDFKLSoidefsdflk 6 lt/wsBinarySecurityTo
kengt 7 ltdsSignaturegt 8 ltdsReferencegt 9
ltdsRef URI"PO"/gt 10 lt/dsReferencegt 11
ltdsSignatureValuegtakjsdflaksflt/dsSignatureValu
egt 12 ltdsKeyInfogt 13 ltwsBinarySecurityTok
enReference URI"X509token"/gt 14
lt/dsKeyInfogt 15 lt/dsSignaturegt 16
lt/wsSecuritygt 17 lt/soapHeadergt 18 ltsoapBodygt
19 ltpoPurchaseOrder ID"PO"/gt 20 lt/soapBodygt
21 lt/soapEnvelopegt
22
WS-SecureConversation

• Conversations focus on the public processes in
  which the participants of a Web service engage
  WSCL is Web Services Conversation Language.
• Web Services Secure Conversation Language
  (WS-SecureConversation) February 2005
• Status revised public draft release provided for
  review and evaluation only
• Main goal provide secure communication across
  one or more messages.
• Extends WS-Security mechanisms
• Allows to authenticate a series of SOAP messages
  (conversation)
• by establishing and sharing between two endpoints
  a security context for a message conversation
  using a series of derived keys to increase
  security.
• The security context is defined as a new token
  type that is obtained using a binding of WS-Trust
• This allows for exchange in a potentially more
  efficient way keys or new key material
• Security Context
• A security context is an abstract concept that
  refers to an established authentication state and
  negotiated key(s) that may have additional
  security-related properties.
• A security context token (SCT) is a
  representation of that security context abstract
  concept, which allows a context to be named by a
  URI and used with WS-Security.

23
Security policies for Web Services

• The concept of Policy Guiding principles and
  procedures
• Security policy might mean different things to
  different people
• Firewall filtering rules
• Access control policy
• Privacy policy
• Standards for Web Services Policies
• WS-Policy
• XACML
• XACML profile for Web Services
• Approaches specialized models languages vs.
  one-size-fits-all framework

24
WS-Policy

• Web Services Policy 1.2 - Framework (WS-Policy)
  W3C Member Submission 25 April 2006
• Status public draft release for review and
  evaluation only
• Main goal The WS-Policy and WS-PolicyAttachment
  aim to offer mechanisms to represent the
  capabilities and requirements of Web services as
  Policies
• Policy view in WS-Policy
• A policy is used to convey conditions on an
  interaction between two Web service endpoints.
• The provider of a Web service exposes a policy to
  convey conditions under which it provides the
  service.
• A requester might use this policy to decide
  whether or not to use the service.

25
WS-Policy

• WS-Policy
• is an extensible model for expressing all types
  of domain-specific policy models transport-level
  security, resource usage policy, even end-to-end
  business-process level policy. It Define basic
  policy, policy statement, and policy assertion
  models. WSPolicy is also able to incorporate
  other policy models such as SAML and XACML
• WS-PolicyAssertions
• Defines a few generic policy assertions
• WS-Policy Attachment
• Defines how to associate a policy with a service,
  either by directly embedding it in the WSDL
  definition or by indirectly associating it
  through UDDI
• WS-SecurityPolicy
• Defines security policy assertions corresponding
  to the security claims defined by WS-Security
  message integrity assertion, message
  confidentiality assertion, and message security
  token assertion
• The only policy assertions standardized so far
  are those defined in WS-SecurityPolicy (specific
  assertions that describe how messages are
  secured) and WS-PolicyAssertions.

26
WS-Policy Policy model

• Policy
• A potentially empty collection of policy
  alternatives. Alternatives are not ordered
• Policy Alternative
• A potentially empty collection of policy
  assertions.
• An alternative with zero assertions indicates no
  behaviors..
• Alternatives are mutually exclusive (exclusive
  OR)
• Policy Assertion
• Identifies a a requirement (or capability) of a
  policy subject.
• Assertions indicate domain-specific (e.g.,
  security, transactions) semantics and are
  expected to be defined in separate,
  domain-specific specifications

27
WS-Policy example
ltwspPolicygt ltwspExactlyOnegt
ltwsseSecurityTokengt ltwsseTokenTypegtwsseKe
rberosv5TGT lt/wsseTokenTypegt
lt/wsseSecurityTokengt ltwsseSecurityTokengt
ltwsseTokenTypegtwsseX509v3
lt/wsseTokenTypegt lt/wsseSecurityTokengt
lt/wspExactlyOnegt lt/wspPolicygt Which security
token we want to use among the various tokens
such as Kerberos and X509
28
XACML

• eXtensible Access Control Markup Language 2
  (XACML) Version 2.0 OASIS Standard, 1 Feb 2005
• Status approved OASIS Standard within the OASIS
  Access 12 Control TC.
• XACML is a general-purpose access control policy
  language for managing access to resources
• It describes both a policy language and an access
  control decision request/response language
• Fine access control grained control
• Access control based on subject and object
  attributes
• Consistent with and building upon SAML

29
XACML Key Aspects

• General-purpose authorization policy model and
  XML-based specification language
• XACML is independent of SAML specification
• Triple-based policy syntax ltObject, Subject,
  Actiongt
• Negative authorization is supported
• Input/output to the XACML policy processor is
  clearly defined as XACML context data structure
• Input data is referred by XACML-specific
  attribute designator as well as XPath expression
• Extension points function, identifier, data
  type, rule-combining algorithm, policy-combining
  algorithm, etc.
• A policy consists of multiple rules
• A set of policies is combined by a higher level
  policy (PolicySet element)

30
XACML data flow model
Source oasis-access_control-xacml-2.0-core-spec-
os
31
XACML Protocol
XACML Request/ Response
32
XACML Protocol

• When a client makes a resource request upon a
  server, the PEP is charged with AC
• In order to enforce AC policies, the PEP will
  formalize the attributes describing the requester
  at the PIP and delegate the authorization
  decision to the PDP
• Applicable policies are located in a policy
  store, managed by the PAP, and evaluated at the
  PDP, which then returns the authorization
  decision
• Using this information, the PEP can deliver the
  appropriate response to the client
• XACML Request
• Subject
• Object
• Action
• XACML Response
• Permit
• Permit with Obligations
• Deny
• NotApplicable (the PDP cannot locate a policy
  whose target matches the required resource)
• Indeterminate (an error occurred or some required
  value was missing)

33
XACML Protocol

• The Policy Administration Point (PAP) creates
  security policies and stores these policies in
  the appropriate repository.
• The Policy Enforcement Point (PEP) performs
  access control by making decision requests and
  enforcing authorization decisions.
• The Policy Information Point (PIP) serves as the
  source of attribute values, or the data required
  for policy evaluation.
• The Policy Decision Point (PDP) evaluates the
  applicable policy and renders an authorization
  decision.
• Note The PEP and PDP might both be contained
  within the same application, or might be
  distributed across different servers

34
Policies and PolicySet

• The key top-level element is the ltPolicySetgt
  which aggregates other ltPolicySetgt elements or
  ltPolicygt elements
• The ltPolicygt element is composed principally of
  ltTargetgt, ltRuleSetgt and ltObligationgt elements and
  is evaluated at the PDP to yield and access
  decision.
• Since multiple policies may be found applicable
  to an access decision, (and since a single policy
  can contain multiple Rules) Combining Algorithms
  are used to reconcile multiple outcomes into a
  single decision
• The ltTargetgt element is used to associate a
  requested resource with an applicable Policy. It
  contains conditions that the requesting Subject,
  Resource, or Action must meet for a Policy Set,
  Policy, or Rule to be applicable to the resource.
  
• The Target includes a build-in scheme for
  efficient indexing/lookup of Policies.
• Rules provide the conditions which test the
  relevant attributes within a Policy. Any number
  of Rule elements may be used each of which
  generates a true or false outcome. Combining
  these outcomes yields a single decision for the
  Policy, which may be "Permit", "Deny",
  "Indeterminate", or a "NotApplicable" decision.

35
Policies and Policy Sets

• Policy
• Smallest element PDP can evaluate
• Contains Description, Defaults, Target, Rules,
  Obligations, Rule Combining Algorithm
• Policy Set
• Allows Policies and Policy Sets to be combined
• Use not required
• Contains Description, Defaults, Target,
  Policies, Policy Sets, Policy References, Policy
  Set References, Obligations, Policy Combining
  Algorithm
• Combining Algorithms Deny-overrides,
  Permit-overrides, First-applicable,
  Only-one-applicable

36
Overview of the Policy Element
ltPolicygt ltTargetgt ltResourcesgt
ltSubjectsgt ltActionsgt ltRuleSet
ruleCombiningAlgId DenyOverridesgt
ltRule ruleIdR1gt ltRule ruleIdR2gt
ltObligationsgt
ltRuleSetgt lt/Policygt
ltRule RuleIdR2 EffectDenygt
ltTargetgt ltResourcesgt ltSubjectsgt
ltActionsgt ltConditiongt lt/Rulegt
ltRule RuleIdR1 EffectPermitgt
ltTargetgt ltResourcesgt ltSubjectsgt
ltActionsgt ltConditiongt lt/Rulegt
37
XACML policy

• A Policy has four main components
• A target
• A rule-combining algorithm identifier
• A set of rules
• Obligations
• The Rule is the elementary unit of a policy
• Main components of a rule
• A target
• An effect permit or deny
• A condition
• Policy Language
• A policy target specifies a set of
• Resources
• Subjects
• Actions
• Environment
• to which it applies

38
XACML Profile for Web-Services

• OASIS XACML Profile for Web-Services XACML
  Working draft 04, 29 Sep 2003
• Status working draft
• Main goal extending XACML to deal with the
  specific characteristics of Web services
• Two main extensions to XACML
• define in a precise way the various aspects to
  which a security policy applies to, for example
  for distinguishing the security policy that must
  be applied to the message level from the access
  control policy applied to a Web service or to an
  operation of the Web service
• use of the policy combination mechanisms defined
  in XACML in order to combine the
  preference/requirements policy of the Web service
  client with the access control policy of the Web
  service provider
• Note XACML profile is not getting as much
  attention as it used to

39
Security Assertion Markup Language (SAML)

• Developed by the OASIS XML-Based Security
  Services Technical Committee (SSTC)
• Status SAML V2.0 OASIS Standard specification
  set was approved on 15 March 2005
• Main goal authentication and authorization
• promote interoperability between disparate
  authentication and authorization systems
• How
• defining an XML-based framework for communicating
  security and identity information (e.g.,
  authentication, entitlements, and attribute)
  between computing entities
• using available different security
  infrastructures (e.g., PKI, Kerberos, LDAP, etc)

40
SAML basic concepts

• Assertions The core concept
• SAML Authority a system entity that makes SAML
  assertions (also called Identity Provider IdP
  and Asserting Party)
• Service Provider a system entity making use of
  SAML assertions
• Relying Party a system entity that uses received
  assertions (named also SAML requester)
• SAML Bindings Bindings describe exactly how the
  SAML protocol maps onto the transport protocols.

41
SAML assertions

• An assertion is constituted by one or more
  statements made by a SAML authority
• Different kinds of assertion statement that can
  be created by a SAML authority
• Authentication The specified subject was
  authenticated by a particular means at a
  particular time.
• Attribute The specified subject is associated
  with the supplied attributes.
• Authorization decision statements the specified
  subject is entitled to do a specified action

Martino authenticated with a password at 900am
Bill is an account manager with a 1000 spending
limit per one-day travel
John Doe is permitted to buy a specified item
42
SAML entities
SAML Authority makes SAML assertions
SAML Requester a system entity that uses received
assertions
Service Providers a system entity making use of
SAML assertions
43
SAML profiles

• Defines constraints and/or extensions of the core
  protocols and assertions in support of the usage
  of SAML for a particular application.
• Achieve interoperability.
• Stipulates how particular statements are
  communicated using appropriate protocol messages
  over specified bindings.
• E.g. Web Browser SSO Profile specifies how SAML
  authentication assertions are communicated using
  the Authentication Query and Response messages
  over a number of different bindings in order to
  enable Single Sign-On for a browser user
• By agreeing to support a particular SAML profile
  (as opposed to the complete specification set),
  parties who wish to exchange SAML messages have a
  much simpler job of achieving interoperability.

44
SAML and XACML
Source Security Assertion Markup Language (SAML)
V2.0 Technical Overview Working Draft 08, 12
September 2005
45
SAML Federated Identity

• SAML addresses one key aspect of identity
  management how identity information can be
  communicated from one domain to another
• SAML 2.0 will be the basis on which Liberty
  Alliance builds additional federated identity
  applications (such as web service-enabled
  permissions-based attribute sharing).

46
Standards for security management XKMS (XML Key
Management Standard)

• XML Key Management Specification (XKMS 2.0)
  Version 2.0 5 April 2004
• Status W3C Candidate Recommendation
• XKMS provides a Web-based interface to existing
  public key infrastructure (PKI)
• XKMS specifies protocols for
• Distributing
• Registering public keys
• The protocol is suitable for use in conjunction
  with the standard for XML Signatures XML-SIG
  and companion standard for XML Encryption
  XML-ENC.
• The XML Key Management Specification (XKMS)
  defines two services
• the XML Key Information Service Specification
  (X-KISS) and
• the XML Key Registration Service Specification
  (X-KRSS).

47
XKMS services
BOB
ALICE
XKMS protocol
XML Key Information Service (X-KISS)
XML Key Registration Service (X-KRSS)
- register - reissue - revoke - recover
- locate a public key - validate a public key
48
Standards for security management WS-TRUST

• Security (confidentiality integrity) is
  achieved through encryption, digital signatures
  and certificates
• Ultimately, security depends on the secure
  management of cryptographic keys and security
  tokens
• Key/security token issuance
• Key/security token transmission
• Key/security token storage
• Key/security token exchange

49
WS-Trust

• Web Services Trust Language (WS-Trust) February
  2005
• Status Initial public draft release provided for
  review and evaluation only
• Main goal to enable the issuance and
  dissemination of credentials among different
  trust domains
• WS-Trust defines extensions to WS-Security that
  provide
• Methods for issuing, renewing, and validating
  security tokens.
• Ways to establish, assess the presence of, and
  broker trust relationships.
• Motivation The recipient of a WS-Security-protect
  ed SOAP message has three potential issues with
  the security token contained within the Security
  header
• Format the format or syntax of the token is not
  known to the recipient
• Trust -- the recipient may be unable to build a
  chain-of-trust from its own trust anchors (e.g.
  its X.509 Certificate Authority, a local Kerberos
  KDC, or a SAML Authority) to the issuer or signer
  of the token
• Namespace -- the recipient may be unable to
  directly comprehend the set of claims within the
  token because of syntactical differences

50
WS-Trust trust model
51
WS-Trust example
?
NO previouos trust relationship
Client
Firewall
The Client uses X.509 certificate
WS-Security SOAP msg
The Provider understands Kerberos certificate
STS Service
52
WS- Security standards and security

• WS- security standard specifications address
  interoperability aspects
• Each standard specification provides a specific
  section describing security threats that are not
  addressed by that specification
• When using implementations of the specifications,
  the above warnings must be carefully analyzed

53
WS- Security standards and interoperability

• Theory
• The framework mandates for a layered approach
• every upper layer standard could/should re-use
  and extend the specification of lower-layer
  standards.
• Practice
• Specifications issued by different bodies are not
  always compatible, but
• Adherence to profiles improves interoperability
• Implementations of different vendors are not
  always interoperable

54
WS- Security standards and performance

• XML induces overhead
• Efficient ways of packaging and transmitting
  binary data in SOAP messages are needed
• XML-binary Optimized Packaging (XOP)
• SOAP Message Transmission Optimization Mechanism
  (MTOM)
• Resource Representation SOAP Header Block (RRSHB)
  
• Processing of WS- security compliant messages
  require encryption/decryption and eventually
  signature management capabilities
• XML accelerators and the XML firewalls try to
  solve those problems

55
XML Accelerators and Firewalls

• Accelerators A customized hardware and software
  performing the following processing tasks
• XML/SOAP parsing,
• XML schema validation,
• XPath processing and XSLT transformation
  functions
• Firewalls Also known as XML gateways
• Perform functions of a XML accelerator
• Support WS-Security standard
• Additional functionalities
• content or metadata-based XML/SOAP filtering
  functions
• XML messages encryption/decryption at the message
  or element level
• XML signatures verification and XML message
  signing according to XML Encryption standard
• Authentication and authorization functions (that
  in some XML appliance can be based on local or on
  off-board repositories)

56
Summary Points

• SOA concept based on service orientation is now a
  significant method for software development and
  promotes extensibility and flexibility Service
  oriented analysis has now become a standard way
  to model software
• Web Services is just one way to realize SOA
• Security for SOA is crucial as SOA is being used
  in numerous sectors since web services realize
  SOA, web services security is critical
• SOA and SOA Security Standards are being
  developed by W3C and OASIS WS-Security,
  WS-Security Framework, and XACML are some of the
  key standards
• SOA security currently focuses mainly on access
  control. SOA-specific techniques to address
  intrusion detection, denial of service and
  insider threat analysis need attention