Skip to content

concept: event handling

Cornelius Kölbel edited this page May 9, 2016 · 16 revisions

Event handling

We can define event handling rules. An event handling rule consists of

  • event (what happens during the HTTP Request) (type: dropdown/list)
  • event dependent condition (type: probably string/free text)
  • action (what needs to happen in case of the event)
    • notify via email
    • notify via SMS
    • block
    • trigger something...
  • choose smtpserver config (action dependent)
  • recipient/ list of recipients (action dependent)

DB Model

  • id (int)
  • ordering - how should we do this? Maybe by storing the id of previous entry. this way we only have to change two entries when reordering one entry
  • event (varchar)
  • handler module (varchar)
  • condition (varchar) It might not make much sense to allow an extra list of conditions, we would have to concatenate this list The condition is defined and evaluated by the handler module
  • action (varchar) The action would also specify some kind of module like "notification" which could contain notification via email or sms Example: "notify"

Second table option contains additional information for an event-handler entry like subaction, parameter1, parameter2...

Use Cases

Each Event is a certain location in the code. The Condition is the required state for the action to be called/performed.

Autoenrollment for first use

  • Event: User has logged in to UI
  • Condition: User has no token
  • Action: Autoenroll a token
  • See: #391

Monitor sensitive accounts

  • Event: Authentication
  • Condition: Authentication failed && user is in importand group/realm
  • Action: notify administrator

PIN Handling

If a token is enrolled, actions can be taken with the PIN

User monitors his tokens

  • Event: Token event like Assign to user, reset/set PIN...
  • Condition: This action was not performed by user but by administrator
  • Action: notify user
  • See: #360

User notification could be done via a configured service, like SMTP server or SMS (currently missing as service?), using avaiable information from userstore (email, mobile number).


Take a look at the python blinker module:

In fact this does not need real events, that trigger some slots.

This event implementation probably can be rather similar to the PolicyObject implementation. But: The condition and the action need be be flexible. In this way the privacyIDEA policies might be seen as a certain form of event handling with fixed condition and action.

We could have a decoratpr @event("name", g or request). Such a decorator should be available to run before and after a request - just like prepolicy and postpolicy.

g or request contain the state to be used for the condition.

Within the event-decorater additional modules get loaded depending on the "name". Or better: All available modules are loaded an each module defines which "name"-event it can handle. This module gets registered for this "name"-event. This way there can be several handling-modules for one event or one handling-module can handle more than one event.

With registering the "name"-events we also know the available conditions.

A handling-module could also register its provided actions.

how can we define consistent "name"-events?

The "name"s in the events should not be defined and two different locations. So is it possible to somehow either gather all names from

@event("name", request)

from the code? Yes it is. The list AVAILABLE_EVENTS is a filled in the Module event.

Pre and Post actions

We should have Pre- and Post-Actions, that are performed before the original event and after it.


Pre and Post could be defined by the handler module itself (an action would always have a defined position) or


An action from a handler module could be either put in pre or post position. Then we would have to extend the database model.

You can’t perform that action at this time.