820 likes | 836 Views
This article explores the combination of XML Encryption and XML Signature to provide secure web service communication. It discusses the order of processing, examples of encryption and signing, and the significance of identity in the XML family.
E N D
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>
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
Example Enc & Sig 1: Protecting Integrity of <EncryptedData>(2/2)
<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...
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>
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>
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>
++ Signature, w/t sensitive data, invisible ++ Clear order of processing -- Integrity of EncryptedData isn’t guaranteed EfS: however...
In conclusion • Order of processing SfE • Security Model: SfE or EfS
Order of processing SfE • Problem: What to do 1st, Decrypt or Validate Signature • Solution: additional 'Decrypt Transform' element for XML-Signature
Security Model: SfE or EfS • Depends on context, the specific situation • Specify a Policy • Consider multi-layered approach SfEfS
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
Trusted Third Party TTP Subject(indiv./entity) Credentials Establishing and using Identity: establishing Identity (1/2) Identity Refer
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”
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
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
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
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
Supported transport protocols • Number of Transport protocols = 1 • Technically, spec supports expansion to others (UDP, SMTP, JMS, etc.) • Spec Formal binding to HTTP
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
SOAP Header • Information about SOAP envelope • Manage the package • Extensibility is located here • SOAP Security (extensions) lives here
SOAP Body • Information about SOAP Content • Containts the message payload, i.e. XML Data • Anything: full purchase order doc, RPC inc. method & parameters
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
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, ...
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
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
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