Back end
- 17 Jan 2025
- 3 Minutes à lire
- SombreLumière
- PDF
Back end
- Mis à jour le 17 Jan 2025
- 3 Minutes à lire
- SombreLumière
- PDF
The content is currently unavailable in French. You are viewing the default English version.
Résumé de l’article
Avez-vous trouvé ce résumé utile ?
Merci pour vos commentaires
The back end of the FIDO UAF sample web application exposes the FIDO UAF server functionality via a set of REST APIs. By default, the UAF server is configured to work with the static predefined FIDO Client structures provided by the front end of the FIDO UAF sample web application.
The UAF server provided by the FIDO UAF sample web application can be customized to work with a real FIDO Client and UAF authenticator. To perform a successful integration, you need to adapt the relying party configuration inside the sample/src/main/resources/relyingparty/relyingparty-1.json file and configure the AppId URL, the trusted facets list, and the UAF policy there.
Controllers
The UAF server part of the application is exposed via a set of REST APIs implemented via Spring Rest Controllers. Each controller is in charge of calling the corresponding service layer and wrapping the returned value into a ServerResponse object using UafResponseCreator.
AppIdController
Exposes the trusted facets list endpoint.
Request
GET /uaf/fido-app-facetsResponse
This returns the list of trusted facets configured in the relyingparty-1.json configuration file.
You can configure the AppId URL from the relyingparty-1.json file to link to your fido_sample_web_app_server/uaf/fido-app-facets endpoint.
RegistrationController
Exposes the two-step UAF registration ceremony.
Registration initialize
Request
POST /uaf/registrations/initRequest headers
- fido-app-id: The AppId URL used for performing the registration.
- fido-app-username: The username used for the registration.
Request body
None.
Response
A ServerResponse object including the registration request(uafRequest) and the UAF status code(statusCode) to be passed back to the FIDO Client.
Registration finalize
Request
POST /uaf/registrations/finishRequest headers
None.
Request body
A UafRegistrationResponse object including registrationResponse received from the FIDO Client
Response
A ServerResponse object including the UAF status code (statusCode).
AuthenticationController
Exposes the two step authentication ceremony. The same endpoints are used for transaction signing as well, but with the extra transaction signing info being passed as input.
Authentication/Transaction signing initialize
Request
POST /uaf/authentications/initRequest headers
- fido-app-id: The AppId URL used to perform the authentication/transaction signing.
- fido-app-username: The username used for the authentication/transaction signing.
- fido-transaction-content: The transaction confirmation message string. (needed only in case of transaction signing).
Request body
None.
Response
A ServerResponse object including the authentication/transaction signing request(uafRequest) and the UAF status code(statusCode) to be passed back to the FIDO Client.
Authentication/Transaction signing finalize
Request
POST /uaf/authentications/finishRequest headers
None.
Request body
A UafAuthenticationResponse object including the authentication/transaction signing response received from the FIDO Client.
Response
A ServerResponse object including the UAF status code (statusCode).
DeregisterController
Contains the deregister functionality.
Deregister individual keys
Request
POST /uaf/deregister-keysRequest headers
- fido-app-id: The AppId URL context.
- fido-app-username: The username used for the deregister.
Request body
List of DeregisterAuthenticatorInput(aaid, keyId)
Response
A ServerResponse object including the UAF status code (statusCode).
Deregister user authenticators
Request
POST /uaf/deregister-authenticatorsRequest headers
- fido-app-id: The AppId URL context.
Request body
- DeregisterUserAuthenticators(userId, aaid)
Response
A ServerResponse object including the UAF status code (statusCode).
Services
The sample web application includes three main services, which are responsible for the integration with the OneSpan FIDO UAF SDK and invoking the SDK functions:
- RegistrationService
- AuthenticationService
- DeregisterService
RegistrationService
Registration is a two-step process for both the SDK and the sample web application. The web app calls the Registering.prepareRequest() function for the first step, the Registering.register() function for the second step, and correlates these two requests in one session (see the com.onespan.tid.fido.samplewebapp.application.session.SessionData and com.onespan.tid.fido.samplewebapp.application.session.SessionStorage classes in the sample web application sources).
AuthenticationService
Authentication is also a two-step process. The service calls the Authenticating.prepareRequest() function for the first step, the Authenticating.register() function for the second step, and correlates these two requests within one session (see the com.onespan.tid.fido.samplewebapp.application.session.SessionData and com.onespan.tid.fido.samplewebapp.application.session.SessionStorage classes in the sample web application sources).
DeregisterService
Deregistration is a one-step process, therefore there is no need to implement any session storage. The purpose of this service is to wrap (map) data into the appropriate format (according to the request type) and call the Deregistering.deregister() function with these parameters.
Interface implementation
You need to implement three interfaces for the FIDO UAF SDK to work properly:
AssertionsManager (service: AssertionService)
This interface implementation allows you to manage FIDO protocol classes (accessing, updating, and saving) storage data.
MetadataProvider (service: MetadataServiceInMemory)
This interface implementation provides metadata to the FIDO protocol classes. For more information about FIDO metadata, see FIDO metadata.
The FIDO UAF sample web application implements a loadMetadataFiles() method to load metadata from the resources/metadata folder. To add custom metadata, copy a proper metadata v3 file (JSON) to this folder. The metadata is loaded automatically when the service is started.
- PolicyProvider (service: PolicyManager)
This interface implementation provides the policy to the FIDO protocol classes. The policy defines which authenticators can be used to perform UAF operations.
The sample web application stores data in memory or in files for easier demonstration purposes. We highly recommend to introduce an external storage (for example, a database) in production environments.
Cet article vous a-t-il été utile ?