1 / 82

Last week…

Last week…. XML-family. XML-Encryption. XML-Encryption. Objective. XML-Encryption structure. Resulting Schema shorthand. <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:KeyName>? <ds:RetrievalMethod>?

caelan
Download Presentation

Last week…

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Last week…

  2. XML-family

  3. XML-Encryption

  4. XML-Encryption

  5. Objective

  6. XML-Encryption structure

  7. Resulting Schema shorthand <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:KeyName>? <ds:RetrievalMethod>? <ds:*>? </ds:KeyInfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData>

  8. Web service security:Part 2

  9. Combining XML-Encryption with XML-Signature

  10. Example Enc & Sig 1: Protecting Integrity of <EncryptedData>(1/2) EncryptedData for SSNo. Ciphered SSNo. Key (1) info belonging to Ciphered SSNo. EncryptedData for Key Encrypted Key to decrypt Ciphered SSNo. Key (2) info belonging to Encrypted Key Signed info refers to Encrypted Data for SSNo. Digest of EncryptedData for SSNo. Signature of SignedInfo Key (3) info to verify Signature

  11. Example Enc & Sig 1: Protecting Integrity of <EncryptedData>(2/2)

  12. <Signature> & <EncryptedData> are detached <Signature> can be removed without being noticed <Signature> can even be replaced: "Signed by David Copperfield" Need Policy: If encrypted, then also signed BTW: what's the order of processing ?? SfE: however...

  13. Example Enc & Sig 2: Encryption follows Signing (1/3) The original Order <Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <Customer id="customer" custNum="A2345"> <FirstName>Fred</FirstName> <MiddleInit>L</MiddleInit> <LastName>Jones</LastName> <CreditCard> <CreditCardType>VISA</CreditCardType> <CreditCardNumber>43343456343566</CreditCardNumber> <CreditCardExpiration>10/08</CreditCardExpiration> </CreditCard> </Customer> </Order>

  14. Example Enc & Sig 2: Encryption follows Signing (2/3) The Order, signed by David Remy <Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <Customer id="customer" custNum="A2345"> <Name . . . /> <CreditCard . . . /> <Signature> <SignedInfo> <CanonicalizationMethod Algorigthm=". . ." /> <SignatureMethod Algorithm=". . ." /> <Reference URI="#customer"> <Transform Algorithm=".../#envelopedSignature" /> <DigestMethod Algorithm=". . ." /> <DigestValue>. . .</DigestValue> </Reference> </SignedInfo> <SignatureValue>. . . </SignatureValue> <KeyInfo> <X509Data> <X509SubjectName>O=MyCompany,OU=Engineering,CN=David Remy</X509SubjectName> </X509Data> </KeyInfo> </Signature> </Customer> </Order>

  15. Example Enc & Sig 2: Encryption follows Signing (3/3) The signed order, <Customer> is element Encrypted <Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <EncryptedData id="encryptedData1" Type="Element"> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . . </CipherValue> </CipherText> <KeyInfo> <EncryptedKey> <EncryptionMethod Algorithm=". . ." /> <CipherText> <CipherValue>. . .</CipherValue> </CipherText> <KeyInfo> <X509Data> <X509Subject>O=HisCompany,OU=Technology,CN=JothyRosenberg</X509Subject> </X509Data> </KeyInfo> </EncryptedKey> </KeyInfo> </EncryptedData> </Order>

  16. ++ Signature, w/t sensitive data, invisible ++ Clear order of processing -- Integrity of EncryptedData isn’t guaranteed EfS: however...

  17. In conclusion • Order of processing SfE • Security Model: SfE or EfS

  18. Order of processing SfE • Problem: What to do 1st, Decrypt or Validate Signature • Solution: additional 'Decrypt Transform' element for XML-Signature

  19. Security Model: SfE or EfS • Depends on context, the specific situation • Specify a Policy • Consider multi-layered approach SfEfS

  20. Summary

  21. XML-family

  22. SAML

  23. Identity

  24. Questions focus around Identity: Who is accessing my network / information? Who is this request from? Who sais this information is correct? Who sent me this confidential information? How do I know it is really the sender? ... Significance of Identity

  25. Trusted Third Party TTP Subject(indiv./entity) Credentials Establishing and using Identity: establishing Identity (1/2) Identity Refer

  26. Trusted Third Party TTP Portable Assertion Authentication: Subject is who she claims to be. Verify: Credentials are legitimately in possession of Subject Identity Subject Credentials Authorization: Subject is allowed to perform action. Verify: Action is allowed by Credentials (rights have been established under control of authority responsible for action) Refer Trust domain NL Trust domain HU Establishing and using Identity: using Identity (2/2) Assertion: “Presenting Credentials when Subject initiates action” Portable Assertion: “Presenting Credentials when Subject initiates action in otherTrust Domain”

  27. Problem

  28. Solution: open federated identity model

  29. Credentials: “Who is this subject” Assertion Statement: “I vouch that this is van Gogh” TravelAgency.com Trust Domain 1 Subject Credentials Federated Identity: ChosenAirline.com Trust Domain 2 Auth. & make travel order Book flight Order car Book flight • SAML: • Communicates Assertions: • Deferred Identity Decisions • SAML Fundaments: • Assertions: XML Schema • Protocols: XML Schema for Request/response pairs • Bindings: Ass.s on transport & messaging standards (currently: SOAP@HTTP(s) ) ChosenHotels.com Trust Domain 4 ChosenRentals.com Trust Domain 3

  30. Summary

  31. Where are we?

  32. SOAP

  33. Objective & Characteristics

  34. Where XML defines the content of a message ... SOAP defines how that data moves from A to B Via a number of standard transport protocols, but ... Extensible to future needs (protocols & standards, functionality) SOAP is for web services... .... what Internet Inter-ORB Protocol (IIOP) is for CORBA .... ... and RMI is for Java Allows Sender & Receiver to support common transport protocol Transport of XML data

  35. Simple Object Access Protocol • It isn't Simple • it doesn't deal with Objects • It's got more to do with transport than Access • from version 1.1: SOAP is no longer an acronym • sometimes: Service-Oriented Architecture (or Application) Protocol

  36. Characteristics • SOAP = XML derivative • Hence character oriented • Hence easier debugging (meta-data describing what is being passed) • Hence firewall friendly • Treat XML messages as service request • Separation between infrastructure & application processing of messages

  37. Supported transport protocols • Number of Transport protocols = 1 • Technically, spec supports expansion to others (UDP, SMTP, JMS, etc.) • Spec Formal binding to HTTP

  38. Structure

  39. Envelope = container to hold XML Data Uniform container, then be carried by variety of transports Applications refer to content Transport refers to envelope Provide transport envelope

  40. SOAP Header • Information about SOAP envelope • Manage the package • Extensibility is located here • SOAP Security (extensions) lives here

  41. SOAP Body • Information about SOAP Content • Containts the message payload, i.e. XML Data • Anything: full purchase order doc, RPC inc. method & parameters

  42. Binding Style :: How to bind XML-elements on physical remote methods & parameters Binding style: RPC versus Document RPC/Encoded: remote invocated procedures, synchronous, design-time binding Encoding Type :: How to encode original objects: Serialization of original object onto hierarchical XML-structure Encoding type: SOAP encoded versus Literal Document/Literal: document processing, asynchronous, run-time binding SOAP binding & encoding

  43. SOAP processing • SOAP Processors are part of application servers • SOAP runtime system acts upon Headers & Bodies • SOAP intermediaries act only upon Headers • Security: authenticate identities, encrypt or decrypt, validate signatures & call-out TTP authorities, ...

  44. WS-Security

  45. WS-Security

  46. Objective

  47. Secure pipe between 2 directly connected endpoints Endpoints usually Application Server Secure IN the pipe, not outside What about, for instance, logging? Comparing Transport vs Message based security contrasts (& complements) transport-based security

  48. Transport based: ... Point-to-point ... Mature, straightforward impl. ... Not granular: entire payload, entire session ... transport dependent Message based: ... End-to-intermediary-to-end ... new, relatively complex, many options ... Very granular: part of payload, single message ... Transport independent Comparing Transport vs Message based security

  49. Characteristics • As flexible as XML • Each message carries own security strategy • Flexibility is strength AND weakness • WS-Security = SOAP security • WS-Security = part of Web Service Security framework

  50. WS-Security structure

More Related