"Message was not processed: Assertion Falsified (600)" will appear on the Details tab in the Gateway Audit Events.
Has anything changed?
Probably the most important thing to keep in mind when diagnosing fault 600 is to determine if anything has changed. For example, if a particular service has been active for some time, “600 – Assertion Falsified” should not start occurring for no apparent reason. Instead, something has changed. You can right click on the service in the API Gateway and select Revision History to see if any changes have been made to the service in the API Gateway. If there are no recent changes to the service in the API Gateway, this strongly implies something other than the service in the API Gateway either changed or is not working as expected.
The user requesting the operation in the WSDL must be authorized to request the operation (entitled). For example, let's say the WSDL contains an operation called myOperation.
In this example, the user will need to have an entitlement that lets them request myOperation. On the Associated Logs tab in Gateway Audit Events, the entitlements the user has been granted can be viewed. The record usually begins with "Audit ENT" and is just after the "Query LDAP for Entitlements" event. In this example, the user has not been granted access to request myOperation. The user will need to be granted access to the operation being requested.
Following are the most likely things outside of the API Gateway that have either changed or are not working as expected:
- A new version of the app was deployed – always check this first, it’s the most likely cause!
- Something else downstream (eg. app mainframe external calls) is failing or responding with a 500 status.
- Service is being requested using an entitlement that has not been granted access to the service
- SAML token has expired
- SAML failures with Coarse Grained Security