Cleaning Up WS-Security With SOAP
SOAP based communication allows us to secure the message (end-to-end security) not just at the transport level (HTTPS). If you want to protect inbound SOAP requests, at the message level, you can use WS-Security. If you have not attempted this in your ServiceNow instance yet, John Anderson's blog post on SOAP into ServiceNow via x509 WS-Security has a helpful tutorial providing all of the steps necessary to configure your instance, and SoapUI.
As a quick summary of John's post:
- Add your certificate to the key store.
- Configure SoapUI to use the key store.
- Create an x509 Certificate record in ServiceNow using the PEM encoded certificate.
- Create a Security Profile that uses the new x509 Certificate.
Submitting your request through SoapUI should return a valid XML payload.
What happens when you need more than one Security Profile?
You guessed it, use a Security Policy. A Security Policy allows the ServiceNow administrator to define how the Security Profiles will be used. Let's assume that you have already configured 2 different Security Profiles (using the knowledge from John's Blog).
Testing the same web service call from our SoupUI project will now fail. SoapUI (Raw) will show:
and the XML response payload will be:
wsse:InvalidSecurity
An error was discovered processing the WS-Security header
No profiles to authenticate
Looking through the log file, we will find the following exception:
SOAP-thread-40 369921984F955E00DF448DF07310C757 WebServiceSecurity: Retrieving Profiles to authenticate
SOAP-thread-40 369921984F955E00DF448DF07310C757 WebServiceSecurity: Authenticating against: First Profile
SOAP-thread-40 369921984F955E00DF448DF07310C757 WebServiceSecurity: Authenticating against: Second Profile
SOAP-thread-40 369921984F955E00DF448DF07310C757 WebServiceSecurity: Authentication failed against: Second Profile
SOAP-thread-40 369921984F955E00DF448DF07310C757 WARNING *** WARNING *** WSSecurity login failed
SOAP-thread-40 369921984F955E00DF448DF07310C757 WARNING *** WARNING *** WS-Security request rejected
SOAP-thread-40 369921984F955E00DF448DF07310C757 Sending response
SOAP-thread-40 369921984F955E00DF448DF07310C757 WARNING *** WARNING *** SOAP Fault:
wsse:FailedAuthenticationThe security token could not be authenticated or authorized
WSSecurity login failed/SOAP-ENV:Fault/SOAP-ENV:Body/SOAP-ENV:Envelope
2016-01-27 11:18:46 (043) SOAP-thread-40 369921984F955E00DF448DF07310C757 Response bytes sent: 218
The next step will be to configure a Security Policy. The Security Policy will define how the Security Profiles should be used.
Then populate the form. In this example, we will use the two Security Profiles listed, and we must authenticate against either one of these.
The last piece of the puzzle is to update the system property "glide.soap.default_security_policy" to let the instance know which policy to use.
Once the property has been updated to point to the desired security policy, SoapUI can, once again, process the request.
To wrap up, we have seen that when we have only one Security Profile, ServiceNow is able to process inbound SOAP requests that require end-to-end security, with no additional configuration. When several Security Profiles exist in your ServiceNow instance, you can manage these different profiles with a Security Policy. The policy defines how these different profiles should be used to authenticate the messages received.
Related Articles:
ServiceNow KB: Inbound Web service Security Configuration (KB0546239)
https://www.servicenow.com/community/grc-blog/cleaning-up-ws-security-with-soap/ba-p/2276058