SOA, Interoperability and Security


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

SOA, Interoperability and Security

  1. 1. SOA, Interoperability and Security All roads lead to web services security Nataraj Nagaratnam, Ph.D., IBM Distinguished Engineer Chief Architect, Identity and SOA Security, Tivoli, Software Group, IBM
  2. 2. Agenda • Service Oriented Architecture and Interoperability – Role of Web Services • SOA Security Considerations • Web Services Security – Standards Roadmap – Message security – Policy – Trust, Authorization
  3. 3. SOA and Interoperability 10/23/2007 Template Documentation 3
  4. 4. What is SOA? … a service? … service oriented architecture (SOA)? A repeatable An IT architectural business task – style that supports e.g., check integrating your customer credit; business as linked open new account services
  5. 5. What is the SOA model? Business Componentization Business Re-defining today’s monolithic enterprise components processes as a set of standardized modular business process components Service Oriented Architecture SOA application An IT model which mirrors the interaction components * of business components through a set of IT applications implemented as real-time services that interact dynamically WS Protocols (XML, SOAP, WSDL, UDDI) Web Services provide an interface toolkit for components A set of vendor neutral and platform Business components agnostic standards that can be used to define how SOA components interact SOA components Components interfaces * Each SOA application component may be made up of multiple applications Web Services protocols 10/23/2007 Template Documentation 5
  6. 6. Web Services – a Simple View Business Business Process Execution Language Processes For Web Services (BPEL4WS) Quality of Reliability Transactions Management Security Service Description Web Services Description Language (WSDL) Simple Object Access Protocol (SOAP) Other Protocols Other Messaging Services Extensible Markup Language (XML)
  7. 7. WS-* Architectural Principles • Message orientation – Using only messages to communicate between services • Protocol composability – Use protocol building blocks in nearly any combination. • Autonomous services – Independent endpoints • Managed transparency – Controlling what is externally visible • Protocol-based integration – Coupling via wire artifacts only.
  8. 8. SOA – Security considerations
  9. 9. Security Considerations for SOA • Entities/Identities – users, services Services have identities Identities and/or credentials are propagated across services Users and services are now subject to the same security controls • Organizational/enterprise boundaries Perimeter is obscure Identities are managed across boundaries Trust relationships are established across boundaries • Composite applications Ensuring proper security controls are enacted for each service and when used in combination • Greater focus on data/information Protecting data at transit and at rest Apply consistent protection measures Access to data by applications and services • Governance, Risk, and Compliance Auditing ie. entity identification to specific transactions 10/23/2007 Template Documentation 9
  10. 10. SOA Security – Reference Model Business Security Services Governance and Risk Management Compliance & Data Protection, Privacy Non-repudiation Security Policy Infrastructure Reporting & Disclosure Control Services Policy Management Identity & Trust Secure Systems Access Management & Networks IT Security Services Authentication Authorization Identity Services Services Services Confidentiality Integrity Audit Services Services Services Security Enablers 10/23/2007 Template Documentation 10
  11. 11. Web Services Security
  12. 12. Interoperable security enablers and services • Message security –Integrity, Confidentiality, Identity propagation • Policy constraints, requirements –Constraints, Authorization, privacy, .. • Security services –Standardized virtualized security services
  13. 13. Standards Summary: Web Services Security Secure Authorization Federation Conversation Security Privacy Trust Policy Message Security SOAP Messaging
  14. 14. Message protection
  15. 15. Message Processing Requires New Layers of Security 10/23/2007 Template Documentation 15
  16. 16. WS-Security Sender Intermediary Intermediary Receiver …
  17. 17. WS-Security • Defines a framework for building security protocols – Integrity – Confidentiality – Propagation of security tokens • Framework designed for end-to-end security of SOAP messages – From initial sender, through 0-n intermediaries to ultimate receiver • Leverages existing XML security specs – XMLDSIG for integrity – XMLENC for confidentiality • Provides constructs for transmitting security tokens – Supports XML and binary tokens
  18. 18. WS-Security • WS-Security does provide: • WS-Security does NOT – Message level security provide: – “Improved SSL” – Application level security – Security at lower/network – Enterprise security layer – Authentication mechanisms – Transmission security – Authorization security – Message authentication – Intrusion detection – Message confidentiality – Identity management – Message integrity – Security Architecture – Network Security – Anti-Virus protection
  19. 19. What are Security Tokens? • Examples include • Message claims to be from Alice – Username token – Specified using Alice's X509 – X509 Certificate certificate – Kerberos ticket – REL license • Proof is based on Alice's private key – SAML assertion – Signing part of the message • Represent claims with her private key proves about that she knows the key and is therefore Alice – Identity – Specifically, that the signed – Capabilities parts are from Alice – Privileges
  20. 20. Web Services message transmission Soap Envelope Soap Header Message Header and Routing Security Content Security Token Signature Actual signed content Message Body
  21. 21. WS Security • Terminology: – Claim - A claim is a statement that a client makes (e.g. name, identity, key, group, privilege, capability, etc). – Security Token - A security token represents a collection of claims. – Signed Security Token - A signed security token is a security token that is asserted and cryptographically endorsed by a specificauthority (e.g. an X.509 certificate or a Kerberos ticket). – Proof-of-Possession - The proof-of-possession information is data that is used in a proof process to demonstrate the sender's knowledge of information that SHOULD only be known to the claiming sender of a security token. – Integrity - Integrity is the process by which it is guaranteed that information is not modified in transit. – Confidentiality - Confidentiality is the process by which data is protected such that only authorized actors or security token owners can view the data – Digest - A digest is a cryptographic checksum of an octet stream. – Signature - A signature is a cryptographic binding of a proof-of-possession and a digest. This covers both symmetric key-based and public key-based signatures. Consequently, non-repudiation is not always achieved. – Attachment - An attachment is a generic term referring to additional data that travels with a SOAP message, but is not part of the SOAP Envelope.
  22. 22. WS Security Capabilities Summary • Message Security Model – Security Tokens MAY be bound to messages • Message Protection – Message Integrity – attained by using XML Signatures with Security Tokens – Message Confidentiality – attained by using XML Encryption with Security Tokens • WS Security Standard allows: – Encryption/Signing of: • Body • Body Elements • Header • Attachments
  23. 23. WS Security Message Example Message example with a username security token (1 of 3): (001) <?xml version="1.0" encoding="utf-8"?> First two lines start SOAP message (002) <S:Envelope xmlns:S="" xmlns:ds=""> (003) <S:Header> (004) <m:path xmlns:m=""> Lines 004 to 008 define how to (005) <m:action></m:action> route this message (006) <m:to></m:to> (007) <m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id> (008) </m:path>
  24. 24. WS Security Message Example Message example with a username security token (2 of 3): (009) <wsse:Security Line 009: Start of Security header xmlns:wsse=""> (010) wsse:UsernameToken Id="MyID"> Lines 010 to 012 specify the (011) <wsse:Username>Zoe</wsse:Username> security token (012) </wsse:UsernameToken> (013) <ds:Signature> (014) <ds:SignedInfo> Lines 013 to 028 specify a digital (015) <ds:CanonicalizationMethod signature – this example uses a Algorithm= signature based on the security ""/> token, this is NOT a recommended signature scheme (016) <ds:SignatureMethod Algorithm= ""/> (017) <ds:Reference URI="#MsgBody"> (018) <ds:DigestMethod Algorithm= ""/> (019) <ds:DigestValue>LyLsF0Pi4wPU...</ds:DigestValue> (020) </ds:Reference>
  25. 25. WS Security Message Example Message example with a username security token (3 of 3): (021) </ds:SignedInfo> (022) <ds:SignatureValue>DJbchm5gK...</ds:SignatureValue> (023) <ds:KeyInfo> (024) <wsse:SecurityTokenReference> (025) <wsse:Reference URI="#MyID"/> (026) </wsse:SecurityTokenReference> (027) </ds:KeyInfo> (028) </ds:Signature> (029) </wsse:Security> (030) </S:Header> (031) <S:Body Id="MsgBody"> (032) <tru:StockSymbol xmlns:tru=""> Lines 031 to 033 contain the body QQQ of the SOAP message </tru:StockSymbol> (033) </S:Body> (034) </S:Envelope>
  26. 26. Interoperable secure messages across SOA environment IBM WebSphere DataPower IBM WebSphere WS-Security based messages: Tokens, Signature, Encrypted elements
  27. 27. Trust model: trust, authentication and identity propagation
  28. 28. WS-Trust • Defines how to broker trust relationships – Some trust relationship has to exist a priori • Defines how to exchange security tokens • Defined as an interface specification for a Security Token Service • Anyone can issue tokens (be a Security Token Service)
  29. 29. Getting Tokens • A RequestSecurityToken message is sent to the trust service • It responds with a RequestSecurityTokenResponse – Contains required security token and associated details (e.g. proof) • Example – I want to have secure communication with you – I ask the trust service for a token to allow me to talk to you – The trust service sends two copies of a secret key • One encrypted for me (proof token) • One encrypted for you (requested token)
  30. 30. Example Trust T1 Trust U/P 1 P1 T1 2 T2 P2 3 T2 T# Security Token P# Proof token
  31. 31. Identity mediation using WS-Trust Tivoli Federated Identity Manager Firewall Firewall DataPower ESB Tivoli Federated Identity Manager
  32. 32. Challenge mechanism Request Token Issue Challenge Respond to Challenge Issue Token
  33. 33. Other Token Characteristics • Requester can specify various required characteristics of the security token – Key type, size – Delegation constraints –… • Trust service can then indicate those characteristics in the response – May indicate anything it thinks important
  34. 34. Persisted Context SCT
  35. 35. Farm Context SCT
  36. 36. WS-SecureConversation • WS-Security provides for single message security • Nodes will often want to exchange more than one message – Specifying new symmetric keys for each message is tedious, verbose, and inefficient • WS-SecureConversation defines mechanisms to address this
  37. 37. WS-SecureConversation • Participants establish a shared context – Context contains keys/secrets and other information – Can be stateless (state embedded in security context token) • Context established multiple ways – Using token exchange – Having one party create the context – Through negotiation
  38. 38. Policy
  39. 39. Policy Framework Policy Policy Attachment Assertions Policy WSDL
  40. 40. WS-Policy • Framework for expressing Web service capabilities and requirements –Security –Transactions –Reliable messaging –Transports –...
  41. 41. WS-Policy Model • Policy: collection of alternatives; pick one • Alternative: collection of assertions; do all • Assertion: domain-specific behavior –Strongly typed –Arbitrary parameters to behavior
  42. 42. WS-Policy Expressions • May represent a policy in a compact form –Nest operators • All distributes over ExactlyOne –Assertion/@wsp:Optional=‘true’ • An alternative with and an alternative without • Simplification of prior @wsp:Usage=‘xs:QName’ –Policy reference to reuse common expression • Included as is where referenced
  43. 43. WS-Policy Intersections • Do two Web service endpoints have compatible policy? –At design time to “wire together” compatible services –At runtime to select compatible options • Two alternatives are compatible if they at least have the same assertion types
  44. 44. WS-Policy Runtime Intersections
  45. 45. WS-PolicyAttachment • Associate policy with WSDL constructs – Interface-wide policy, e.g., • SOAP version • Transports (and addresses) • Which token to use when signing messages • Which version of transactions (if any) – Message policy, e.g., • Which parts of this message to sign • Whether this message is part of a transaction
  46. 46. WS-SecurityPolicy • A set of policy assertions related to concepts defined by other WS-Sec* specs • Allows participants to specify – Token types – Whether integrity and/or confidentiality are required – Algorithms for the above – Which message parts need signing/encrypting
  47. 47. WS-SecurityPolicy Example <wsp:Policy> <sp:SymmetricBinding> <wsp:Policy> <sp:ProtectionToken> <wsp:Policy> <sp:KerberosV5APREQToken sp:IncludeToken=".../IncludeToken/Once" /> </wsp:Policy> </sp:ProtectionToken> <sp:SignBeforeEncrypting /> <sp:EncryptSignature /> </wsp:Policy> </sp:SymmetricBinding> <sp:SignedParts> <sp:Body/> <sp:Header Namespace="" /> </sp:SignedParts> <sp:EncryptedParts> <sp:Body/> </sp:EncryptedParts> </wsp:Policy>
  48. 48. Federation
  49. 49. WS-Federation • “Single Sign-On” access across trust domains using identities from the different domains • WS-Federation defines a model for this building on the WS-* security specifications: –Model for trust –Sign out messages –Attribute service –Pseudonym service
  50. 50. Federation – Using Tivoli Federated Identity Manager Third-Party Partner Access Partners using Partners using Microsoft® SAML Federated Access Third Party Third-party User WS-Federation/SAML Partners using Liberty WS-Security/WS- Federation/SAML Direct Tivoli Federated Access Identity Manager Web Access / Web SSO User Web SSO Web SSO Web SSO Portal Benefits Service Billing Service Service
  51. 51. Authorization
  52. 52. Authorization (WS-Trust profile) • Authorization service that renders authorization decision and can return entitlements • Authorization attributes could be part of token issue • Built on WS-Trust • Now published as part of WS-Federation spec
  53. 53. Secure, Reliable, Transacted Web Services Service BPEL4WS Composition Composable Reliable Security Transactions Service Messaging Assurances XSD, WSDL, UDDI, Policy, MetadataExchange Description XML, SOAP, Addressing Messaging HTTP, HTTPS, SMTP Transports From joint IBM/MSFT WS Whitepaper at
  54. 54. Importance of Composition • Everything works in combination – Ex: Transaction context works over a reliable connection – Ex: Participants use WS-Security to secure transactions (for all types participants) • Not "reinventing the wheel" for every stack – Code reuse, lower costs, faster time to market – Ex: all resources named using WS-Addressing • The overall system is more stable – Changes don't percolate up the stack – Ex: By using WS-Security, Federation supports all tokens, including future ones
  55. 55. Composable Headers <S:Envelope … > <S:Header> <wsa:ReplyTo> <wsa:Address></wsa:Address> Addressing </wsa:ReplyTo> <wsa:To></wsa:To> <wsa:Action></wsa:Action> <wssec:Security> <wssec:BinarySecurityToken Security ValueType="wssec:X509v3" EncodingType=“wssec:Base64Binary"> dWJzY3JpYmVyLVBlc…..eFw0wMTEwMTAwMD </wssec:BinarySecurityToken> </wssec:Security> Reliability <wsrm:Sequence> <wsu:Identifier></wsu:Identifier> <wsrm:MessageNumber>10</wsrm:MessageNumber> </wsrm:Sequence> </S:Header> <S:Body> <app:TrafficStatus xmlns:app=""> <road>520W</road><speed>3MPH</speed> </app:TrafficStatus> </S:Body> </S:Envelope>
  56. 56. IBM Product Support • WebSphere Application Server 5.0 – Supported WS-Security input spec as a technology preview – WAS 5.02 Supported the first WSS TC committee draft as a partial implementation • WebSphere Application Server 5.1 – Increased support for the first WSS TC committee draft • WebSphere Application Server 6.0 – Supports full OASIS WSS TC Standard v1.1 • Tivoli Federated Identity Manager – WS-Security support – WS-Trust support – WS-Federation support
  57. 57. Standards Summary: Web Services Security Secure Authorization Federation Conversation Security Privacy Trust Policy Message Security SOAP Messaging
  58. 58. References (1 of 4) • OASIS WSS TC Homepage – • Web Services Security: SOAP Message Security – 200401-wss-soap-message-security-1.0.pdf • Web Services Security: Username Token Profile – 200401-wss-username-token-profile-1.0.pdf • Web Services Security: X.509 Certificate Token Profile – 200401-wss-x509-token-profile-1.0.pdf • Schema Files – 200401-wss-wssecurity-secext-1.0.xsd.xsd – 200401-wss-wssecurity-utility-1.0.xsd.xsd
  59. 59. References (2 of 4) • OASIS WSS TC Call for participation & Original Charter – • OASIS WSS TC Revised Charter – after first TC meeting – • OASIS Announcement of public review phase for WS-Security – • OASIS Announcement of WSS voting as a 1.0 standard – • Original DeveloperWorks posting of WS-Security,Roadmap & Addendum – secure/ – secmap/ – • WS-Security License from IBM – • WS-Security License from Microsoft –
  60. 60. References (3 of 4) • OASIS WSS TC Disposition of public review/comments – – • OASIS WSS TC Notes sent to OASIS at submission time – – http://www.oasis- notes.pdf • Statements of implementation – – – – – – – –
  61. 61. References (4 of 4) • OASIS WSS TC Public review comments archive – • OASIS WSS TC Latest “issues list” as of 3/23/2004 –