Events
Overview
Britive records the Shared Signals events it accepts or sends, in both directions:
- Received: an event from a transmitter, and the Britive action Britive ran on the user
- Transmitted: a Britive event that Britive sent to a receiver
Each record shows whether the event succeeded. Records are kept for 90 days.
A 202 response to a transmitter means Britive accepted the event, not that the action succeeded. The event record shows the result.
Before You Begin
- A Britive user who can view Shared Signals, for example through TenantAuditorRole or SecurityViewRole. See Permissions.
- For the API, a Britive API token for that user
View Events
Click Admin → Security → Shared Signals → Events.
Each entry shows the event type, the action taken, and whether it succeeded or failed. Expand an entry to see its outcome and the raw event.
Event Fields
The API returns these fields for each event.
| Field | Description |
|---|---|
direction | RECEIVED or TRANSMITTED |
eventUri | The CAEP or RISC event type, for example https://schemas.openid.net/secevent/caep/event-type/session-revoked |
subject | The user the event was about |
action | For a received event, the Britive action that ran. For a transmitted event, the Britive event, such as user.disable |
status | ACCEPTED when the event succeeded, or FAILED |
outcome | Details of the result, such as an error message |
issuerUrl | For a received event, the transmitter’s issuer URL. For a transmitted event, Britive’s issuer, https://<your-tenant-domain> |
receiverUrl | For a transmitted event, the receiver’s endpoint |
receivedAt, processedAt | For a received event, both are when Britive recorded the result. For a transmitted event, when the SET was issued and when the delivery result was recorded |
rawSsfEvent | The event’s claims |
Match Events to the Audit Log
Audit log entries do not name the Shared Signals event that caused them. To link an event to its audit entries, match the user and the time.
Received Events
Britive logs the Britive action with System User as the actor and the user as the target.
| Britive action | Audit entries |
|---|---|
| Force Checkin | admin.access.checkin for each checkout, then admin.access.checkin.all once every check-in is submitted. access.checkin follows for each checkout when its check-in finishes. |
| Force Logout | The same entries as Force Checkin. Ending the user’s sessions is not logged. |
| Disable User | The same entries as Force Checkin, then user.disable |
If the user had no active checkouts, there are no check-in entries, so a Force Logout leaves no audit entry.
To find the transmitter and event behind these entries, find the received event for the same user with a processedAt at about the same time. Its issuerUrl and eventUri name the transmitter and the event.
Transmitted Events
A transmitted event’s action is the audit event type that caused it, such as user.disable. Find the audit entry with that event type for the same user, just before the event’s receivedAt.
Britive also logs other check-ins, such as checkouts that expire, as System User. When one happens at about the same time, the time alone cannot tell them apart.
Troubleshoot
| Symptom | Cause | Fix |
|---|---|---|
| A received event shows as failed | The Britive action could not complete, for example because no Britive user matches the subject | Expand the entry, or read outcome. If no user matches, check the user’s email address, username, user ID, or external ID |
A transmitter got a 400, 403, or 404, and no event appears | Britive rejected the event before processing it | See the Troubleshoot table in Transmitters |
| An event from more than 90 days ago is missing | Records expire after 90 days | Records are not kept longer than 90 days |
Next Steps
- Transmitters: receive events from an identity provider
- Receivers: send Britive events to a SIEM or other receiver