Tag Archives: SSL Connection


Basic Authentication vs WS-Security username token

Basic Authentication vs WS-Security username token

Basic-authentication and WS-security username/password authentication both are different and independent.

Basic Authentication
Basic authentication is used in HTTP where user name and password will be encoded and passed with the request as a HTTP header.

POST http://localhost:5565/ws/zzHenry.webServiceSecurity.Provider.providerWSD_http/zzHenry_webServiceSecurity_Provider_providerWSD_http_Port HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: “zzHenry_webServiceSecurity_Provider_providerWSD_http_Binder_debugLog”
Content-Length: 325
Host: localhost:5565
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Authorization: Basic AAAAA=

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/&#8221; xmlns:zzh=”http://localhost/zzHenry.webServiceSecurity.Provider:providerWSD_http”&gt;

Username and password will be encoded using base64 and which is used in authorization header.

The most common to access a webservice hosted in webMethods is using basic authentication. In SOAPUI, at “Authentication” tab, choose “Basic” as authorization type and provide username and password. If you switch to “Raw” format of the request, all the HTTP headers are visible and you can see the Basic Authorization header is highlighted in yellow.

When we use Basic-authentication, the username and password setting is on the HTTP headers not in the SOAP message which might include SOAP header and SOAP body.

WS-Security username token

You can secure webservices using WS-Security username/password authentication mechanism that is a simple mechanism to secure services. It enforces user to provide Username Token security header in the SOAP requests. When create webservice descriptor in webMethods, you need to attach “Username over Transport” policy, this will force Username Token as part of the SOAP request.

To setup WS-Security in SOAPUI, please refer to:

Add client self-signed certificate into keystore.

Add outgoing WS-Security configuration. Below is the sample to add username token as security.
Enter the username/password that has the privilege to access webMethods webservice.
Add timestamp as part of security as this is defined in webMethods policy file.

Apply WS-Security setting to your SOAP request. Open the SOAP request that you want to apply the username token to and click the Authentication tab in the bottom corner and select the outgoing WSS configuration.

Test your request in SOAPUI. Remember to use HTTPS endpoint instead of HTTP.

If you switch to “Raw” format of the request, all SOAP message content is visible and you can see the Username Token in WS-Security is highlighted in yellow.

POST https://localhost:5575/ws/zzHenry.webServiceSecurity.Provider.providerWSD_http/zzHenry_webServiceSecurity_Provider_providerWSD_http_Port HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: “zzHenry_webServiceSecurity_Provider_providerWSD_http_Binder_debugLog”
Content-Length: 1226
Host: localhost:5575
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/&#8221; xmlns:zzh=”http://localhost/zzHenry.webServiceSecurity.Provider:providerWSD_http”&gt;
<wsse:Security xmlns:wsse=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&#8221; xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”&gt;
<wsu:Timestamp wsu:Id=”TS-7991F70E1E3D94C684146294521076478″>
<wsse:UsernameToken wsu:Id=”UsernameToken-7991F70E1E3D94C684146294521076477″>
<wsse:Username>def </wsse:Username>
<wsse:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”>def</wsse:Password&gt;

Execution ACL permission

If you have both username/password in HTTP header and username token in SOAP header, which account will be used to execute webservice in webMethods?

When request comes to webMethods, Integration Server will check if account in HTTP header has the privilege or not. Once account in HTTP header has the permission, then Integration Server use the account in SOAP header to execute the service. In the other words, account in HTTP header should have the permission to access Integration Server while account in SOAP header should have the permission to execute the service.

To test this scenario, you can’t really do it using SOAPUI, use PowerShell instead. It gives more power to manipulate the xml request.

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/&#8221; xmlns:zzh=”http://localhost/zzHenry.webServiceSecurity.Provider:providerWSD_http”&gt;
<wsse:Security xmlns:wsse=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&#8221; xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”&gt;
<wsu:Timestamp wsu:Id=”TS-7991F70E1E3D94C6841462949426574114″>
<wsse:UsernameToken wsu:Id=”UsernameToken-7991F70E1E3D94C6841462949426574113″>
<wsse:Username> def </wsse:Username>
<wsse:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”&gt; def </wsse:Password>

$user = ‘abc’
$pass = ‘abc’
$pair = “$($user):$($pass)”

$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))

$basicAuthValue = “Basic $encodedCreds”

$dict = @{}



[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

$response=Invoke-WebRequest ‘https://localhost:5575/ws/zzHenry.webServiceSecurity.Provider.providerWSD_http/zzHenry_webServiceSecurity_Provider_providerWSD_http_Port&#8217; -Method POST -Body $request -ContentType ‘text/xml; charset=utf-8’ -Headers $dict


To verify it, insert wm build-in service wm.monitor.util:getCurrentUser into your flow service, it will return the account that execute service.

Setup client certificate authentication in webMethods and test with SOAPUI

webMethods has three types of Client Authentication when Integration Server performing requests that arrive on its HTTPS port. One of them is Require Client Certificates, this means Integration Server requires client certificates for all requests.

By using a client certificate, you don’t need to provide user/pin to identify yourself when login to Integration Server.

What is a client certificate?

A client digital certificate or client certificate is basically a file, usually protected with a password and loaded into a client application (usually as PKCS12 files with the .p12 or .pfx extension).

Config Integration Server as an SSL Server

– Generate a public/private key pair using key store explorer. This certification will be used as server certification.

o Select key store type as JKS.

o Enter key pair alias. Use your server domain name as alias.

o Enter key store password. This key store password is important when setup key store in webMethods.


– Install the certificate in Integration Server

o Install the keystore via Security -> Keystore -> Create Keystore Alias on IS’s web frontend.

o To verify the key store has been loaded.

o Install the certificate via Security -> Certificates -> Edit Certificates Settings. Please notice we don’t have truststore setup at the moment and we will setup this up when we create client certificate.

– Add an HTTPS Port in Integration Server:

o Add HTTPS port via Security -> Ports -> Add Port

o Select require client certificate as client authentication methods. Again here we will setup truststore alias later.

o Test the HTTPS connection by navigating to https://localhost:5575 in IE.

The certificate error is ok, because we self-signed our certificate. Add the certificate to the list of trusted certificates and move on. If you use a “real” certificate later, the error will go away.

Config SOPAUI as SSL client

– Similar to generate server certificate, generate a client certificate using key store explorer but choose PKCS #12 as store type

o Select key store type as PKCS #12.

o Enter key pair alias. Use your name and local pc name as alias.

o Enter key store password. This key store password is important when setup key store in SOAPUI.

– Export client certificate and include it in trust store. This is to enable webMethods integration server to accept a self-signed certificate.

o Right click on the key pair, select export -> export certificate chain. Select X.509 as export format.

o Create java key store (.jks) to include the cert that generate in the previous step.

– Config trust store in webMehtods.

o Create truststore via Security -> Keystore -> Create Truststore Alias on IS’s web frontend.

o We should have both keystore and truststore setup in webMethods by now.

o Install the truststore via Security -> Certificates -> Edit Certificates Settings. Select truststore as alias from the drop down list.

o The final step to associate client certificate with a correspondence user in webMethods via Security -> Certificates -> Configure Client Certificates Settings.

– Use client certificate in SOAPUI

o Select the client key store in SOAPUI preference -> SSL settings.

o Test your client cert in SOAPUI! You will find the SSL information in the response.

As I mentioned at the beginning, try to login to IS’s web frontend using HTTPS to see if you were asked for a user/pin!