Introduction
The reader is assumed to have knowledge of the following:
...
| Table of Contents |
|---|
Purpose of the API
The Audit Service API is designed to provide a method of programmatically pulling down the audit logs that are visible within the Admin web pages.
...
- A greenID account must be established. This includes specifying the rules to be used, the data sources that will be available, and a range of other configuration options.
- Get the Web Service credentials. These consist of an "account ID" and a Web Service password. These must be obtained from greenID, and used in every Web Service call.
- Consume the WSDL.
GreenID offers two separate environments: test and production. Customers start out in test, where they may carry out their development activities, performing as many test verifications as they like. Once the customer is satisfied with their integration, their account can be activated in the production environment.
How to Use the API
The API has only one method:
retrieveAuditLogs - this method returns the audit logs for a particular verification attempt. All logs related to the specified validation attempt, including calls to external data sources, and any admin activity is returned.
...
See Web Service Endpoints for WSDL details.
API Parameters
A successful audit log request call looks like the following:
| Code Block |
|---|
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://services.registrations.edentiti.com/">
<soapenv:Header/>
<soapenv:Body>
<ser:retrieveAuditLogs>
<accountId>account_id</accountId>
<password>password</password>
<verificationId>pUz9rXAc</verificationId>
</ser:retrieveAuditLogs>
</soapenv:Body>
</soapenv:Envelope> |
The account id and password are the same credentials that Edentiti has given for your account. The verification id is the same code listed under "REF NO" in the admin panel, and is related to a specific customer.
Additionally, filters can be added to the audit log request.
| Code Block |
|---|
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://services.registrations.edentiti.com/">
<soapenv:Header/>
<soapenv:Body>
<ser:retrieveAuditLogs>
<accountId>account_id</accountId>
<password>password</password>
<verificationId>pUz9rXAc</verificationId>
<filter>datasourceattempt</filter>
</ser:retrieveAuditLogs>
</soapenv:Body>
</soapenv:Envelope> |
This will limit the results returned to only verification attempts of a person. The list of filters includes:
- datasourceattempt - verification attempts by a person.
- webservice - webservice calls. This incldues things such as a user being successfully registered, or requesting session tokens.
- statechange - overall state changes of the users verification attempt.
- admin - administration logs related to a single user.
- thirdpartycheck - logging of any third party checks.
More than one filter may be applied. In the event of more than one filter, logs are returned if they match on any of the filters.
Interpreting Results
A single audit log from the Audit Service look like this:
| Code Block |
|---|
<auditlog>
<dateAudited>2014-07-11T13:40:58.335+10:00</dateAudited>
<errorEvent>false</errorEvent>
<eventDescription>A watchlist check against the U.S. Treasury - Office of Foreign Assets Control Specially Designated Nationals List source resulted in no match</eventDescription>
<eventType>system</eventType>
<eventCode>datasourceattempt</eventCode>
<eventStatus>PASSED</eventStatus>
<eventSubCode>OFAC Watchlist</eventSubCode>
<guid>2863bf62-5faf-4200-b214-a75810a71750</guid>
</auditlog> |
Interpreting audit logs
All audit logs have a date, whether or not it is an error event, a description, type, and guid. The event type is either "system", "admin", or "customer". System events are background events, admin events are those created by an administration task, and customer events are generated from customer actions.
...
Possible "webservice" Sub Codes
The sub code for in the webservice logs are contains the methods method name called in the web service. These include:
- registerUser
- registerVerification
- getVerificationResult
- getOneTimeSessionToken
- isUserIdRegistered
Examples are registerVerification and getVerificationResult.
Event Statuses
This field will tell you whether the logged event was successful or not. There are a number of different possible results . For "customer" event type "datasourceattempt" events, the following statuses apply:
- VERIFIED - Success.
- VERIFIED_ADMIN - Verified after admin changes.
- VERIFIED_WITH_CHANGES - Verified with some changes.
- FAILED - Check has failed.
- IN_PROGRESS - User has still not passed that check, indicating that the attempt logged by this log event failed.
- ERROR - Site returned an error, so could not perform check.
- PENDING - Verified from site, but with changed data. Waiting for an admin to approve it.
For background checks, or "system" checks, the following statuses apply:
- AUTOFAIL - Failed an automatic check.
- FAILED - Failed a check.
- NOT_FOUND_ON_LIST - Used for watchlists, could not find the person on the list.
- FOUND_ON_LIST - Used for watchlists, could find the person on the list.
- PASSED - Passed a check.
- ERROR - Site returned an error, so could not perform check.
Other logged events may have a status as well, that will include events in the above lists. An example of that is the "statechange" log event, which can contain the same event statuses as the customer datasourceattempt logs.- refer to the Individual Source States reference table.