3.2 XML Signature syntax
advertisement
FOD Financiën Douane & Accijnzen MASP Digital Signature Version 0.08 MASP Version: 0.08 Digital Signature Date: 12/05/2011 30/09/2011 Date: 0.08 Version: Wim Mertens (IBM) Author: FOD Financiën – D&A Owner: FOD Financiën – D&A Customer: 0.1 Document History This document is only valid on the day that it was printed. The authoritive source of this document will be StarTeam. Version Summary of changes 0.01 Initial draft 0.02 Review from Kris Bussers and Stefan Van Assche 0.03 Added interfaces section 0.04 Review from Kris Bussers 0.05 Review from Serge Vereecke 0.06 Discussion with Bart Verhaeghe 0.07 Added feedback from meeting on 21/04/2011 0.08 Added error codes, message part to be signed 0.2 Document Approvals This document requires the following approvals. Signed approval forms will be stored in the project file. Name Title Roger Beekman Program Manager D&A David Jansegers Program Manager IBM Signature Date - 2 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 Table of Contents 0.1 Document History ...................................................................................................................................... 2 0.2 Document Approvals ................................................................................................................................. 2 1. INTRODUCTION ..................................................................................................................................... 4 1.1 1.2 1.3 1.4 1.5 2. DOCUMENT OBJECTIVES ........................................................................................................................... 4 DOCUMENT SCOPE .................................................................................................................................... 4 REFERENCES ............................................................................................................................................. 4 ABBREVIATIONS........................................................................................................................................ 4 GLOSSARY ................................................................................................................................................ 5 CONCEPT .................................................................................................................................................. 7 2.1 DEFINITION ............................................................................................................................................... 7 2.2 MECHANISM.............................................................................................................................................. 7 2.2.1 Step 1: Calculate digest .................................................................................................................... 8 2.2.2 Step 2: Encrypt and sign ................................................................................................................... 8 2.2.3 Step 3: Decrypt and re-calculate digest and compare ...................................................................... 8 3. REALIZATION ......................................................................................................................................... 9 3.1 WS-SECURITY .......................................................................................................................................... 9 3.2 XML SIGNATURE SYNTAX ...................................................................................................................... 10 3.2.1 SignedInfo ....................................................................................................................................... 11 3.2.2 SignatureValue ................................................................................................................................ 12 3.2.3 KeyInfo ............................................................................................................................................ 12 3.3 BINARY SECURITY TOKEN SYNTAX......................................................................................................... 13 3.4 SIGNATURE AND DIGEST USAGE .............................................................................................................. 13 3.4.1 Sender.............................................................................................................................................. 13 3.4.2 Receiver ........................................................................................................................................... 14 3.5 STANDARDS AND ALGORITHMS USED OVERVIEW .................................................................................... 15 3.6 MESSAGE PARTS TO BE SIGNED ............................................................................................................... 15 3.7 ERROR CODES ................................................................................... ERROR! BOOKMARK NOT DEFINED. 4. INTERFACES .......................................................................................................................................... 17 4.1 4.2 4.3 4.4 4.5 4.6 PLDA ..................................................................................................................................................... 17 EMCS ..................................................................................................................................................... 18 NCTS...................................................................................................................................................... 18 MESSAGE EXAMPLES............................................................................................................................... 19 SOAPUI ................................................................................................................................................... 20 OPEN POINTS ........................................................................................................................................... 22 - 3 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 1. Introduction 1.1 Document Objectives This document describes how B2B messages exchanged between the different applications of the MASP program (PLDA, EMCS & NCTS) and economic operators will be digitally signed. The signing of the messages applies to both sent and received messages. This document will answer the following questions: How does the digital signature mechanism work? What algorithms are used on MASP for signing and verifying the messages? What does a concrete message exchange look like? 1.2 Document scope This document will specify the standards and mechanisms used for digitally signing and verifying B2B messages on MASP. It serves as input for the technical implementation of economic operators to exchange digitally signed message with the MASP applications. This version of the document focuses on the following: On a high level explain how the mechanism of digital signature works. Specifying how economic operators need to implement signing and verification of messages in order to communicate with the B2B channel of the different MASP applications 1.3 References Abbreviation [W3_DSIG] Reference http://www.w3.org/TR/xmldsig-core/ Title XML Signature Syntax and Processing (Second Edition) [W3_DSIGFIL] http://www.w3.org/2002/06/xmldsig-filter2 XML-Signature XPath Filter 2.0 [OASIS_WSS] http://www.oasis-open.org/committees/wss/ OASIS Web Services Security (WSS) TC [WIKI_DSIG] http://en.wikipedia.org/wiki/Digital_signature Digital signature [WIKI_CHF] http://en.wikipedia.org/wiki/Cryptographic_hash_function Cryptographic hash function [WIKI_PKI] http://en.wikipedia.org/wiki/Public_key_infrastructure Public key infrastructure [WIKI_XS] http://en.wikipedia.org/wiki/XML_Signature XML Signature [WIKI_RSA] http://en.wikipedia.org/wiki/RSA RSA [WIKI_X509] http://en.wikipedia.org/wiki/X.509 X.509 [WIKI_SOAP] http://en.wikipedia.org/wiki/SOAP SOAP [WIKI_WSS] http://en.wikipedia.org/wiki/WS-Security WS-Security [WIKI_SOAPUI] http://en.wikipedia.org/wiki/SoapUI SoapUI [SOAPUI] SoapUI http://www.soapui.org/ 1.4 Abbreviations Abbreviation B2B Meaning Business to business - 4 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 D&A Customs and Excise EMCS Excise Movement and Control System, MASP Multi Annual Strategic Plan NCTS New Computerised Transit System PLDA Paperless Douane en Accijnzen XML Extensible Markup Language SOAP Simple Object Access Protocol WSS Web Services Security 1.5 Glossary Concept Cryptographic hash function Meaning A cryptographic hash function is a deterministic procedure that takes an arbitrary block of data and returns a fixed-size bit string, the (cryptographic) hash value, such that an accidental or intentional change to the data will change the hash value. The ideal cryptographic hash function has four main or significant properties: it is easy to compute the hash value for any given message, it is infeasible to find a message that has a given hash, it is infeasible to modify a message without hash being changed, it is infeasible to find two different messages with the same hash. Digest The resulting hash value when applying a cryptographic hash function. PKI Public Key Infrastructure (PKI) is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. Public-key cryptography Public-key cryptography refers to a widely used set of methods for transforming a written message into a form that can be read only by the intended recipient or that can be created only by the intended sender. Public key cryptography utilizes two keys, or a key pair, to encrypt and decrypt data. One of the two keys is a private key, which the owner can use to encrypt a message. The encrypted message is sent and the recipient uses the corresponding public key to decrypt it. The process is such that only the holder of the private key can produce a message that when decrypted returns the original content. RSA In cryptography, RSA (which stands for Rivest, Shamir and Adleman who first publicly described it) is an algorithm for public-key cryptography. It is the first algorithm known to be suitable for signing as well as encryption, and was one of the first great advances in public key cryptography. RSA is widely used in electronic commerce protocols, and is believed to be secure given sufficiently long keys and the use of up-to-date implementations. SHA1 In cryptography, SHA-1 is a cryptographic hash function designed by the National Security Agency (NSA) and published by the NIST as a U.S. Federal Information Processing Standard. SHA stands for Secure Hash Algorithm. SHA-1 results in a 160 bit message digest. X509 In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) for single sign-on (SSO) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation - 5 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 algorithm. In the X.509 system, a certification authority issues a certificate binding a public key to a particular distinguished name in the X.500 tradition. XML Canonicalization The creation of XML Signatures is a bit more complex than the creation of an ordinary digital signature because a given XML Document (an "Infoset", in common usage among XML developers) may have more than one legal serialized representation. For example, whitespace inside an XML Element is not syntactically significant, so that <Elem > is syntactically identical to <Elem>. Canonical XML is a profile or subset of XML. Any XML document can be converted to Canonical XML, thus normalizing away specific kinds of minor differences while remaining an XML document. SOAP SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on Extensible Markup Language (XML) for its message format, and usually relies on other Application Layer protocols, most notably Remote Procedure Call (RPC) and Hypertext Transfer Protocol (HTTP), for message negotiation and transmission. SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built. This XML based protocol consists of three parts: an envelope, which defines what is in the message and how to process it, a set of encoding rules for expressing instances of applicationdefined datatypes, and a convention for representing procedure calls and responses. WS-Security WS-Security (Web Services Security, short WSS) is a flexible and feature-rich extension to SOAP to apply security to web services. It is a member of the WS-* family of web service specifications and was published by OASIS. The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security. - 6 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 2. Concept This section explains the high level concept of the digital signature and how it is applied. More detailed information on the different security concepts are mentioned in the glossary. 2.1 Definition A digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or document. Digital signatures will provide data authentication and non-repudiation services. The signer can not claim he did not sign the message A digital signature scheme typically consists of three algorithms: A key generation algorithm that selects a private key uniformly at random from a set of possible private keys. The algorithm outputs the private key and a corresponding public key. A signing algorithm that, given a message and a private key, produces a signature. A signature verifying algorithm that, given a message, public key and a signature, either accepts or rejects the message's claim to authenticity. Two main properties are required. First, a signature generated from a fixed message and fixed private key should verify the authenticity of that message by using the corresponding public key. Secondly, it should be computationally infeasible to generate a valid signature for a party who does not possess the private key. The following section shows how the above algorithms are applied. 2.2 Mechanism The picture below depicts the basic principles of a digital signature. The exact implementation is elaborated in a subsequent section. Figure 1 - Digital signature mechanism - 7 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 2.2.1 Step 1: Calculate digest In a first step a digest (cryptographic hash value) is calculated on the original message to be transmitted. This digest has as a characteristic that it is infeasible to find two different messages with the same hash. If the document is altered in any way the resulting digest will not be equal to the one calculated on the original version. This means it is infeasible to modify the message without the hash being different. 2.2.2 Step 2: Encrypt and sign The calculated digest is then encrypted using a private key. As a result no one except the owner of the private key can replace the encrypted digest, with a digest of their own (public-key cryptography). The encrypted digest represents the digital signature which is added to the original message together with the corresponding public key, allowing the receiver to decrypt the digest. 2.2.3 Step 3: Decrypt and re-calculate digest and compare Upon receiving of the message, the digest is decrypted using the sender’s public key. The resulting digest is then compared to a digest that is calculated by the receiver using the same algorithm as used by the sender. If the digests are equal then the receiver can be sure the message was unaltered during transmission. - 8 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 3. Realization This section lists the different standards/algorithms that will be used to implement the digital signature concept on MASP. 3.1 WS-Security The WS-Security specification proposes a standard set of SOAP extensions. This specification is flexible and is designed to be used as the basis for securing Web services within a wide variety of security models. It provides support for multiple security token formats, multiple signature formats, and multiple encryption technologies to provide integrity or confidentiality. The WS-Security specification defines the usage of XML Signature and XML Encryption. The picture below provides an overview of the web service elements that can be added to the SOAP header. For digital signature we will use the signature and security token blocks. Figure 2 - WS-Security header As the MASP B2B messages are exchanged between traders using SOAP over HTTP, the Web Services Security extension on SOAP will be used in order to specify how the digital signature will be communicated between the MASP applications and the economic operators on the B2B channel. The WS-Security information is passed in a Security element that is included in the SOAP header. The actual digital signature information is stored in a Signature element that is a child of the Security element as shown below. The public key information is stored in the BinarySecurityToken element also a child of the Security element: - 9 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 Figure 3 - WS-Security syntax The specific content of Signature element is elaborated in the next section. 3.2 XML Signature syntax The information needed to verify the digital signature is stored in a Signature element as shown below. Figure 4 - XML signature syntax It contains three blocks: Item 1: A first block which contains algorithm information on the digest(s) calculated against the message together with the actual digest(s) value. It also contains the algorithms used to generate the signature. Item 2: The actual value of the signature, which is the encrypted hash of the entire SignedInfo element (item 1) Item 3: A last section containing the reference to the certificate that needs to be used for the encrypt/decrypt operations The next sections will show what each part of the Signature element is for and which algorithms need to be used when signing or verifying a message. On MASP there will always be only one Signature element present (there is no need for multiple signatures using different keys on different message parts). - 10 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 3.2.1 SignedInfo The SignedInfo element contains information on all security algorithms used as well as the message digest(s). The SignedInfo element contains: A CanonicalizationMethod element which specifies the canonicalization algorithm used to transform the SignedInfo element. For MASP following XML canonicalization algorithm will be used: http://www.w3.org/2001/10/xml-exc-c14n# A SignatureMethod algorithm that needs to be applied to created the actual signature (the encrypted SignedInfo element). For MASP following algorithm will be used: http://www.w3.org/2000/09/xmldsig#rsa-sha1 One or more Reference element(s) which contains the calculated digest(s) and the algorithms used to generate them. Figure 5 - XML SignedInfo syntax 3.2.1.1 Reference The Reference element contains a digest together with the algorithms used to generate that digest. It also contains a reference to the parent element of the XML block that was used to create the digest (this is an URI attribute on the Reference element). There can be multiple Reference elements; this means multiple digests can be created on different parts/sections of the request message. On MASP there can only be one Reference element. The XML element to be signed on MASP will always be the actual business message element, as indicated in the table below. This allows the signing mechanism to be independent of changes to elements/attributes contained in the business message. The element that needs to be signed is depicted below: Interface masp.plda-b2b-v2.wsdl XML element to be signed (including all dependant subelements) open:message xmlns:open="http://www.openuri.org/" MSAMovement.wsdl ie:CD815A, ie:CD818A, ie:CD813A, ie:CD810A, ie:CD837A xmlns:ie="http://emcs.dgtaxud.ec/v10/cd810/ie" masp.ncts-ExternalServiceProvider-v1.wsdl ns1:CC015B, ns1:CC007A, ns1:CC013B, ns1:CC014A, ns1:CC044A, ns1:CC054A, ns1:CC141A xmlns:ns1="http://internal.data.ncts.intl.intrasoft.com" - 11 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 Figure 6 - XML Reference syntax A single Reference element consists of: A Transforms element which specifies algorithm(s) used to transform the content prior to creating the digest. For MASP following XML canonicalization algorithm will be used: http://www.w3.org/2001/10/xml-exc-c14n# A DigestMethod algorithm that needs to be applied to calculate the hash. For MASP following digest method will be used: http://www.w3.org/2000/09/xmldsig#sha1 A DigestValue element which contains the calculated digest. 3.2.2 SignatureValue The SignatureValue element contains the calculated digest of the entire SignedInfo element (Item 1 on the Signature element as shown in Figure 4 - XML signature syntax) encrypted using the private key of the sender. Figure 7 - SignatureValue example 3.2.3 KeyInfo Digital signature and encryption operations require that a public key certificate be specified. For various reasons, the element containing the key in question may be located elsewhere in the message or completely outside the message. The SecurityTokenReference element provides an extensible mechanism for referencing security tokens and other key bearing elements For MASP an X509 public key certificate will be used in order to perform the decryption. The KeyInfo element uses a SecurityTokenReference element which contains a Reference element which points to this key. Figure 8 - KeyInfo syntax The Reference element contains two attributes A URI attribute by which the corresponding BinarySecurityToken element is linked (which contains the actual public key certificate) - 12 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 A ValueType attribute which specifies the format of the public key certificate. For MASP following format will be used: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile1.0#X509PKIPathv1 On MASP there can only be one KeyInfo element. 3.3 Binary Security Token syntax The public key certificate that is needed to decrypt the signature is stored in a BinarySecurityToken. Figure 9 – Binary Security Token syntax A EncodingType attribute indicates how the security token is encoded. For MASP this will be Base64Binary: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security1.0#Base64Binary A ValueType attribute which identifies the type of the security token. On MASP this will be an X509 public key certificate of which the full certificate chain needs to be sent: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile1.0#X509PKIPathv1 A Id attribute which is to be referenced on the Reference element on the KeyInfo element Certificates issued by one of the following certificate authorities are supported: Globalsign: http://www.globalsign.be ISABEL: http://www.isabel.be Certipost: http://www.certipost.be VeriSign: http://www.verisign.com 3.4 Signature and digest usage Following steps are needed for signing or verifying messages sent or received from the MASP applications: 3.4.1 Sender Before sending a B2B message following steps are needed: calculate the digest on the business message element in the SOAP Body use the result of the calculated business message digest in the creation of the Reference element create the SignedInfo element using the above Reference element calculation of the digest of the SignedInfo element encryption of the calculated SignedInfo digest to create the SignatureValue element creation of a KeyInfo element with a reference to the public key certificate that matches the private key used to encrypt the SignedInfo digest add SignedInfo, SignatureValue and KeyInfo to the message - 13 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 Figure 10 - Calculations needed to sign a message 3.4.2 Receiver When receiving a digitally signed message 2 steps are needed to verify the message authenticity. First the authenticity of the SignedInfo element is checked. This is done by comparing the result of: decrypting the digest from the SignatureValue element calculating the digest on the SignedInfo element If both values are equal then we know the SignedInfo element is unaltered and the digest it contains can be used to validate the authenticity of the message Body element. If the values are different that means the signature of the message has been compromised and the authenticity of the SOAP Body cannot be checked. Figure 11 - Verification of the digital signature In a second step the authenticity of the business message element in the SOAP Body is checked. This is done by comparing the result of: The DigestValue from the Reference element calculating the digest on the business message element - 14 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 If both values are equal then we know the business message element received is unaltered. If the values are different that means the authenticity of the business message element has been compromised. Figure 12 - Verification of the message body 3.5 Standards and algorithms used overview The table below contains an overview of the above mention standards and algorithms to be used in the signing and verifying of the digital signatures on MASP: Description Number of signature element Standard/Algorithm Exactly 1 signature element will be present Number of reference elements Exactly 1 reference element will be present and it will reference the business message as defined in 3.2.1.1 XML Signature http://www.w3.org/2000/09/xmldsig# XML Canonicalization algorithm http://www.w3.org/2001/10/xml-exc-c14n# Signature creation algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1 Digest calculation algorithm http://www.w3.org/2000/09/xmldsig#sha1 3.6 Message parts to be signed The table below contains an overview of the message parts that need to be signed. It contains the location and the attribute that needs to be used to indicate the URI of the reference object: Application PLDA Message part to be signed soapenv:Envelope/soapenv:Body/open:submit/open:message/@wsu:Id EMCS soapenv:Envelope/soapenv:Body/msa:submitDraftAADRequest/ie815:CD815A/@wsu:Id EMCS soapenv:Envelope/soapenv:Body/msa:submitReportOfReceiptRequest/ie818:CD818A/@ws u:Id EMCS soapenv:Envelope/soapenv:Body/msa:submitChangeOfDestinationRequest/ie813:CD813A/ @wsu:Id EMCS soapenv:Envelope/soapenv:Body/msa:submitCancellationRequest/ie810:CD810A/@wsu:Id - 15 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 EMCS soapenv:Envelope/soapenv:Body/msa:submitExplanationOfConsignorRequest/ie837:CD837 A/@wsu:Id EMCS soapenv:Envelope/soapenv:Body/msa:submitExplanationOfConsigneeRequest/ie837:CD83 7A/@wsu:Id NCTS soapenv:Envelope/soapenv:Body/ext:submitDeclaration/int:CC015B/@wsu:Id NCTS soapenv:Envelope/soapenv:Body/ext:submitArrivalNotification/int:CC007A/@wsu:Id NCTS soapenv:Envelope/soapenv:Body/ext:submitDeclarationAmendment/int:CC013B/@wsu:Id NCTS soapenv:Envelope/soapenv:Body/ext:submitDeclarationCancellationRequest/int:CC014A/@ wsu:Id NCTS soapenv:Envelope/soapenv:Body/ext:submitUnloadingRemarks/int:CC044A/@wsu:Id NCTS soapenv:Envelope/soapenv:Body/ext:submitRequestOfRelease/int:CC054A/@wsu:Id NCTS soapenv:Envelope/soapenv:Body/ext:submitInformationOnNonArrivedMovement/int:CC141A /@wsu:Id - 16 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 4. Interfaces 4.1 PLDA The current web service of PLDA consists of two operations with each a request and a response message. Figure 13 – Current PLDA web service In order to support error reporting in case the digital signature fails validation, the current operations will be extended with a fault message. The fault will be returned synchronously to the caller. Figure 14 – eSignature PLDA web service The structure of the fault will be as shown below. It contains a callId, which is a unique identifier of the web service call to PLDA (this id should be used in case of problem reporting). It also contains a fault code which identifies the specific error that occurred and a fault description. Figure 15 – Fault structure - 17 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 The table below shows the error codes returned and the description of what went wrong: Code Description UC code V01 There should be exactly 1 BinarySecurityToken present ES-1004 V02 The ValueType attribute on the BinarySecurityToken should be #X509PKIPathv1 ES-1004 V03 There should be exactly 1 signature element present ES-1005 V04 There should be exactly 1 reference element present ES-1005 V05 There should be exactly 1 keyinfo element present ES-1005 V06 RSA signature did not verify ES-1006 V07 Hash values do not match ES-1008 V08 Unable to parse certificate ES-1003 V09 Unknown certificate identifier ES-1003 S01 Failed to establish a backside connection ES-2004 S02 The system was unable to store the message ES-2002 S03 The system was unable find a validation credentials object N/A C01 Trader with certificate: issuer='' and subject='' is not registered ES-1002 C02 Certificate not trusted ES-1007 An unknown error occurred, please contact the helpdesk N/A 4.2 EMCS The current EMCS interface already supports a fault message that can be returned in case of errors so no modification is needed. Figure 16 – EMCS web service 4.3 NCTS The current NCTS interface already supports a fault message that can be returned in case of errors so no modification is needed. Figure 17 – NCTS web service - 18 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 4.4 Message examples This table below contains example messages of a signed request, a signed response and a signed fault: Application Description Message PLDA PLDA PLDA EMCS EMCS NCTS NCTS - 19 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 4.5 SoapUI Testing on digital signatures is not that trivial as a number of complex calculations need to occur on a message in order to produce a correct digital signature. This means the verification cannot be done manually. One way to check the digital signature is by using SoapUI. SoapUI is an Open Source Web Service Testing Tool for Service Oriented Architectures. The free version is capable of generating and checking a digital signature. The picture below shows an example in which a SOAP request is digitally signed by SoapUI and the signed response signature is then in turn checked by SoapUI: Figure 18 – Testing with SoapUI The picture below shows the configuration needed by SoapUI to generate a digital signature as defined on MASP: - 20 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 Figure 19 – SoapUI security settings More information on testing digital signatures with SoapUI can be found on: http://www.soapui.org/SOAP-and-WSDL/applying-ws-security.html - 21 / 22 Document: 533563624 MASP Version: 0.08 Digital Signature Date: 12/05/2011 4.6 Open points Description Not all incoming messages for PLDA need to be signed. We need to be able to distinguish between: Answer Is it possible to sign only the content of the message element in case of the PLDA web service? Possible solution would be using XPATH on the Reference element. - End of Document - - 22 / 22 Document: 533563624
