Ws-security in SoapUI Pro
In the field of development of various payment gateways and in solving other integration tasks (I don’t think this limits the scope of application of this technology, but I’ve encountered this very area), authentication can occur in the system according to the Ws-security specification (detailed description in docs.oasis- open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf ). This article will consider the case of access to web services, client authentication in which is made according to this specification.
Suppose you exchanged with the system (the system means a payment system or another organization that provides access to web services) with two certificates (one for two-way ssl, the other for signing messages). To do this, the system will require two certificate requests from you. You will need to create two pairs of "certificate request-private key." You can do this, for example, using the openssl utility (download link slproweb.com/products/Win32OpenSSL.html ). You need to run the command twice in it:
(second time privkey2.key and request2.csr respectively). You end up with two pairs of request-key (privkey1.key & request1.csr, privkey2.key & request2.csr). Two certificate requests need to be sent to system analysts; they, in turn, having signed these requests and adding to their vaults, will send you back certificates in the * .crt format to access their system. Let the first pair “request-private key” correspond to the certificate ssl.crt, which will be used to provide two-way ssl, the second pair - trust.crt, this certificate will be used to sign messages.
When we received these certificates, we can check whether the web service is available to us and if everything is correct with the certificates even from the browser. To do this, we need to add a pair of "private key-certificate" in the keystore. In the browser, we will use the pkcs12 storage format. It can be created with the same openssl. The command is as follows:
Naturally, the command must be executed in the directory where the certificate and private key files are located (or write their full path). So, we received a file of the * .p12 format, which contains a pair of "private key-certificate" (from the first pair of ssl.p12, from the second - trust.p12). In order to see which elements are present in the repository, you can use the standard openssl commands, but it is better to use the Keystore Explorer program (http://keystore-explorer.sourceforge.net/). In it, you can set the necessary aliases for identifying certificate-private key pairs, if there are several of them in the repository.
')
Development of a client in a programming language (we implemented in Java and C #), which exchanges messages with web services and implements client authentication in the system, is not considered in this article. At this point, it would be good to check with any tool before the development, if there is any trick in the certificates and whether the signing will work properly.
To verify authentication and signing, we will use SoapUI Pro version 4.5.1. First, we need to add an SSL certificate to the SoapUI settings to provide a secure channel with a web service. In this version of the program, this is done as follows: File -> Preferences -> SSL Settings. I have an English version, so all terms are in English. In the KeyStore field, specify the path to the ssl.p12 repository. In the KeyStore Password field, specify the password that we set when creating the vault. It is impossible to create a vault without a password and this cannot be done, because it contains the private key. Click OK, the SSL configuration is complete.
After that we need to configure the so-called usernametoken, its signature and the signature of the message body. Signing and having a usernametoken is determined on the server by security requirements and the presence of token authentication. About signing in SoapUI is written in sufficient detail on the website of SoapUI itself: www.soapui.org/SOAP-and-WSDL/applying-ws-security.html . Somewhere repeating, somewhere adding my own, I will continue my article.
I) Add the repository to our key-certificate pair to create signatures:
If we do not intend to check for correct signatures of messages that come to us, then nothing needs to be added to Truststores. Here we added the trust.p12 repository, since it was created for signing messages. It is also possible to use repositories of other formats, for example, * .jks (java keystore).
II) Create a configuration to apply to SOAP requests when sending to a web service. To do this, in the Outgoing WS-Security Configurations tab, click on add a new WSS configuration. Call it outgoing.
Iii) Add the usernametoken to the configuration.
If his client number is used as an identifier of a client, then we register the phone number, in a word, the client's login in the system. If there is a password, then you need to select Password Type -> PasswordDigest so that it appears in the message in an encrypted form.
IV) Since it was assumed that we are signing two parts of our SOAP message (usernametoken and Body), we need to create two signatures. To do this, along with the Username, add two Signature elements.
V) The first signature is intended to sign up a UsernameToken:
We set all the settings as in the picture (the settings in your case may differ), the password from the repository, in Parts we prescribe the part of our SOAP message that we are going to sign. Namespace for UsernameToken:
docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
VI) The difference between the second signature (for the Body part of the SOAP message) and the first one only in the Parts part:
Namespace for Body:
schemas.xmlsoap.org/soap/envelope
This completes the authentication setup and signing. It remains to create a SOAP message in SoapUI and select the necessary configuration for it (in terms of outgoing wss):
When sending a message, SoapUI will add a usernametoken and two signatures. In order to see what message is being sent, you can add to the endpoint the name of the service posttestserver.com/post.php , and the response will contain a link to the page with our request. The original SOAP request may be something like this:
A signed request will look like this:
As you can see, we have two signatures <Signature ...> ... and one <wsse: UsernameToken ...> ... </ wsse: UsernameToken>. The first signature refers to the Body, as seen from <ds: Reference URI = "# id-17">, because <soapenv: Body wsu: Id = "id-17" ..., the second to the UsernameToken, because second signature URI = "# UsernameToken-19".
Suppose you exchanged with the system (the system means a payment system or another organization that provides access to web services) with two certificates (one for two-way ssl, the other for signing messages). To do this, the system will require two certificate requests from you. You will need to create two pairs of "certificate request-private key." You can do this, for example, using the openssl utility (download link slproweb.com/products/Win32OpenSSL.html ). You need to run the command twice in it:
openssl req -new -key privkey1.key -out request1.csr(second time privkey2.key and request2.csr respectively). You end up with two pairs of request-key (privkey1.key & request1.csr, privkey2.key & request2.csr). Two certificate requests need to be sent to system analysts; they, in turn, having signed these requests and adding to their vaults, will send you back certificates in the * .crt format to access their system. Let the first pair “request-private key” correspond to the certificate ssl.crt, which will be used to provide two-way ssl, the second pair - trust.crt, this certificate will be used to sign messages.
When we received these certificates, we can check whether the web service is available to us and if everything is correct with the certificates even from the browser. To do this, we need to add a pair of "private key-certificate" in the keystore. In the browser, we will use the pkcs12 storage format. It can be created with the same openssl. The command is as follows:
openssl pkcs12 -export -in ssl.crt -inkey privkey1.key -out ssl.p12Naturally, the command must be executed in the directory where the certificate and private key files are located (or write their full path). So, we received a file of the * .p12 format, which contains a pair of "private key-certificate" (from the first pair of ssl.p12, from the second - trust.p12). In order to see which elements are present in the repository, you can use the standard openssl commands, but it is better to use the Keystore Explorer program (http://keystore-explorer.sourceforge.net/). In it, you can set the necessary aliases for identifying certificate-private key pairs, if there are several of them in the repository.
')
Development of a client in a programming language (we implemented in Java and C #), which exchanges messages with web services and implements client authentication in the system, is not considered in this article. At this point, it would be good to check with any tool before the development, if there is any trick in the certificates and whether the signing will work properly.
To verify authentication and signing, we will use SoapUI Pro version 4.5.1. First, we need to add an SSL certificate to the SoapUI settings to provide a secure channel with a web service. In this version of the program, this is done as follows: File -> Preferences -> SSL Settings. I have an English version, so all terms are in English. In the KeyStore field, specify the path to the ssl.p12 repository. In the KeyStore Password field, specify the password that we set when creating the vault. It is impossible to create a vault without a password and this cannot be done, because it contains the private key. Click OK, the SSL configuration is complete.
After that we need to configure the so-called usernametoken, its signature and the signature of the message body. Signing and having a usernametoken is determined on the server by security requirements and the presence of token authentication. About signing in SoapUI is written in sufficient detail on the website of SoapUI itself: www.soapui.org/SOAP-and-WSDL/applying-ws-security.html . Somewhere repeating, somewhere adding my own, I will continue my article.
I) Add the repository to our key-certificate pair to create signatures:
If we do not intend to check for correct signatures of messages that come to us, then nothing needs to be added to Truststores. Here we added the trust.p12 repository, since it was created for signing messages. It is also possible to use repositories of other formats, for example, * .jks (java keystore).
II) Create a configuration to apply to SOAP requests when sending to a web service. To do this, in the Outgoing WS-Security Configurations tab, click on add a new WSS configuration. Call it outgoing.
Iii) Add the usernametoken to the configuration.
If his client number is used as an identifier of a client, then we register the phone number, in a word, the client's login in the system. If there is a password, then you need to select Password Type -> PasswordDigest so that it appears in the message in an encrypted form.
IV) Since it was assumed that we are signing two parts of our SOAP message (usernametoken and Body), we need to create two signatures. To do this, along with the Username, add two Signature elements.
V) The first signature is intended to sign up a UsernameToken:
We set all the settings as in the picture (the settings in your case may differ), the password from the repository, in Parts we prescribe the part of our SOAP message that we are going to sign. Namespace for UsernameToken:
docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
VI) The difference between the second signature (for the Body part of the SOAP message) and the first one only in the Parts part:
Namespace for Body:
schemas.xmlsoap.org/soap/envelope
This completes the authentication setup and signing. It remains to create a SOAP message in SoapUI and select the necessary configuration for it (in terms of outgoing wss):
When sending a message, SoapUI will add a usernametoken and two signatures. In order to see what message is being sent, you can add to the endpoint the name of the service posttestserver.com/post.php , and the response will contain a link to the page with our request. The original SOAP request may be something like this:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header/> <soapenv:Body wsu:Id="id-17" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <findSomething/> </soapenv:Body> </soapenv:Envelope> A signed request will look like this:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <ds:Signature Id="SIG-21" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#id-17"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <InclusiveNamespaces PrefixList="" xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>wU/JToBU67+gCBtfb2+gYL1w9zY=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>Ez94qqmkV642l3jIy+8PS8lozO+VtEbMZvYZv3inNV4QCZBsRCmQ9IvGcUhfMXnDlqukXaa+zRwr dW8tVOW9vkc9DVgzeFGMSREvP2BUuqB6HzZKCGeec3Jihlc59EyuHwyiz5+18jObuyD18Mtb7T90 7adQsDVSBmQGLydX/tfptopmykYfUpRYTh0sMCcRH7J4B51RrecBs6rK9GJEslWTeW2tGgxpxQJ4 Y690rzkrR6AT6h7t4HBD6JltQUi9xwsjpnQ0j0ReSiK+jNNf99pBl7iiEPc9Kzrc8vNKRacbTfm4 /EE9xP6qu61hBxFQpmpWTRt+SmvVCkDOkBAGew==</ds:SignatureValue> <ds:KeyInfo Id="KI-7D1A45FAAA5C9F47FD138788868310035"> <wsse:SecurityTokenReference wsu:Id="STR-7D1A45FAAA5C9F47FD138788868310036"> <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">lPhvPtZSH+7TfXO2TMEIe0jlDQw=</wsse:KeyIdentifier> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> <ds:Signature Id="SIG-20" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#UsernameToken-19"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <InclusiveNamespaces PrefixList="soapenv" xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>Bbt473ZLc41VKtiEZbMI+q+sFZY=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>F/K6Lgw3P40hFo1ifYY894V5HpVCvns8P4mbeR9pZfTVg4MH/hZf0+KKfKnURTTwS8Rw9MlOM9gG rwkk0hEANxraZHcMIuopWJlvf6sBkykyVSgrAFCHhqjVdAb7bacv7P6U4wHjY1PNRFWMYSUavewq KN08xp80lH30SEMIZznKX6pUuRBllEUTIvRMaR62z1GcNkLWLf5hadUGbv8Qdssj1BL5SY2zin3d hAPFlobMzMUVh019h4Eg0ljWrtFAhHZMOJouZKVYr6ldsPaMiIm9QYTArPoh4fH/rdIIiDT6SVHr e8v0fdywWnapepGyFDJa1ltUXw+JrqBm579PsQ==</ds:SignatureValue> <ds:KeyInfo Id="KI-7D1A45FAAA5C9F47FD138788868306932"> <wsse:SecurityTokenReference wsu:Id="STR-7D1A45FAAA5C9F47FD138788868306933"> <wsse:KeyIdentifier EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier">lPhvPtZSH+7TfXO2TMEIe0jlDQw=</wsse:KeyIdentifier> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> <wsse:UsernameToken wsu:Id="UsernameToken-19"> <wsse:Username>9035153503</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">sTK/zTQP+BthB9Ag9uYsPXCn2Q8=</wsse:Password> <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">wuPL8u2jN8p3T4u0oAZTiQ==</wsse:Nonce> <wsu:Created>2013-12-24T12:38:03.065Z</wsu:Created> </wsse:UsernameToken> </wsse:Security> </soapenv:Header> <soapenv:Body wsu:Id="id-17" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <findAllPersonalAccounts/> </soapenv:Body> </soapenv:Envelope> As you can see, we have two signatures <Signature ...> ... and one <wsse: UsernameToken ...> ... </ wsse: UsernameToken>. The first signature refers to the Body, as seen from <ds: Reference URI = "# id-17">, because <soapenv: Body wsu: Id = "id-17" ..., the second to the UsernameToken, because second signature URI = "# UsernameToken-19".
Source: https://habr.com/ru/post/207480/
All Articles