Versions Compared

Old Version 1

changes.mady.by.user Former user

Saved on

compared with

New Version 2

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

Getting Started

In order to start using the Dynamic Forms API, there are several key requirements:
  1. 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.
  2. 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.
  3. 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:

...

See Web Service Endpoints for WSDL details. 

API Parameters

A successful audit log request call looks like the following:

...

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.

...

There is also a sub code, which appears for datasourceattempt logs, as well as for some webservice and admin logs.  This sub code specifies what data source was being queried, or more specifically what occurred.

Possible 'datasourceattempt' Sub Codes

The possible datasourceattempt subcodes describe the data source that was being queried.  The sub code corresponds to the name of a data source as per the names returned via other web services (e.g. NSWRegoDVS, NSWRego, Wp, etc).  When the eventType is "customer" then the attempt was done by the customer.  If the evenType is "system" then the source or watchlist attempt was done in the background without the customer causing the attempt. 

Possible "webservice" Sub Codes

The sub code in the logs contains the method name called in the web service.  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 - refer to the Individual Source States reference table.