Reactor
Introduction
FusionAuth Reactor is a powerful suite of features developed to extend FusionAuth’s core functionality.
See the Reactor Feature for a high level description.
A paid edition of FusionAuth is required to enable these features. Learn more about purchasing FusionAuth on the Pricing Page.
Features
Activate Reactor
Once a license is purchased, in order to activate your instance and enable Reactor, log into your Account and copy your License Id.
Then in your FusionAuth instance navigate to and enter your License Id under Start the Reactor.
Note: You may enter your License Id on multiple instances. However, since billing is based upon the total number of monthly active users across all licensed instances it is recommended that you only license those instances you need support for or require Reactor features for.
Immediately after activating, the Status may be Activated, pending connection. This means that the activation was successful, now FusionAuth is just obtaining a secure connection
to Reactor. This may take a minute or two, but should change to Activated, securely connected after refreshing the page.
Breached Password Detection
We collected hundreds of millions of compromised usernames and passwords from numerous breached databases. FusionAuth can now check passwords to ensure that they don’t exist in any of these databases to keep your users' accounts safe from external threats that may be using this same breached data.
This password detection can be configured per tenant to detect vulnerable passwords at account creation and during password changes. You can also optionally enable breach detection during login. Performing breach detection during login may introduce additional latency to the end user. The configurable actions taken when a vulnerability is detected during login are logging for later reporting and analysis, emailing the user with a templated email, and forcing an immediate password change.
To enable and configure this feature navigate to
Detailed documentation on the configuration can be found in the Tenant Documentation and the Breached Password Detection Guide.
Additionally, there is some keen insight into how the Reactor Breached Password Detection is performing on the Reactor page.
High level stats are displayed at the top of the page for the total number of passwords checked, how many vulnerable passwords have been detected, and the number of accounts that have outstanding actions required (users with unresolved vulnerable passwords). If there are any accounts that still need to take action, then a Breached Users search button will appear. Clicking this will take you to the user search page with those users displayed. From there you may investigate each user and perform additional actions, such as forcing a password reset.
At the bottom of the Reactor page is a table with the same stats broken out per tenant.
A new webhook event is available for use with FusionAuth Reactor Breached Password Detection. This event when enabled will be fired during login if the user is using a vulnerable password: User Password Breach (user.password.breach), see Webhook Events for additional information.
Breached Password Detection White Paper
From "Avoiding Catastrophic Business Failure by Using Breached Password Detection", a white paper discussing breached password detection:
Users tend to choose weak passwords, reuse passwords across applications and services, and not use a password manager or two-factor authentication. The most logical solution to this problem is to force users to choose better, more secure passwords. Indeed, today’s complex password policies have evolved in response to users’ bad habits. First, organizations made users change passwords frequently. Users still chose bad passwords, so organizations made them use longer passwords and add numbers and special characters.
Informing a user that their account has been compromised provides a valuable service to that user. Compromised password detection is a safety measure that can protect your users by helping them identify other accounts that may share the same password. It can also help your organization prevent unauthorized access to your systems without requiring any user action—at least until a password leak or insecure password is found.
Get the Breached Password Detection White Paper.
Related Posts
Advanced Registration Forms
Advanced registration forms let you build multi-step, custom registration experiences with no coding required. You can use the administrative user interface to build your forms.
If you use the FusionAuth themed login pages for your application and the default self service registration form doesn’t meet your needs, advanced registration forms can help.
Detailed documentation on the configuration can be found in the Advanced Registration Forms Guide.
It also can improve the registration experience. Whether you want to break a form up into multiple steps, gather user consents, or have the user provide app specific profile data, advanced registration forms can help.
To use advanced registration forms, you must:
-
Create any custom form fields. This is optional, but typical.
-
Assemble the predefined and custom form fields into a series of steps. Then you compose steps into a form.
-
Configure an application to use your form for self service registration.
-
Theme the form to have a cohesive look and feel. This is optional, but highly recommended.
What is the Difference Between Advanced and Basic Registration Forms
FusionAuth has two types of registration forms: basic and advanced. Both of these allow self service registration. Basic registration is only one step; all the fields are displayed on one form. With basic registration, you can mix and match the following user data fields:
-
Birthdate
-
First name
-
Full name
-
Last name
-
Middle name
-
Mobile phone
Any displayed fields can be required for successful registration. You can choose to use a username or an email for your login identifier. A password field is displayed and required.
This is a typical registration page; you can collect information and at the end the user will be associated with the application in FusionAuth and be able to sign in. The look and feel of the registration form can be themed. Validation is limited to having fields be required, though you can also implement additional validation in theme managed client side javascript.
Basic registration forms have a subset of the functionality of advanced registration forms. With advanced registration forms, in addition to registering a user to an application, you can also:
-
Collect additional profile data and store it in FusionAuth.
-
Validate any field on the server in a variety of ways, including matching a regular expression.
-
Use more complicated fields, such as consents and confirmation fields.
-
Break a registration process into a series of less imposing steps.
Related Posts
Connectors
Connectors allow you to connect other sources of user data to your FusionAuth instance. Once the connection is created, you may either:
-
Authenticate the user against the external data source, or
-
Authenticate and migrate the user from the external data source to FusionAuth
Detailed documentation on the proper configuration can be found in the Connectors documentation.
To use Connectors, you must:
-
Configure a Connector. The required information varies depending on the type of Connector. Currently LDAP and HTTP API Connectors are available.
-
Configure the Connector policy for a tenant. This includes the ordering of the Connectors and to which email domains the Connector will apply.
Users log in to FusionAuth normally, but are authenticated against the appropriate Connector rather than the FusionAuth datastore.
What is the Difference Between Connectors and Identity Providers
Identity Providers also allow you to authenticate users against data sources external to FusionAuth. However, with Identity Providers:
-
While you can use a reconcile lambda to migrate data, the Identity Provider always remains the system of record. Connectors are typically part of a migration strategy.
-
Authentication with an Identity Provider typically requires user action. For example, a user clicking a "Login with Google" button. In contrast, users authenticate using Connectors based only on Tenant configuration.
-
With Connectors the API and UI behave as if a user is signing into FusionAuth; with Identity Providers the user is clearly signing into the third party.