SOA Security <Iris Levari> <OWASP role> <Amdocs> <irisl@amdocs.com> <12/3/07>
Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns /...
Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns /...
SOA Example
SOA Key Terms
SOA - Service Oriented Architecture  <ul><li>Business processes oriented architecture  </li></ul><ul><li>Decomposing busin...
Service Properties   <ul><li>Service is </li></ul><ul><ul><li>Loosely coupled </li></ul></ul><ul><ul><li>High-level granul...
Service Oriented Architecture -  Advantages & Disadvantages <ul><li>Advantages  </li></ul><ul><ul><li>Maximize reuse </li>...
SOA Example
Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns /...
Business-Driven Development Methodology
Security Encompasses all life cycle aspects
Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns /...
New Security Threats <ul><li>SOA Introduces the following new security threats: </li></ul><ul><ul><li>Services to be consu...
Security Considerations <ul><li>The propagation of users and services across domain trust boundaries </li></ul><ul><li>The...
New Techniques In Integration Security <ul><li>SOA introduces new techniques In integration security </li></ul><ul><ul><li...
Message Level Security vs. Transport Level Security <ul><li>Transport level security (SSL/VPN) </li></ul><ul><ul><li>Point...
Transport Layer Security
Security in the Message <ul><li>HTTP security (SSL) is point-to-point </li></ul><ul><li>WS-Security provides context over ...
Transport Security For Web Services Pros and Cons Pros Cons Mature: SSL/VPN Point to point: messages are in the clear afte...
Message Security For Web Services  Pros And Cons Pros Cons Persistent message self-protecting Encompasses many other stand...
Message Security And Transport Security Comparison  Transport Security Message Security Point-to-point End-to-end Mature, ...
Message Level Security (example) integration of a brokerage and a bank. An investor securely attaches authorization to wit...
Converting Security into a Service <ul><li>Security services provide service such as: </li></ul><ul><ul><li>Authentication...
SOA Security Reference Model
Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns /...
Traditional SSO Security is hard coded into each application   User credentials are transmitted across enterprise boundaries
SOA SSO Federation
SOA SSO Federation Cont’ <ul><li>Traditional limited implementation using 3 rd  party SSO solutions  </li></ul><ul><ul><li...
Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns /...
WS-security Standard  <ul><li>SOAP security (securing the web service messages) </li></ul><ul><li>SOAP header extension  <...
Web Services Stack
Web Services Security Architecture
“WS –Security” Building Blocks <ul><li>Security Tokens </li></ul><ul><ul><li>Username Token </li></ul></ul><ul><ul><li>Use...
Structure of a Basic Web Services Security SOAP Header
Structure of a Basic Web Services Security SOAP Header (cont.)
XML Encryption in WS-Security Use of a <ReferenceList> in the Security Header Pointing to the Parts of the Message Encrypt...
A Wrapped Key in a Security Header for Use in XML Encryption
A Wrapped Key in a Security Header for Use in XML Encryption (cont.)
Providing Integrity  XML Signature in Web Services Security  <ul><li>XML Signature </li></ul><ul><ul><li>Verify a security...
XML Signature Example
XML Signature Example Cont’
XML Signature Example Cont’
XML Signature Example Cont’
Upcoming SlideShare
Loading in...5
×

SOA security

397

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
397
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • business system requirement motivate SOA consumption Following a service orientation, existing business processes are decomposed into discrete units of business function termed services Service orientation is more than merely decomposing business processes into components of business function. It also identifies that the focus in application development should be on implementing business logic, not on how components will interconnect. This allows services to be arbitrarily connected together to implement the desired business processes. Moreover, services can be replaced with equivalent services as required; for example, a particular business function may be outsourced, or there is a change in the partners used. SOA and Business Architecture One area where SOA has been gaining ground is in its power as a mechanism for defining business services and operating models and thus provide a structure for IT to deliver against the actual business requirements and adapt in a similar way to the business. The purpose of using SOA as a business mapping tool is to ensure that the services created properly represent the business view and are not just what technologists think the business services should be. At the heart of SOA planning is the process of defining architectures for the use of information in support of the business, and the plan for implementing those architectures (Enterprise Architecture Planning by Steven Spewak and Steven Hill). Enterprise Business Architecture should always represent the highest and most dominant architecture. Every service should be created with the intent to bring value to the business in some way and must be traceable back to the business architecture.
  • Services are stateless
  • Service orientation aims to better align business and IT goals, and to provide greatly improved capability to deal with change. The service-oriented life cycle is therefore built around a business-driven development methodology that includes the following phases: Model: Use modeling tools to define the business process at a business function level, and model the actual services that will be part of an assembled, composite application. Assemble: Assemble the individual services and write the code that is needed to implement the business rules for the application. Pre-existing services can be re-used, new services can be developed, or both. Deploy: Deploy the services to runtime environments, such as transaction management engines like WebSphere® Application Server. Use integration components, primarily an enterprise service bus (ESB), to link together the various services needed for the composite application. Manage: Implement the management infrastructure for monitoring and managing the services and the service infrastructure. This includes not only IT management tools, but also business management and monitoring tools to measure actual business activities. Governance underpins all the life cycle stages, providing guidance and oversight for the entire service-oriented environment. Model: Use modeling tools to define the business process at a business function level, and model the actual services that will be part of an assembled, composite application .: Use modeling tools to define the business process at a business function level, and model the actual services that will be part of an assembled, composite application. Assemble : Assemble the individual services and write the code that is needed to implement the business rules for the application. Pre-existing services can be re-used, new services can be developed, or both. Deploy : Deploy the services to runtime environments, such as transaction management engines like WebSphere® Application Server. Use integration components, primarily an enterprise service bus (ESB), to link together the various services needed for the composite application. Manage: Implement the management infrastructure for monitoring and managing the services and the service infrastructure. This includes not only IT management tools, but also business management and monitoring tools to measure actual business activities. Governance underpins all the life cycle stages, providing guidance and oversight for the entire service-oriented environment. Governance underpins all the life cycle stages, providing guidance and oversight for the entire service-oriented environment.
  • דגשי א &amp;quot; מ
  • integration complicates security enforcement
  • integration complicates security enforcement
  • integration complicates security enforcement VPN - feasible for partners, who may have sophisticated IT setup, it is onerous for casual users, or large number of clients SSL not sufficient when integrating more then 2 applications merchant seeking to enable online purchases with credit cards. Here, two applications, the shopping system that merchant uses and the authorizing system that the credit card company uses, are integrated to offer a higher level service that enables customers to make direct purchases from the merchant. When you submit your credit card information, perhaps you use HTTPS to transmit the information. As your HTTPS connection is with the merchant’s application and not with the credit card company’s application, the merchant gets to see your credit card details. The merchant can of course reuse the information for making additional purchases without your knowledge. Even if you trust the intentions of the merchant, there is no guarantee that the merchant’s application handles your credit card information securely. For example, the merchant application may store your credit card information in a database that is not well secured against attacks by hackers. Or, your merchant application may relay your credit card information to the credit card company over an insecure connection. Message level example: Not all of the lower level services may be belong to the same security domain (organization or entity). This translates into the need for securing same or different parts of a message differently for consumption by different parties. This of course cannot be done using network level security as the network can only secure a message in one way and does not distinguish one part of a message from another. There are no such limitations with Message level security and hence, it is a good technique for use in integration security.
  • Message in the clear
  • Security service not only facilitates integration; it can also drastically bring down the cost of developing, auditing and managing security in each business Depending that services are resused
  • hard-coded security models in each application. Most applications, even to this date, come with their own custom solutions to security issues. For example, applications have their own user/password stores which they use to authenticate; they have their own way of doing authorization based on the user name, resource, activity, and perhaps even internal system status. The problem with this state of affairs is that the security model in each application may make assumptions that are only valid when the application is used by itself and not when the application is integrated with others.
  • A security service avoids the need to pass on user credentials to each business service. The security service forwards authorized requests to the called business service along with security assertions. The called business service can in turn submit some of those assertions to the underlying applications as required
  • integrating applications: Additional management us required for managing the interactions between the applications. For example, a password change in one place may have to be propagated to multiple applications. Or, a change in the security policy of one part of the application may impact the access policy of another application. provides a declarative way of specifying security for applications, which has two important repercussions – the first being easy implementation of security solutions and the second being ability for clients and servers to dynamically negotiate security policies.
  • CISSP Security-Management Practices By Michael C. Gregg . Confidentiality —The concept of keeping private information away from individuals who should not have access. Any time there is an unintentional release of information, confidentiality is lost. As an example, if Black Hat Bob can intercept an email between the CEO and the CIO and learn their latest plans, confidentiality has been broken and there is a lapse of security. Other attacks on confidentiality include sniffing, keystroke monitoring, and shoulder surfing. Integrity —The concept of integrity means that data is consistent and that it hasn’t been modified. This modification can result from access by an authorized or unauthorized individual or process. Integrity must also prevent modification of data while in storage or in transit. For example, if I could access my bank account and change the bank balance by adding a few zeroes . . . well, that’s not such a big deal to me, but the bank might not be happy because they would suffer a serious lapse of integrity. Availability —The concept of availability is pretty straightforward. You should have reliable and timely access to the data and resources you are authorized to use. A good example of a loss of availability is a DoS attack. No, it doesn’t give the perpetrator access, but it does prevent legitimate users from using the resource. Which one of these three is most important? Well, that depends. They are all important, but organizations are unique. Different elements of the CIA triad will take the lead in different companies. For example, your local bank might consider integrity the most important, but an organization that does data processing might see availability as the primary concern.
  • When key wrapping is involved in WS-Security, an EncryptedKey element shows up in the security header. The ReferenceList in the EncryptedKey element points to the EncryptedData elements that use the underlying encrypted key Wrapped Key XML Encryption Shared key encryption is very fast, scalable to any size message, and, consequently, is always used for encrypting the XML text of a message. Public key encryption has beneficial key management characteristics because a public key, typically wrapped in an X.509 certificate issued by a certificate authority, can be published publicly in a registry or even in the WSDL. The recipient&apos;s public key can then be used to encrypt the shared key, and the shared key can be used to encrypt the different parts of the message itself. Let&apos;s go over that again but in a different order. First, the message itself, or perhaps multiple individual parts of the message, are encrypted using a generated arbitrary shared key. Second, this shared key is then encrypted using the recipient&apos;s public key. Because the recipient is the holder of the solitary matching and highly protected private key, theoretically, the recipient is the only one who can decrypt the shared key and then proceed to decrypt the rest of the message. The technique is often called key wrapping or digital enveloping because the shared key is wrapped by the recipient&apos;s public key. Although we tend to emphasize using a public key for key wrapping, it is equally possible to use a shared key to wrap a shared key. Tip You might use a shared key to wrap other shared keys in a &amp;quot;master key&amp;quot; scenario. In this scenario, a single master shared key can be used to encrypt multiple other shared keys used to encrypt different parts of the document. With this approach, intended recipients can read only their parts of the document, but the holder of the master key can read the entire document. Notice that the main SOAP elements such as Envelope, Header, and Body are never encrypted because these elements are necessary for the SOAP infrastructure to work effectively.
  • XML Signature is used within WS-Security for two major reasons. One is to verify a security token credential such as an X.509 certificate or SAML assertion. Another is message integrity —verifying that the message (or important parts of it) has not been modified in transit XML Signature for Message Integrity XML Signatures are also used to certify and maintain the integrity of the message itself. By signing the body of a message or some other part of a message, you can guarantee that the message arrives unaltered at the receiver&apos;s end as long as the receiver applies the signature validation process. The possibility of legitimate changes in transit could conceivably cause problems with the XPath statements that are used in the Reference URI of the XML Signature. You must be careful when constructing XPath statements so that they remain valid at the point of signature validation.
  • SOA security

    1. 1. SOA Security <Iris Levari> <OWASP role> <Amdocs> <irisl@amdocs.com> <12/3/07>
    2. 2. Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns / opportunities </li></ul><ul><li>SSO & SSO Federation </li></ul><ul><li>WS Security Standard </li></ul>
    3. 3. Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns / opportunities </li></ul><ul><li>SSO & SSO Federation </li></ul><ul><li>WS Security Standard </li></ul>
    4. 4. SOA Example
    5. 5. SOA Key Terms
    6. 6. SOA - Service Oriented Architecture <ul><li>Business processes oriented architecture </li></ul><ul><li>Decomposing business processes into discreet functional units = services </li></ul><ul><li>Existing or new business functionalities are grouped into atomic business services </li></ul><ul><li>Evolution of distributed computing and modular programming driven by newly emergent business requirements </li></ul><ul><li>Application development focused on implementing business logic </li></ul>
    7. 7. Service Properties <ul><li>Service is </li></ul><ul><ul><li>Loosely coupled </li></ul></ul><ul><ul><li>High-level granularity </li></ul></ul><ul><ul><li>Self describing </li></ul></ul><ul><ul><li>Hardware or software platform interoperability </li></ul></ul><ul><ul><li>Discoverable </li></ul></ul><ul><ul><li>Service can be composed of other services </li></ul></ul><ul><ul><li>Context-independent </li></ul></ul>
    8. 8. Service Oriented Architecture - Advantages & Disadvantages <ul><li>Advantages </li></ul><ul><ul><li>Maximize reuse </li></ul></ul><ul><ul><li>Reduce integration cost </li></ul></ul><ul><ul><li>Flexible & easily changed to reflect business process change </li></ul></ul><ul><li>Shortcomings </li></ul><ul><ul><li>Message handling and parsing </li></ul></ul><ul><ul><li>Legacy application services wrapping </li></ul></ul><ul><ul><li>Complex service design and implementation </li></ul></ul>
    9. 9. SOA Example
    10. 10. Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns / opportunities </li></ul><ul><li>SSO & SSO Federation </li></ul><ul><li>WS Security Standard </li></ul>
    11. 11. Business-Driven Development Methodology
    12. 12. Security Encompasses all life cycle aspects
    13. 13. Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns / opportunities </li></ul><ul><li>SSO & SSO Federation </li></ul><ul><li>WS Security Standard </li></ul>
    14. 14. New Security Threats <ul><li>SOA Introduces the following new security threats: </li></ul><ul><ul><li>Services to be consumed by entities outside of the local trust domain </li></ul></ul><ul><ul><li>Confidential data passes the domain’s trust boundaries </li></ul></ul><ul><ul><li>Authentication and authorization data is communicated to external trust domains </li></ul></ul><ul><ul><li>Security must be enforced across the trust domain </li></ul></ul><ul><ul><li>Managing user and service identities </li></ul></ul>
    15. 15. Security Considerations <ul><li>The propagation of users and services across domain trust boundaries </li></ul><ul><li>The need to seamlessly connect to other organizations on a real-time transactional basis </li></ul><ul><li>Security controls for each service and service combinations </li></ul><ul><li>Managing identity and security across a range of systems and services with a mix of new and old technologies </li></ul><ul><li>Protecting business data in transit and at rest </li></ul><ul><li>Compliance with corporate industry & regulatory standards </li></ul><ul><li>Composite services </li></ul>
    16. 16. New Techniques In Integration Security <ul><li>SOA introduces new techniques In integration security </li></ul><ul><ul><li>Message level security vs. transport level security </li></ul></ul><ul><ul><li>Converting security enforcement into a service </li></ul></ul><ul><ul><li>Declarative & policy-based security </li></ul></ul>
    17. 17. Message Level Security vs. Transport Level Security <ul><li>Transport level security (SSL/VPN) </li></ul><ul><ul><li>Point-to-point message exchange </li></ul></ul><ul><ul><li>Encrypts the entire message </li></ul></ul><ul><ul><li>Sender must trust all intermediaries </li></ul></ul><ul><ul><li>Restricts protocols that can be used (i.e. https) </li></ul></ul><ul><li>Message level security </li></ul><ul><ul><li>End-to-end security </li></ul></ul><ul><ul><li>Different message fields within the same message should be read by different entities </li></ul></ul>
    18. 18. Transport Layer Security
    19. 19. Security in the Message <ul><li>HTTP security (SSL) is point-to-point </li></ul><ul><li>WS-Security provides context over multiple end points. </li></ul>Receiver Sender Intermediary Receiver Security Context | | | Security Context | | | Receiver Sender Intermediary Receiver Security Context
    20. 20. Transport Security For Web Services Pros and Cons Pros Cons Mature: SSL/VPN Point to point: messages are in the clear after reaching SSL endpoint Supported by most servers and clients Waypoint visibility: can’t have partial visibility into the message parts Understood by most system administrators Granularity Simpler Transport dependant: applies only to HTTP
    21. 21. Message Security For Web Services Pros And Cons Pros Cons Persistent message self-protecting Encompasses many other standards including XML encryption, XML signature, X.509 certificates and more Portions of the message can be secured to different parties Different security policies can be applied to request and respond transport
    22. 22. Message Security And Transport Security Comparison Transport Security Message Security Point-to-point End-to-end Mature, relatively straightforward to implement Relatively complex with many security options Not granular, applies to entire payload and across session Very granular, can apply to only part of payload and only request or response Transport dependent Same security can be applied across different transport technologies
    23. 23. Message Level Security (example) integration of a brokerage and a bank. An investor securely attaches authorization to withdraw funds from a bank account to the trading request submitted to the brokerage. The attached authorization is secured from everyone, including the brokerage. Only the bank read it and make use of it.
    24. 24. Converting Security into a Service <ul><li>Security services provide service such as: </li></ul><ul><ul><li>Authentication </li></ul></ul><ul><ul><li>Authorization </li></ul></ul><ul><li>Message services </li></ul><ul><ul><li>Encryption decryption </li></ul></ul><ul><ul><li>Signing </li></ul></ul><ul><ul><li>Verification </li></ul></ul><ul><ul><li>Signatures </li></ul></ul><ul><ul><li>Log messages scrub messages </li></ul></ul><ul><li>Facilitates integration </li></ul><ul><li>Reduces development cost </li></ul>
    25. 25. SOA Security Reference Model
    26. 26. Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns / opportunities </li></ul><ul><li>SSO & SSO Federation </li></ul><ul><li>WS Security Standard </li></ul>
    27. 27. Traditional SSO Security is hard coded into each application User credentials are transmitted across enterprise boundaries
    28. 28. SOA SSO Federation
    29. 29. SOA SSO Federation Cont’ <ul><li>Traditional limited implementation using 3 rd party SSO solutions </li></ul><ul><ul><li>No easy integration with applications that have not been written by the same 3 rd party SSO manufacturer </li></ul></ul><ul><li>SOA solution </li></ul><ul><ul><li>Managing security interaction between applications </li></ul></ul><ul><ul><li>Clients and servers dynamically negotiate security policies </li></ul></ul><ul><ul><li>Easy implementation </li></ul></ul>
    30. 30. Agneda <ul><li>What Is SOA </li></ul><ul><li>SOA life cycle & Security </li></ul><ul><li>SOA Generated Security Concerns / opportunities </li></ul><ul><li>SSO & SSO Federation </li></ul><ul><li>WS Security Standard </li></ul>
    31. 31. WS-security Standard <ul><li>SOAP security (securing the web service messages) </li></ul><ul><li>SOAP header extension </li></ul><ul><li>Standard Feb. 2007 Ver 1.1 (OASIS) </li></ul><ul><li>Any combination of In Request/Response </li></ul><ul><ul><li>Authentication </li></ul></ul><ul><ul><li>Encryption </li></ul></ul><ul><ul><li>Digital Signature </li></ul></ul>
    32. 32. Web Services Stack
    33. 33. Web Services Security Architecture
    34. 34. “WS –Security” Building Blocks <ul><li>Security Tokens </li></ul><ul><ul><li>Username Token </li></ul></ul><ul><ul><li>Username Token with Password Digest </li></ul></ul><ul><ul><li>Binary Security Token </li></ul></ul><ul><ul><ul><li>X.509 Version 3 certificates </li></ul></ul></ul><ul><ul><ul><li>Kerberos tickets </li></ul></ul></ul><ul><li>Signatures signs all or part of the soap body </li></ul><ul><li>Reference List or Encrypted Key </li></ul>
    35. 35. Structure of a Basic Web Services Security SOAP Header
    36. 36. Structure of a Basic Web Services Security SOAP Header (cont.)
    37. 37. XML Encryption in WS-Security Use of a <ReferenceList> in the Security Header Pointing to the Parts of the Message Encrypted with XML Encryption
    38. 38. A Wrapped Key in a Security Header for Use in XML Encryption
    39. 39. A Wrapped Key in a Security Header for Use in XML Encryption (cont.)
    40. 40. Providing Integrity XML Signature in Web Services Security <ul><li>XML Signature </li></ul><ul><ul><li>Verify a security token or SAML assertion </li></ul></ul><ul><ul><li>Message integrity </li></ul></ul><ul><li>XML syntax </li></ul><ul><ul><li>Explicit <reference> element points to what is being signed </li></ul></ul><ul><ul><li>One or more XML signatures </li></ul></ul><ul><ul><li>Overlapping is possible </li></ul></ul>
    41. 41. XML Signature Example
    42. 42. XML Signature Example Cont’
    43. 43. XML Signature Example Cont’
    44. 44. XML Signature Example Cont’
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×