Audit File

The STS Audit file provides the business (i.e. Privacy, Clinical Informatics, etc) with information on the activity related to the Service Providers.

Using these files the following key data measurements can be obtained:

User activity audits

Service volumes

STS performance metrics

Each server has it own audit file, so in an environment where more than one server processes requests, then all audit files should be reviewed.

Audit File Format

Every user interaction when executing properly will have two events in the audit event:

the beginning of the request when the source system re-directs the user to the STS

the completion of the request when the STS re-directs the user to the Service Provider; this can be successful or a failure (if there is an error in STS processing the request)

 

Fields

Each user interaction will have an event its separate row and are pipe-delimitted “|”.

The fields below are in order as stored in the audit file.

Audit Time Stamp

This segment is actually set in the web.config under the web.config. This will provide the local time as defined in the Windows system format to the millisecond.

Remote Address

This is the client IP address of the user’s browser that is interacting with the STS.

Session ID

This is the unique session ID for the user’s interaction. Keep in mind that the session will remain active, so it is possible that the users can have more than one pair of interaction events.

The session ID is the main correlating factor that allows analysts to perform measurements for transaction times or abandoned requests.

NameID

This is the NameID that was either provided by the source system, or obtained by the STS. This will be provided as part of the SAML request that the Service Provider will be able to audit against.

NameQualifier

This is the NameQualifierthat was either provided by the source system, or obtained by the STS. This will be provided as part of the SAML request that the Service Provider will be able to audit against.

UserContextTimeDate

This the time/date in the supported format that the source system submitted to the STS. This is helpful to determine any significant network latency (to the second) and allows the analyst to correlate the request from the source system if necessary.

UserContextMode

This is a value indicating with UserContextMode is being used. This would be a value from 1 to 5 (as of v1.93).

UserContextID

This is the UserContextID submitted by the source system or the username that was authenticated by the STS (in case of UserContextMode 4 or 5).

UserContextDomain

This is the AD domain of the authenticated UserContextID if UserContextMode 4 was used.

UserContextWorkstation

This UserContextWorkstation value would be the hostname or IP address provided if the source system is using UserContextMode 3.

PatientContextIDType

This is the type of Patient ID being provided by the source system. Values can be “MRN” or “JHN”.

Sanitized PatientContextID

This is the Patient ID provided for Privacy or Security incident audit. Note that this value will not be stored in full and will be processed and sanitized in three modes. See

Configuration Settings for more information.

Sanitized PatientContextLastName

This is the Patient’s Last Name sanitized to protect the PHI.

UAO

This is the UAO value (if applicable) associated with the request.

Status

This provides the status of the request.

Unknown - this is the start of the interaction; at this point, the user identity has not been validated or established.

Success - all processing has been completed and the user has been re-directed to the Service Provider

Failure - there was an error in processing the request and the administrator should review the operational STS log for additional information.

Example

 

2019-04-04 15:54:17,401 56437|10.105.1.221|dmv5zj1mfvb2ze5x5vz5pali|mark|corporate.hospital.on.ca|2019-04-04 16:00:00|2||JHN|635353|Unknown

2019-04-04 15:54:17,439 56475|10.105.1.221|dmv5zj1mfvb2ze5x5vz5pali|mark|corporate.hospital.on.ca|2019-04-04 16:00:00|2||JHN|635353|Success

 

Performance Metrics

In the example below one can calculate the difference in the two time stamps to establish that this STS took 38ms to process the request.