Best practice configuration
Last updated
Last updated
Fortified ID Enrollment app supports several different methods to enroll for strong authentication. Depending on technology used, enrollment is some time also called enroll, register or activate.
The Enrollment application support four different enrollment methods
OATH software tokens. Often used to generate one-time password in an mobile app. Examples of common mobile app are Microsoft Authenticator, Google Authenticator or our own Fortified ID mobile app.
OATH hardware tokens. Often used to generate one-time password in an hardware device. Examples of common hardware devices are YubiKey and Feitian.
Passkeys/FIDO2.
Fortified ID mobile app.
Depending on your needs, you decide which of the above methods you want to use. If you only e.g. need OATH software, then you remove configuration for the three other modules.
In this use case we provide an best practice configuration. All four methods are configured in this use case. If you do not need all four methods, remove configuration for the methods you do not need.
Use this use case as a start for a best practice for your Enrollment app configuration.
This use case only explains the best practise configuration. For more settings or explanation, se product documentation for Enrollment application.
The four methods are called:
OathSwEnrollment (this modules refers to OATH software tokens)
OathHwEnrollment (this modules refers to OATH hardware tokens)
WebAuthnEnrollment (this modules refers to Passkeys/FIDO2)
MobileServerEnrollment (this modules refers to Fortified ID mobile app)
Remove the modules you do not intend to use from the configuration.
When you enroll for a software token you need to store the tokens somewhere. In this use case with use an Microsoft SQL server.
TokensDb. Name of the module. See in example configuration file.
url, username and password for the database. Make sure that you have created the database with the same name as in URL, in our example called /enrollment.
The enrollment application is an SAML service provider (SP), it expects that there is a SAML IdP that handles the authentication.
AuthN. Name of the module. See in example configuration file.
Best practices is to have one AuthN module with one authenticator that all configured modules share.
Since the Enrollment application can host four enrollment methods you could configure each of them to have its own AuthN module or share AuthN module and have one authenticator each. It all depends on your specific environment och use case.
The example configuration includes more configuration and modules covered in this use case. See product documentation for more information.
