Server events are triggered by the Curity Identity Server on certain notable occurrences, such as a new user account being created.
They allow Event Listeners to react to such events, implementing custom logic as necessary.
A simple Event Listener may, for example, send out an email every time a new user account is created. A more advanced example, perhaps, would be to send a request to a login analysis service every time a user logs in, such that further action could be taken upon the detection of suspicious login patterns.
This page documents the basic Server Events components, linking to the appropriate parts of the documentation for more details on the different parts of the system.
There are 3 categories of event listeners:
Note
To activate an event listener, it must be added to the list of active Event-listener instances. It is not enough to just create and configure the plugin or script event-listener.
Script EventListeners are scripts that run in reaction to the Server Events they are registered for.
See EventListener procedures for details.
A Script EventListener is appropriate for implementing simpler logic that may even be modified via the server configuration, without requiring a server restart.
EventListener plugins, like script event listeners, perform custom actions in reaction to a Server Event.
EventListener
They should be preferred when the required logic is too complex to be implemented in a script EventListener.
To create an EventListener Plugin, a plugin descriptor must inherit from EventListenerPluginDescriptor.
To learn more about plugins, see the Plugins section.
Besides the EventListener Plugin, it’s also possible to provide event listeners from the following plugin types:
This allows plugins of these types to react when certain events happen, which can be necessary for the plugin to provide its main functionality correctly. For example, the Opt-In MFA action can cleanup MFA user data when one of the account deletion events happen.
An important distinction between Event Listeners provided by the above Plugins is that, unlike those provided by Script and EventListener Plugins, they are scoped to a particular profile, hence will only receive events that are published from the same profile or from a profile that links to it.
For example: events published from a User Management Profile will be received by:
Global events like SystemEvent and DistributedCacheEvent are not received by profile-scoped event listeners.
SystemEvent
DistributedCacheEvent
All Events that can occur in the server are sub-types of the Event interface.
Some notable types are (not mutually exclusive):
TokenOAuthEvent
ProblemOAuthEvent
Most of the above types have several subtypes, and an event may have multiple supertypes. For example, the AccountUpdatedScimEvent is a subtype of both ScimEvent and AuditableEvent.
AccountUpdatedScimEvent
ScimEvent
AuditableEvent
When an EventListener registers to listen for a certain type, it will be notified if any of its subtypes, including itself, are published.
The AccountEvent subtypes happen when an Account Manager acts on the account. However, GraphQLEvent and ScimEvent are not subtypes of AccountEvent since those events may happen without using an Account Manager. For this reason, CreatedAccountEvent and DeletedAccountEvent are not supertypes of AccountCreatedScimEvent and AccountDeletedScimEvent, respectively, nor of AccountCreatedGraphQLEvent and AccountDeletedGraphQLEvent. This means that to reliably listen for events related to accounts may require listening to all 3 types of events: AccountEvent, GraphQLEvent and ScimEvent.
AccountEvent
GraphQLEvent
CreatedAccountEvent
DeletedAccountEvent
AccountCreatedScimEvent
AccountDeletedScimEvent
AccountCreatedGraphQLEvent
AccountDeletedGraphQLEvent
Please check the Event documentation for an up-to-date list of all events.