Skip to content

All about rulesets

As discussed in the previous section, rulesets govern how pools operate.

When looking at a ruleset, there are a few sections which outline how it operates, detailed below.

This is the address that emails to the user will be sent from.

This outlines the various factors that this ruleset implements.

These factors are required to be unique within the pool, and are used to find an identity during authentication. The first factor requested in the flow will be one of these identifying factors, and then the rest of the flow is checking against this identity.

These are the rest of the factors used when authenticating — for example, password.

Prefactor implements a multi-layed approach to security. Methods are combinations of factors which (if correct) should be regarded as “enough” to authenticate. The authentication plans collect factors during the process, then nominate a method to use to authenticate. If an error was made when configuring those plans, it would be caught here.

An authentication plan outlines the steps a user will go through when completing an authentication process. Some are visible steps that will present a screen to the user, others are processing steps that perform tasks against the backend.

For example, if we break down a simple login into its steps it might look something like this:

  1. Check if the user is already authenticated — if they are, skip this whole process
  2. Ask the user for their email address and validate that this corresponds to a registered identity
  3. Ask the user for their password and validate that this matches the identity found in (2)
  4. Log the user in

Prefactor builds up authentication flows from steps like this. In the playground there are a few different flows configured, if you step through you can understand what the user will experience.