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.
Contents
- 1 Audit File Format
- 2 Fields
- 2.1 Audit Time Stamp
- 2.2 Remote Address
- 2.3 Session ID
- 2.4 NameID
- 2.5 NameQualifier
- 2.6 UserContextTimeDate
- 2.7 UserContextMode
- 2.8 UserContextID
- 2.9 UserContextDomain
- 2.10 UserContextWorkstation
- 2.11 PatientContextIDType
- 2.12 Sanitized PatientContextID
- 2.13 Sanitized PatientContextLastName
- 2.14 UAO
- 2.15 Status
- 3 Example
- 4 Performance Metrics
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.