-
Notifications
You must be signed in to change notification settings - Fork 0
Event Notifications
The operations directives for each facility requires operators to consult the JLab Authorization Manager (JAM) app at the beginning of each shift. Further, changes made to authorization during an operations period are expected to be communicated to operations staff directly. However, for defense in depth, additional automated notification mechanisms are in place. When various events occur in the app logbook entries and emails are used to notify users. This page summarizes how this works for the four roles: Authorization Watchers, Verification Teams, Facility Managers, and Admins.
An elog entry is created automatically whenever a new Authorization is posted. The ways in which this can happen include:
- An authorizer (generally a Facility Director or designated deputy/backup) posts a new authorization
- A new authorization is automatically posted with reduced permissions
- due to an authorizer's operation permission expiration
- due to a verifier's control verification expiration
- due to a verifier's explicit control verification downgrade
- due to a control verification component downgrade
The automated log entry includes a screenshot of the authorization. The logbook the entry is associated with is determined based on the Facility (configurable).
Whom is notified when authorizer posts a new authorization?
| Watcher | Verifier | Manager | Admin | |
|---|---|---|---|---|
| Authorizer posts new authorization | X | X | X |
Whom is notified when an automated authorization permission reduction is posted?
| Watcher | Verifier | Manager | Admin | |
|---|---|---|---|---|
| Operation authorization expired | X | X | X | |
| Operation authorization revoked due to verification expiration | X | X | X | X |
| Operation authorization revoked due to verification downgrade | X | X | X | X |
| Operation authorization revoked due to component downgrade | X | X | X | X |
Whom is notified of an upcoming authorization permission reduction due to expiration?
| Watcher | Verifier | Manager | Admin | |
|---|---|---|---|---|
| Upcoming operation authorization expiration | X | X | ||
| Upcoming operation authorization revocation due to verification expiration | X | X | X |
- Note A: Watchers and Manager notifications are limited to their associated Facility and Watchers are further limited to associated Operations Type
- Note B: Verifier notifications are limited to authorizations associated the verifier's verifications
- Note C: Downgrades, expirations, and upcoming expirations of verifications that do not reduce the current authorization do NOT generate an email.
- Note D: Upcoming Expiration Notifications are only sent once: 1 week from the expiration date (at midnight of the 7th preceding day). Notably, users are NOT spammed every night with a reminder.
- Note E: Expiration is handled lazily: an expiration check is performed on every request to the app Authorization page. This guarantees that the correct status is returned in the response, but it is non-optimal performance wise as the check is frequently executed. A more performant, yet more complicated (read: buggy) approach requires starting and managing timers for each and every item that can expire. Alternatively if we could fix the time of day of all items that expire to be the same this could be optimized to a single fixed scheduled timer (but I don't think we can restrict time of day of expirations). The midnight scheduled expiration email check is related, but insufficient for replacing the per-request expiration check given arbitrary expiration time-of-day.
Notifications need to be handled carefully during testing to avoid spamming actual users. During development in containers a MailHog email server is used to catch all emails and the containerized Keycloak instance is configured with fake users. There is no containerized logbook server at this time so testing can be performed onsite only with the production logbook server if the Facility logbook is set to TLog.
The internal demo/test server at acctest.acc.jlab.org/jam is the next place testing occurs and a special env named JAM_EMAIL_TESTING can be set with value true in that environment to redirect all non-watcher emails to users in the testlead directory role (Keycloak synced with Red Hat Identity Manager). This includes emails intended for admins, facility managers, and verifiers. Watchers emails are not redirected so be careful whom is configured as a watcher in the test environment. Authorizers do not receive emails so no extra steps are required with them and they can safely be configured in the test environment without fear of spamming them.