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://SP11822.jmifa.local: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: SP11822.jmifa.local:5565
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
Authorization: Basic QWRtaW5pc3RyYXRvcjptYW5hZ2U=

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/&#8221; xmlns:zzh=”http://SP12322.jmifa.local/zzHenry.webServiceSecurity.Provider:providerWSD_http”&gt;
<soapenv:Header/>
<soapenv:Body>
<zzh:debugLog>
<input>abcd</input>
</zzh:debugLog>
</soapenv:Body>
</soapenv:Envelope>

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:
https://www.soapui.org/soapui-projects/ws-security.html

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://SP11822.jmifa.local: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: SP11822.jmifa.local: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://SP12322.jmifa.local/zzHenry.webServiceSecurity.Provider:providerWSD_http”&gt;
<soapenv:Header>
<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″>
<wsu:Created>2016-05-11T05:40:10.764Z</wsu:Created>
<wsu:Expires>2016-05-11T05:42:10.764Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken wsu:Id=”UsernameToken-7991F70E1E3D94C684146294521076477″>
<wsse:Username>Administrator</wsse:Username>
<wsse:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”>manage</wsse:Password&gt;
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<zzh:debugLog>
<input>abcd</input>
</zzh:debugLog>
</soapenv:Body>
</soapenv:Envelope>

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.

$request=@”
<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/&#8221; xmlns:zzh=”http://SP12322.jmifa.local/zzHenry.webServiceSecurity.Provider:providerWSD_http”&gt;
<soapenv:Header>
<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″>
<wsu:Created>2016-05-11T07:07:26.574Z</wsu:Created>
<wsu:Expires>2016-05-11T07:12:26.574Z</wsu:Expires>
</wsu:Timestamp>
<wsse:UsernameToken wsu:Id=”UsernameToken-7991F70E1E3D94C6841462949426574113″>
<wsse:Username>Administrator</wsse:Username>
<wsse:Password Type=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText”>manage</wsse:Password&gt;
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<zzh:debugLog>
<input>abcd</input>
</zzh:debugLog>
</soapenv:Body>
</soapenv:Envelope>
“@

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

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

$basicAuthValue = “Basic $encodedCreds”

$dict = @{}
$dict.Add(‘SOAPAction’,’zzHenry_webServiceSecurity_Provider_providerWSD_http_Binder_debugLog’)

$dict.Add(‘Authorization’,$basicAuthValue)

$response=@{Content=”}

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

$response=Invoke-WebRequest ‘https://SP11822.jmifa.local: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

$response.Content

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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s