Mobile Auth / FIDO UAF

In-band Mobile Authentication Realm

#Mobile Authentication #Authentication #Realms

Plugin: nevisadmin-plugin-nevisfido

Sets up In-Band Authentication to protect REST services.

If you want to protect a web application and use mobile authentication from a web browser, use Out-of-band Mobile Authentication instead.

In a nutshell, the pattern configures Nevis for the following use case:

1. The user opens the mobile application and accesses a protected resource, for which they have no authorization yet.
2. The mobile application prompts the user to authenticate.
3. The mobile app sends a request to /auth/fidouaf to authenticate.
4. The user is now authenticated, the mobile application is able to access the protected REST service.

Before executing mobile authentication, the user has to register their mobile device. The required APIs can be set up using In-band Mobile Registration Service pattern.

Application Access Tokens

Tokens assigned here may be created after successful authentication.

To produce and forward a token to an application backend, reference the same token from the application's Additional Settings property.

nevisFIDO

Assign a nevisFIDO instance. This instance will be responsible for providing the in-band authentication services.

Key Store

Assign a pattern which provides the key store for nevisAuth to connect to nevisFIDO with client TLS.

Trust Store

Assign a pattern which provides the trust store for nevisAuth to connect to nevisFIDO.

nevisAuth

The nevisAuth Instance where the authentication flow will be configured.

Key Store

Define the key store to use for 2-way HTTPs connections from nevisProxy to nevisAuth.

Trust Store

Defines the trust store that nevisProxy uses to validate the nevisAuth HTTPs endpoint.

Hostname Validation

Enable to verify that the hostname on the certificate presented by nevisAuth matches the configured hostname in the nevisAuth Instance or nevisAuth Connector pattern.

Internal SecToken Trust Store

Defines the trust store nevisProxy uses for validating the signature of the NEVIS SecToken issued by nevisAuth.

OriginalURL SecretKey

If set, the parameter OriginalUrl.Enable of the IdentityCreationFilter will be set to true and the parameter OriginalUrl.SecretKey to the configured value.

This parameter solves many issues with multiple tabs, multiple frames, and incorrect redirects after login.

Custom Parameters (IdentityCreationFilter)

Add custom init-param elements to each IdentityCreationFilter generated by this pattern.

Most realms generate only 1 IdentityCreationFilter named Authentication_<name>, which is used to protect the application.

Multi-line values, as required for conditional configuration, can be entered by replacing the line-breaks with \n.

Examples:

Key	Value
BodyReadSize	64000
InterceptionRedirect	Condition:ENV:HTTP_USER_AGENT:mozilla|Mozilla\ninitial\nnever
ClientCert	want

Custom Parameters (SecurityRoleFilter)

Add custom init-param elements to the SecurityRoleFilter generated by this pattern.

Multi-line values, as required for conditional configuration, can be entered by replacing the line-breaks with \n.

Custom Parameters (Esauth4ConnectorServlet)

Add custom init-param elements to the Esauth4ConnectorServlet generated by this pattern.

That servlet is called Connector_<name>.

Multi-line values, as required for conditional configuration, can be entered by replacing the line-breaks with \n.

Examples:

Key	Value
EnablePollTerminatedCalls	true

Login Renderer

Choose a login renderer.

In Kubernetes deployments, assignment of a renderer is mandatory.

Assign either a nevisLogrend Instance or a Proxy Login Renderer pattern.

The renderer has to be compatible with the Default Template (see Login Template tab).

In classic VM deployments, a default login renderer will be created when no pattern is assigned.

In case of nevisLogrend, the instance will be called default and deployed on the same host as nevisProxy.

Key Store

Configure a key store to use for 2-way TLS connections to nevisLogrend.

If no pattern is assigned no key store will be created.

The connection will be either 1-way TLS or plain HTTP, depending on the URL of nevisLogrend.

This configuration does not apply when a Proxy Login Renderer is used.

Trust Store

Configure a trust store to use for TLS connections to nevisLogrend.

If no pattern is assigned an automatic trust store will be created.

This configuration does not apply when plain HTTP or the Proxy Login Renderer is used.

Hostname Validation

When enabled the server cert has to match the hostname of nevisLogrend.

This configuration does not apply when plain HTTP or the Proxy Login Renderer is used.

nevisLogrend / Application default.properties

Add or overwrite properties in the default.properties of the nevisLogrend Application.

This is an advanced setting. Use only when there is no other alternative and consider creating a support ticket with your use case.

Check Login Application Configuration for supported properties.

We recommend not overwriting any language related properties, as the languages have to be in sync with nevisAuth. You can configure the supported languages on the nevisAuth Instance.

This setting requires that nevisLogrend is used for GUI rendering. Check the help of Login Renderer for details.

Initial Session Timeout

Define the idle timeout of the initial session. The user must complete the authentication within this time.

Authenticated Session Timeout

Define the idle timeout of an authenticated session.

Max Session Lifetime

Define the maximum lifetime of an authenticated session. The session will be removed after that time even if active.

Update Session Timestamp Interval

Sets the minimum time interval between two updates of the session timestamp.

If the parameter is set to "0", the system will update the session timestamp each time a request accesses a session.

The Initial Session Timeout is used as Update Session Timestamp Interval if it is shorter than the duration configured here.

In-band Mobile Registration Service

#Mobile Authentication #Authentication

Plugin: nevisadmin-plugin-nevisfido

Provides services for In-Band Registration.

For in-band registration no browser is required. All actions are triggered by the mobile app.

The user typically has to click a registration button in the app to get started. On successful registration, credentials are created on the mobile device and in nevisIDM.

A Generic credential is generated as well which makes the mobile device a dispatch target, to which push notifications can be sent. For more information, see Dispatch Target Management.

For the access app this use case is provided for testing purposes only. However, in-band registration may be used in production when using the mobile SDK.

In-band registration requires non-mobile authentication.

This pattern can generate a simple username and password flow into the assigned realm. There are several limitations with this flow:

• the flow cannot be adapted.
• the password must be active and not expired, as there is no support for enforced password change.

For production use cases we recommend configuring your own flow and expose that on a separate path using Standalone Authentication Flow.

Virtual Host(s)

Assign a Virtual Host which shall serve as entry point.

Authentication Realm

Assign an In-band Mobile Authentication Realm or Authentication Realm here.

Assignment is required.

The assigned realm will be used to protect the path /nevisfido/uaf/1.1/request/registration/.

If Authentication Service is enabled, a simple authentication flow will be added to this realm.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign Nevis SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

nevisFIDO

Assign a nevisFIDO instance.

This instance will be responsible for providing the device registration services.

Authentication Service

If enabled, an endpoint will be provided at the Authentication Service Path.

The mobile app may use this endpoint to authenticate and get a cookie.

With this cookie, the registration operation can be initiated.

This is a convenience feature.

The configuration that is generated is similar to the configuration described here. To match this example, the Authentication Service Path should be /auth/pwd but we suggest using a more specific path.

There are several alternatives to how you can provide authentication:

• use Standalone Authentication Flow to provide an authentication endpoint for this realm using authentication steps.
• authenticate the registration operation using the Initial Authentication Flow of the assigned Authentication Realm.

Authentication Service Path

Configure the path of the authentication service.

Client Name

Enter the name of the nevisIDM Client.

Mobile Deregistration Service

#Mobile Authentication #Authentication

Plugin: nevisadmin-plugin-nevisfido

Set up processes required for mobile device deregistration.

The services are called by the mobile app, e.g., when you delete your account in the mobile app.

This use case uses FIDO UAF Credential Deregistration to deregister FIDO credentials.

Virtual Host(s)

A virtual host assigned will be used to expose the protected services.

Authentication Realm

The nevisFIDO APIs required for mobile device deregistration must be protected by In-Band Authentication. The deregistration request service removes the FIDO UAF credentials without challenging the user again, so only the authenticated owner of those credentials may reach it.

Assign an In-band Mobile Authentication Realm here. No other realm type is supported.

Application Access Token

Assign a Nevis SecToken pattern.

This pattern must also be assigned to Application Access Tokens in the Authentication Realm.

nevisFIDO

Assign a nevisFIDO UAF Instance. This instance will be responsible for providing the mobile device deregistration services.

nevisFIDO UAF Connector

#Mobile Authentication #Connector

Plugin: nevisadmin-plugin-nevisfido

Use to connect to an existing nevisFIDO UAF instance.

Use the pattern only when the instance is not set up by the project.

Ensure that the SecToken trust store of the instance allows the SecToken signers used in this project.

Connection URL(s)

Enter URL(s) to connect to your nevisFIDO instance.

The path must be omitted.

Only scheme https:// is allowed.

The scheme is optional which means that you can enter simple host:port pairs (1 per line).

Frontend Address

Enter the address of the Virtual Host where the services of this instance are exposed.

Enter the address without any path component.

Example:

https://example.com

The entered value is used to calculate:

• AppID
• Dispatch payload

The dispatch payload informs the mobile device where to access nevisFIDO for the following use cases:

• Out-of-band Registration
• Out-of-band Authentication

Kubernetes

This setting is used when deploying to Kubernetes only.

Choose between:

• disabled: instance running on a VM.

• same_namespace: service running in the same cluster and namespace.

• other_namespace: service running in the same cluster but in another namespace.

• other_cluster: service running in another cluster.

Namespace

Enter the Kubernetes namespace.

Configuration is required when Kubernetes is set to other_namespace.

nevisFIDO UAF Device Service

#Mobile Authentication

Plugin: nevisadmin-plugin-nevisfido

Exposes the nevisFIDO UAF Device Service on a nevisProxy Virtual Host.

The endpoint is intended to be used by the SDK / Access App only.

Use it to query and update device-specific information such as dispatch targets and authenticators.

Virtual Host(s)

Assign a Virtual Host which shall serve as entry point.

nevisFIDO

Assign a nevisFIDO UAF Instance or nevisFIDO UAF Connector.

Out-of-band Device Management App

#Mobile Authentication #Testing #Experimental

Plugin: nevisadmin-plugin-nevisfido

DEMO/TESTING ONLY - NOT FOR PRODUCTION USE

Provides a simple self-service application for mobile device management. The application is a single page app (SPA) and will be hosted on the Virtual Host at the Frontend Path.

The SPA is not ready for production use. We recommend implementing your own Web application. At least you have to adapt the HTML, CSS, and JavaScript based on your requirements.

The nevisIDM bootstrap user (or any other user with nevisIdm.Root role) can not be used to test the device management as the nevisfido technical user is not allowed to manage credentials of root users.

The SPA sends the following AJAX calls to render a device list:

1a) Get user attributes: GET /nevisidm/api/principal/v1/me (authentic) 1b) Get generic credentials: GET /nevisidm/api/core/v1/100/users/<userExtId>/generic-credentials/ (authentic)

When you then click "Enroll new device", the following API calls are sent:

2a) Generate QR-Code: POST /nevisfido/token/dispatch/registration (authentic) 2b) Poll for completion: POST /nevisfido/status (public)

The QR code is generated by the link-png-qr-code dispatcher. It is configured by the nevisFIDO UAF Instance pattern as soon as a Link Type is set there.

Now you can scan the displayed QR code with the mobile app. This leads to the following calls:

3a) POST /nevisfido/token/redeem/registration (public) 3b) GET /nevisfido/uaf/1.1/facets (public)

The registration is completed with by the mobile app with:

4a) POST /nevisfido/uaf/1.1/registration/ (public)

This pattern exposes the nevisFIDO APIs (2a, 2b, 3a, 3b, 4a) on the Virtual Host itself, so that it also works without an Out-of-band Mobile Registration Service. Only the token dispatch call (2a) is protected by the Authentication Realm, because it contains the user for which the device is enrolled. The other calls are sent by the mobile app, which has no session, and are therefore public.

You must provide the nevisIDM APIs (1a, 1b) by adding an appropriate pattern:

• nevisIDM REST Service or nevisIDM Administration GUI

The same Authentication Realm must be assigned in that pattern. This pattern does not validate that the nevisIDM APIs are set up.

You can combine this pattern with an Out-of-band Mobile Registration Service on the same Virtual Host, as both generate the same connector for the nevisFIDO APIs.

Virtual Host(s)

A virtual host assigned will be used to expose services required for Out-of-band Management Application.

Frontend Path

The path at which the management app shall be accessible at the frontend.

Resources

Upload a ZIP to provide your own resources.

By default, the following resources are provided:

• index.html
• logo.png

Authentication Realm

Configure an authentication realm, which will protect the device management application.

nevisFIDO

Assign a nevisFIDO UAF Instance or a nevisFIDO UAF Connector pattern.

The application uses nevisFIDO to enroll new devices. This pattern exposes the required nevisFIDO APIs on the Virtual Host.

The registration QR code is rendered by the link-png-qr-code dispatcher. That dispatcher is configured by the nevisFIDO UAF Instance pattern as soon as a Link Type is set there, as the QR code contains a link which opens the mobile app.

If you assign a nevisFIDO UAF Connector, the nevisFIDO instance is configured in another project. Make sure that the Link Type is set there, as this cannot be validated here.

Additional Settings

Assign add-on patterns to customize the behavior of this pattern.

Out-of-band Mobile Authentication

#Mobile Authentication

Plugin: nevisadmin-plugin-nevisfido

Sets up Out-of-Band Authentication.

Use as an authentication step in a flow of your Authentication Realm. Typically, this means including this step in the Initial Authentication Flow.

This step can not be used as the first step as the user must be determined before reaching this step. Use any of the following steps in front of this step:

• nevisIDM User Lookup for passwordless authentication,
• nevisIDM Password Login when mobile authentication shall be a second factor.

The user must have a registered mobile app.

Depending on what is selected in the Channel drop-down, the user either has to:

• click a link (shown only on mobile devices),
• scan a QR-code,
• or confirm a push notification sent to the mobile app (with optional number matching).

When this step is done (see On Success), the user will be authenticated, and you can finish the authentication flow or do additional steps.

This step must only be used when the user-agent is a Web browser. To protect REST APIs called by a mobile app use In-band Mobile Authentication Realm instead. Such mobile apps typically embed the Nevis Mobile Authentication SDK.

To use this step, the user must have registered a mobile app and further configuration is required for that. The Out-of-band Device Management App provides an example self-admin page for device registration, while the Out-of-band Mobile Registration Service and In-band Mobile Registration Service patterns only expose the required APIs.

This pattern uses JavaScript (mauth*.js) and other resources, which are included in the default Login Template of the Authentication Realm.

If you are using a custom template you have to ensure that the required resources are used in the same way. Search for mauth in the *.vm files to get started.

Channel

Select how to transfer information to the mobile application.

These channels represent alternative delivery modes. An operation uses either link plus QR-code, or push with a QR-code fallback; one dispatch operation cannot combine push, link, and QR-code delivery.

Link / QR-Code: A QR-code is rendered server-side by nevisFIDO and shown to the user. The user scans the QR code with the camera app or with the mobile app directly. This option uses the link-png-qr-code dispatcher in nevisFIDO. This option uses GUI name mauth_png_qr_link and mauth_png_qr_link.js.

Push / QR-Code: The user receives a push notification on their mobile device. In addition to that, a QR-code is shown which can be scanned instead in case the user does not receive the push notification. This QR-code can be scanned in the mobile app or using the camera app of the mobile device. This option uses GUI name mauth_push_qr and mauth_push_qr.js.

Link / QR-Code (legacy) (deprecated, use Link / QR-Code instead): User can click a link if they are navigating on the same mobile device as the app resides on. A QR-code is rendered client-side via JavaScript and shown to the user. This option uses the link dispatcher in nevisFIDO. This option uses GUI name mauth_link_qr and mauth_link_qr.js.

The link dispatcher is retained for compatibility. The link-png-qr-code dispatcher also returns the link and additionally renders the QR-code server-side, which is more flexible. The GUI descriptor and JavaScript included by the pattern must match the selected dispatcher.

Usernameless Out-of-band Mobile Authentication cannot use push because the user and dispatch target are not known before the operation starts. It therefore uses link plus QR-code only.

If you are using a custom login template, add the correct JavaScript file and some Velocity template snippets.

Download the default template in your Authentication Realm, unpack the zip, and search for mauth to get started.

Number Matching

Enable/disable number matching in case of push notifications. If enabled, a 4-digit number will be displayed on the screen that you have to enter on your mobile device.

By default, it is disabled.

For more information, see Number Matching.

Virtual Host

To complete the operation, the mobile app will send a request to the corresponding nevisFIDO token redeem endpoint: /nevisfido/token/redeem/authentication for authentication, or /nevisfido/token/redeem/registration for onboarding.

The domain is coded into the mobile app and has to be communicated when ordering the app.

We recommend assigning the Virtual Host which serves that domain here so that this pattern can generate the required configuration.

The Virtual Host assigned here will also be considered when calculating the Frontend Address in the nevisFIDO UAF Instance.

On Success

On a successful authentication, the flow will continue with the assigned step.

On Cancel

Assign an authentication step to continue with when the user clicks cancel.

Use to provide a fallback authentication option.

You can change the text on the cancel button by translating the label cancel.button.label.

On Client Failure

When authentication fails due to user behavior, the authentication flow may continue with assigned step.

The authentication may fail due to the following reasons (non-exhaustive list):

• A timeout has occurred
• The authentication itself has failed (for example wrong biometric credential was provided)
• Client errors (e.g. the authenticator chosen did not comply with the policy)

To handle a failure upon sending a push notification, configure On Push Failure instead.

On Dispatch Failure

When a failure occurs during dispatching, the authentication flow will continue with the assigned step.

There are several error cases:

• nevisFIDO is unable to hand out a link or render a QR-code
• the dispatchTargetId sent by the JavaScript does not exist. For instance, the credential may have been deleted in nevisIDM.

User Name

The username is used by nevisFIDO to look up the user in nevisIDM.

Depending on how the nevisFIDO UAF Instance is configured, either the extId or the loginId have to be used.

nevisFIDO

Assign a nevisFIDO UAF Instance pattern. nevisFIDO provides required services for out-of-band authentication.

Key Store

Assign a key store for the TLS connection to nevisFIDO.

If no pattern is assigned, a key store will be provided by automatic key management.

The client certificate in the key store must be trusted by nevisFIDO.

In case both sides use automatic key management, trust can be established automatically and there is nothing to configure.

However, if you are using a different kind of key store, then you must configure Frontend Trust Store in the associated nevisFIDO UAF Instance.

Trust Store

The trust store used to establish a connection with the nevisFIDO component.

The trust store must contain the certificate of the CA that has issued the certificate contained in the Key Store of the nevisFIDO UAF Instance.

In case both sides use automatic key management, trust can be established automatically and there is nothing to configure.

Policy

Enter the name of a policy provided by the assigned nevisFIDO instance.

Read the help of the Policies settings in the nevisFIDO UAF Instance pattern for details.

By default, no policy name is set here and thus the policy default will be used.

You can also enter a nevisAuth or EL expression to determine the policy based on the request or the user session.

Authentication Level

Set an authentication level to apply when authentication is successful.

The level is relevant only if there are is an Authorization Policy assigned to applications.

Out-of-band Mobile Onboarding

#Mobile Authentication #Authentication #Onboarding

Plugin: nevisadmin-plugin-nevisfido

This pattern provides Out-of-Band Registration for mobile authentication.

This pattern can be part of a self-registration sub-flow of an Authentication Realm, or exposed on a separate path using the Standalone Authentication Flow pattern.

This process requires a browser and works as follows:

1. QR code display – A page is rendered using the Login Template of your Authentication Realm. The QR code is rendered client-side via JavaScript (Link / QR-Code (legacy) channel) or generated server-side by nevisFIDO (Link / QR-Code channel).
2. QR code scan – The user scans the QR code with their mobile device:
   • Camera app: The user is redirected to an HTML page with app installation instructions.
   • Mobile app: The registration process continues (step 3).
3. Client-side credential creation – The mobile app generates a client-side credential.
4. Credential registration in nevisIDM – The mobile app ensures the required credentials are created in nevisIDM.
5. Continuation – The process continues with the configured On Success step.

You must configure either a custom URI or a deep link in the nevisFIDO UAF Instance pattern.

The user must have been set in the session (e.g., via nevisIDM User Lookup) before this step is executed. This requirement is not validated during pattern generation because of the variety of possible configurations (e.g., using Generic Authentication Step). Automatic validation may cause false negatives.

If the user cannot be identified, the ERROR message out-of-band mobile onboarding failed. missing username. will be written to the nevisAuth log.

Channel

Select how to transfer information to the mobile application.

Link / QR-Code: A QR-code is rendered server-side by nevisFIDO and shown to the user. The user scans the QR code with the camera app or with the mobile app directly. On mobile devices, a tappable link is shown in addition to the QR code. This option uses the link-png-qr-code dispatcher in nevisFIDO. This option uses GUI name mauth_onboard_png_qr_link and mauth_onboard_png_qr_link.js.

Link / QR-Code (legacy) (deprecated, use Link / QR-Code instead): A QR-code is rendered client-side via JavaScript and shown to the user. On mobile devices, a tappable link is also displayed. This option uses the link dispatcher in nevisFIDO. This option uses GUI name mauth_onboard and mauth_onboard.js.

Link behaviour

For both options the tappable link depends on the Link Type configured in the nevisFIDO UAF Instance:

• Custom URI (myapp://): Opens the app directly. Requires the app to be installed — if it is not, the link leads nowhere.
• Deep Link (https://): Falls back to the browser when the app is not installed. The browser can show an installation page.

Because onboarding typically happens before the app is installed, Deep Link is recommended for this pattern.

You must configure either a custom URI or a deep link in the nevisFIDO UAF Instance pattern.

Frontend Address determination for Link / QR-Code: The frontend address of nevisFIDO is needed to build the redeem_url provided to the mobile app. It is resolved as follows:

1. Frontend Address set on the assigned nevisFIDO UAF Instance or nevisFIDO UAF Connector — used directly.
2. Otherwise, the HTTPS Frontend Address of the single associated Virtual Host is used.

Auto-detection (step 2) fails if:

• No Virtual Host is assigned to this pattern, or
• More than one Virtual Host is assigned.

In these cases, set Frontend Address explicitly on the nevisFIDO pattern.

Virtual Host

To complete the operation, the mobile app will send a request to the corresponding nevisFIDO token redeem endpoint: /nevisfido/token/redeem/authentication for authentication, or /nevisfido/token/redeem/registration for onboarding.

The domain is coded into the mobile app and has to be communicated when ordering the app.

We recommend assigning the Virtual Host which serves that domain here so that this pattern can generate the required configuration.

The Virtual Host assigned here will also be considered when calculating the Frontend Address in the nevisFIDO UAF Instance.

On Success

On a successful authentication, the flow will continue with the assigned step.

On Cancel

Assign an authentication step to continue with when the user clicks cancel.

Use to provide a fallback authentication option.

You can change the text on the cancel button by translating the label cancel.button.label.

User Name

The username is used by nevisFIDO to look up the user in nevisIDM.

Depending on how the nevisFIDO UAF Instance is configured, either the extId or the loginId have to be selected.

This pattern generates an EL expression with fallbacks so ensure all well-known session variables are checked. The order of fallbacks was chosen to follow integrator best practices.

nevisFIDO

Assign a nevisFIDO UAF Instance pattern. nevisFIDO provides required services for out-of-band authentication.

Key Store

Assign a key store for the TLS connection to nevisFIDO.

If no pattern is assigned, a key store will be provided by automatic key management.

The client certificate in the key store must be trusted by nevisFIDO.

In case both sides use automatic key management, trust can be established automatically and there is nothing to configure.

However, if you are using a different kind of key store, then you must configure Frontend Trust Store in the associated nevisFIDO UAF Instance.

Trust Store

The trust store used to establish a connection with the nevisFIDO component.

The trust store must contain the certificate of the CA that has issued the certificate contained in the Key Store of the nevisFIDO UAF Instance.

In case both sides use automatic key management, trust can be established automatically and there is nothing to configure.

Gui Title

The default label for the Gui title is title.signup.mauth.

The default translations for this label are:

• en: Go passwordless
• de: Login ohne Passwort
• fr: Aller sans mot de passe
• it: Vai senza password

Translations for labels can be provided via the Translations tab in your realm pattern.

Policy

Enter the name of a policy provided by the assigned nevisFIDO instance.

Read the help of the Policies settings in the nevisFIDO UAF Instance pattern for details.

By default, no policy name is set here and thus the policy default will be used.

You can also enter a nevisAuth or EL expression to determine the policy based on the request or the user session.

Profile ID Source

Enter a variable expression for the profile ID.

The default works when this step is a follow-up of nevisIDM Password Login or nevisIDM User Lookup.

Out-of-band Mobile Registration Service

#Mobile Authentication #Authentication

Plugin: nevisadmin-plugin-nevisfido

Provides services for Out-of-Band Registration.

The following paths will be exposed:

• /nevisfido/token/dispatch/registration
• /nevisfido/token/redeem/registration
• /nevisfido/uaf/1.1/facets
• /nevisfido/uaf/1.1/registration/
• /nevisfido/status

Out-of-band registration requires a browser and works as follows:

1. The user accesses a Web application which generates a QR code.
2. The user scans the QR code with the mobile app.
3. The mobile app creates a client-side credential.
4. The mobile app calls services provided by this pattern to establish a FIDO UAF credential in nevisIDM.

Alongside the FIDO UAF credential a Generic credential is generated which makes the mobile device a dispatch target, to which push notifications can be sent. For more information, see Dispatch Target Management.

The Web application, which is responsible for QR code generation, is not provided by Nevis. However, you can use the 'Out-of-band Device Management App' pattern to test out-of-band registration.

Virtual Host(s)

Assign the Virtual Host which serves the domain where the nevisFIDO services shall be exposed so that this pattern can generate the required configuration.

The domain is coded into the mobile app and has to be communicated when ordering the app.

The Virtual Host assigned here will also be considered when calculating the Frontend Address in the nevisFIDO UAF Instance.

Authentication Realm

Assign an Authentication Realm to protect the APIs for out-of-band registration.

When the APIs are called by a protected application which is exposed / running on nevisProxy, then you should assign the same realm here.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign Nevis SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

nevisFIDO

Assign a nevisFIDO instance.

This instance will be responsible for providing the device registration services.

Transaction Confirmation Service

#Mobile Authentication #Authentication

Plugin: nevisadmin-plugin-nevisfido

Sets up services for Out-of-band Transaction Confirmation.

This use case typically involves 2 devices.

The transaction confirmation is:

• started on device 1 (e.g. a browser running on a desktop)
• completed on device 2 (e.g. a mobile app).

The pattern provides fine-grained control over which endpoints are exposed in the Endpoints tab.

We recommend starting with the default configuration and then disable any endpoints that you don't need.

Virtual Host(s)

Assign a Virtual Host to expose the enabled endpoints.

Authentication Realm

Optionally assign a realm to protect this application or service.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign Nevis SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

nevisFIDO

Assign a nevisFIDO UAF Instance.

This instance will provide the transaction confirmation services.

Token Dispatch Targets Query Endpoint

Exposes the Query Dispatch Target endpoint /nevisfido/token/dispatch/targets.

This endpoint can be called by an application from device 1 to find out which dispatch targets the user has.

This endpoint should be protected. We provide the option to expose this endpoint as public for testing purposes only. Do not use public for production deployment.

Token Dispatch Endpoints

Exposes the endpoints for token dispatching. These endpoints are called from device 1.

The Dispatch Token Service endpoint /nevisfido/token/dispatch/authentication is called to dispatch a push notification to a mobile app running on device 2.

The Status Service endpoint /nevisfido/status is called to check if the transaction was confirmed by the user on device 2.

Token Redeem Endpoints

Exposes several endpoints that are used by a mobile app running on device 2 to confirm the transaction.

• /nevisfido/token/redeem/authentication
• /nevisfido/uaf/1.1/facets
• /nevisfido/uaf/1.1/authentication

In some setups, the mobile app calls another domain. In this case, you can set these endpoints to disabled and use another pattern to expose these endpoints on another Virtual Host.

Compat Endpoints

Some setups require legacy endpoints to be exposed.

Enable them only if required, e.g., if your device calls any of these endpoints.

The endpoint /auth/fidouaf/authenticationresponse/ is an alias for the Authentication Response Service endpoint /nevisfido/uaf/1.1/authentication on nevisFIDO.

The endpoint /nevisfido/uaf/1.1/authentication/ is imprecise as it also exposes sub-paths. Current apps call /nevisfido/uaf/1.1/authentication (without trailing slash) instead.

Usernameless Out-of-band Mobile Authentication

#Mobile Authentication

Plugin: nevisadmin-plugin-nevisfido

Sets up Out-of-Band Usernameless Authentication.

Use as an authentication step in your Authentication Realm.

This step can be used as the first step as no username has to be entered. Instead, a QR code and a link will be shown.

If you want to show a welcome screen, assign another step in front of this step.

The user must have a registered mobile app and has to scan the QR code to authenticate. If the user is on a mobile device, they can click the link instead.

Push notification is not available for this pattern because the user and dispatch target are not known before the operation starts. This pattern therefore uses the link dispatcher and its mauth_usernameless GUI descriptor.

The Out-of-band Device Management App pattern provides an example self-admin page for app registration, while the Out-of-band Mobile Registration Service and In-band Mobile Registration Service patterns only expose the required APIs.

When this step is done (see On Success), the user will be authenticated, and you can finish the authentication flow or do additional steps.

This step must only be used when the user-agent is a Web browser.

To protect APIs called by a mobile app use In-band Mobile Authentication Realm instead. Your mobile app should use the Nevis Mobile Authentication SDK.

This pattern uses a JavaScript file (mauth_usernameless.js) and other resources, which are included in the default Login Template of the Authentication Realm.

If you are using a custom template you have to ensure that the required resources are used in the same way. Search for mauth_usernameless in the *.vm files to get started.

Virtual Host

To complete the operation, the mobile app will send a request to the corresponding nevisFIDO token redeem endpoint: /nevisfido/token/redeem/authentication for authentication, or /nevisfido/token/redeem/registration for onboarding.

The domain is coded into the mobile app and has to be communicated when ordering the app.

We recommend assigning the Virtual Host which serves that domain here so that this pattern can generate the required configuration.

The Virtual Host assigned here will also be considered when calculating the Frontend Address in the nevisFIDO UAF Instance.

On Success

On a successful authentication, the flow will continue with the assigned step.

On Cancel

Assign an authentication step to continue with when the user clicks cancel.

Use to provide a fallback authentication option.

You can change the text on the cancel button by translating the label cancel.button.label.

On Failure

Assign a step to continue with when the authentication fails.

nevisFIDO

Assign a nevisFIDO UAF Instance pattern. nevisFIDO provides required services for out-of-band authentication.

Key Store

Assign a key store for the TLS connection to nevisFIDO.

If no pattern is assigned, a key store will be provided by automatic key management.

The client certificate in the key store must be trusted by nevisFIDO.

In case both sides use automatic key management, trust can be established automatically and there is nothing to configure.

However, if you are using a different kind of key store, then you must configure Frontend Trust Store in the associated nevisFIDO UAF Instance.

Trust Store

The trust store used to establish a connection with the nevisFIDO component.

The trust store must contain the certificate of the CA that has issued the certificate contained in the Key Store of the nevisFIDO UAF Instance.

In case both sides use automatic key management, trust can be established automatically and there is nothing to configure.

Policy

Enter the name of a policy provided by the assigned nevisFIDO instance.

Read the help of the Policies settings in the nevisFIDO UAF Instance pattern for details.

By default, no policy name is set here and thus the policy default will be used.

You can also enter a nevisAuth or EL expression to determine the policy based on the request or the user session.

Authentication Level

Set an authentication level to apply when authentication is successful.

The level is relevant only if there are is an Authorization Policy assigned to applications.