Table of Contents

• Overview
  
• General User Experience
• How MFA Interacts with Other Services
• Basics on Cirrus MFA Management

Overview

Cirrus MFA is intended to be a lightweight multi-factor authentication (MFA) solution. It is intended to be a compromise between single-factor authentication methods, and the feature rich, but individual user licensed, MFA solutions implemented by organizations.  

Multi-factor authentication (sometimes called two-factor authentication, or two-step verification) decreases the chance of an attacker gaining access to institutional data or misusing institutional devices or services by ensuring a user has a second form of authentication. 

Cirrus MFA provides a time-based one-time password (TOTP) capability for the Identity Provider Proxy. When added to the Proxy, MFA is enforced for any of the following login methods:

• Cirrus OrgBrandedID
• Cirrus Gateway
• Other SAML IdPs that do no provide the REFEDS MFA Profile

Which login methods enforce MFA is configurable.

General User Experience

Before end users can enroll in Cirrus MFA, they must have a mobile device, application, or other way to store their MFA token.  One option is a smartphone based app with support for OATH TOTP tokens (such as  Google Authenticator, Microsoft Authenticator, Duo Mobile or Authy). Some password managers also support storage of OATH TOTP tokens (such as BitWarden or Keeper). Once the end user has a MFA application installed, they can proceed with enrollment.

When an end user first attempts to access a Service Provider protected by the Cirrus Proxy, they will be presented with a dialog explaining they are about to enroll with Cirrus MFA. The following is the default configuration for the dialog:

When the end user clicks on “Proceed” they will be taken to the enrollment dialog. The following shows the default presentation for a desktop browser and the expectation is the end user will scan the QR code with the smartphone MFA application.

The end user can also access the secret key by pressing “Show Secret Key” to manually set up the MFA token. This would be used when setting up alternative ways of storing the token, for example using a password manager. The following shows what this looks like after pressing the button:

If the end user is performing the enrollment on a mobile device, there will be a button “Launch Authenticator App” that will pass the token secret directly to the configured app. The behavior after the button is pressed will vary depending on device type (iOS vs Android), and on the browser being used (Chrome vs Firefox vs Safari). 

After the token is enrolled, the end user will be asked to confirm setup by entering the current 6-digit number provided by the configured token. The following shows the entry of the number before proceeding.

Once enrolled, the user will be allowed to access the Service Provider. On subsequent visits to the SP, the end user will be asked to enter the current 6-digit number provided by the configured token.

How MFA Interacts with Other Services

When customers use other services in conjunction with Cirrus MFA, the behavior will be as follows.

Cirrus Gateway

When Cirrus MFA is used with login methods provided by the Cirrus Gateway (for example Google or Microsoft), Cirrus Engineering can configure some or all of the methods to require Cirrus MFA. 

NOTE - this will be independent of any MFA provided by the login method. For example, if an end user has Google 2-Step configured, they will be asked to both perform Google 2-Step as well as the Cirrus MFA.

Cirrus OrgBrandedID

Cirrus OrgBrandedID only implements a single factor credential, unless it is used with Cirrus Proxy and Cirrus MFA. The OrgBrandedID can also be configured to not require MFA, if other IdPs do require MFA.  

Other SAML Federation IdPs

If another SAML IdP signals the REFEDs authentication context, Cirrus MFA will not be invoked. Individual IdPs can also be excluded if needed.

Cirrus Invitation Service

The default behavior for Cirrus Invitation Service is to set up the MFA token before claiming the invitation. 

There are some deployment configurations where the invitation claim will take place before setting up the token, but this is not a common configuration. Please contact support@cirrusidentity.com if there are questions. 

Cirrus Account Linking

The default behavior for Cirrus Account Linking is to set up the MFA token before linking the login method to the secondary identifier.

Basics on Cirrus MFA Management

Overview

Cirrus uses privacyIDEA , a community open-source two factor server, to provide two factor authentication services to customers.

When you log in to privacyIDEA, you will only have access to your own tenants which are called realms in privacyIDEA.

Each organization has 2 realms.

• UAT- for management of tokens and users in UAT 
• Prod - for management of tokens and users in Prod

To update who has access to administer your realms in privacyIDEA, please email support@cirrusidentity.com with the request.  This will create a ticket in our support system which will be seen and serviced by the Cirrus Team.

Basic Functionality in UAT and Prod Realms

1. Delete tokens/users to reset a user

Example: In Cirrus’ test organization, The Athena Institute, I want to delete the token for connie.contrail+gmail.com.  When I log in, I am presented with the active tokens.

Click on the User whose token you want to delete. Example annotated in green below.

You will see a screen similar to below.  Click on the active token.

You will see details about the active token.  Delete the active token.

You will be brought back to the User.  Delete the User.  

The User will be prompted to enroll again the next time they try to authenticate.

2. Review audit information