Authentication Actions are a powerful way to perform additional abilities on top of user authentication. Authentication Actions occur after credential validation but before the authentication concludes. For example, an HTML form authenticator could validate user credentials. Next, Actions could manipulate attributes related to the subject or trigger a second factor, which may be necessary if the subject is authenticating from a new country or outside office hours.
Actions can use the attributes which were fetched or manipulated by preceding Actions. In this way, you can create workflows by using multiple, simple Actions. You can also use these attributes in tokens later on. In this tutorial, we will create a simple workflow using two Actions.
You will need an installation of Curity Identity Server with the basic setup completed. You can achieve this by following our Getting Started Guides. Alternatively, if you have a system up and running with your own configuration, you can use that as well. Just be aware that you probably have different names set for certain components.
In this tutorial we will also use another authenticator, Google Authenticator, for a second factor. However, you can use any authenticator.
Say you have a user authenticating with a username and password — this is one factor. For user accounts registered with an internal email, you want to introduce a second authentication factor, Google Authenticator.
To enable this, you can set up Actions to:
- Fetch all attributes belonging to the Account
- Change the
subjectfrom the username to the email
- Trigger Google Authenticator if the domain of the email is
To fetch the attributes, we will use the
Data Source Action. It uses the attribute query configured for that data source, so we need to set it up. To do so, enter the Admin UI and click on Facilities->Data Sources->default-datasource. Here, set the
Attribute Query to
SELECT * FROM "accounts" WHERE "username" = :subject. NOTE: This query will fetch all attributes, but you can be more specific.
When that is done, open your authenticator called
username-password and click on the plus sign on the login action and choose to create a New Action. Give the Action a name and click on the Data Source action.
Here, select the Attribute Data Source to be
At this point, click the Add button to add a transformer. This transformer will take care of changing the subject to the email. Click on Create transform and then Replace with value from data source. Now fill in all three fields starting from the left:
subject. Finish by clicking on Close.
Next, we must add a second action. This time, add a Multi-Factor Condition. Set the Condition to
subject-condition as we will filter based upon our subject. Next, press Add to create a new condition. First, we need to set which pattern to match against. This pattern is a Regular expression pattern. Since we want all users with an email domain of
email.example.com to authenticate with Google Authenticator as a second factor, set the pattern to
.*@email.example.com. Then, click Select authenticator and select
Google-Authenticator. Finish by clicking on Close.
You can now try out the
username-password login and see how the system behaves when a user attempts to authenticate with or without the
email.example.com domain. You will also notice that the
subject is changed to reflect the email in your issued tokens. For information on how to register new accounts, visit the
Try It Out section of the Getting Started Guides.
In this guide, we quickly looked at using Authentication Actions to achieve MFA. We used the Multi-Factor Condition to trigger the second factor based on a condition, in this case, the email domain. Feel free to explore other conditions you can use. As we have seen, it is also possible to fetch additional attributes, manipulate them, and use them in following Actions. A powerful way to manipulate attributes is by using Script Action.
Curity ships with about 20 pluggable Actions, and more are available on GitHub. You can also create your own Action with the Curity SDK. This guide also explains how to implement your own Authentication Action.
In this article, we focused on using Actions in the
login flow. You can use the same actions in the
sso flow as well.
Let’s Stay in Touch!
Get the latest on identity management, API Security and authentication straight to your inbox.