Authentication can be implemented in various parts of the application. For REST this can be done when setting up an endpoint or call template.
Authentication for REST endpoints
For REST end point, authentication can be set for each individual end point. It works the same both for REST Data Definitions (GET requests to read data) and REST Processes (for calling processes and modifying data).
It can be found at More > Authentication.
There are three levels of Authentication that all have different functionality and needs.
Service authentication for Novulo REST End points
Service authentication is the primary layer of authentication.
It defines how any user that has access to the URL of the end point, can access the end point.
There are two options (as of April 2024).
- Basic
- Impersonation
Basic authentication for REST endpoints
Basic Authentication is used for HTTP Basic access Authentication using a Novulo username and password - the same as you log on with.
Please note that it must be a username ans password stored in the application you are accessing - it is not linked to SSO access.
The REST End point is then executed with the Rights Profile linked to that user. As the REST End point does not have a GUI, it means that only database rights are used. It means that the end point will not return data or will not be able modify data if the user has no database rights.
Impersonation for REST endpoints
Impersonation makes that end points are publicly available without authentication. The user provided here, is the user that is used in Novulo to execute the end point requests. This is, just like with basic authentication, linked to the rights profile.
Website user authentication
Website user authentication is a second layer of authentication, which is used to provide a Website user with the end point, using Novulo M5167. Website users are designed to be used for your customers and suppliers who are using your website; it is not the same type as a Novulo user.
This is typically used for “My website”-environments. Here, the token stored by the Website user, is provided as a Bearer token in the header UserAuthorization.
When provided, a parameter %website_user becomes available in the context of the REST Definition. This allows you, as a End point developer, to filter out data linked to the contact of this specific Website user. For example, to show order history for a specific customer.
It works together with the Service authentication. Service authentication is strongest and effectively restricting data access. Website user is used on top to distinguish users.
CORS Headers
Cross-origin resource sharing (CORS) is not authentication in the way that it effectively controls access, but it can be used to specify headers which are recognized by all common web browsers.
Entering hosts that may access the end points will then provide the headers, which can also be seen in Postman, but it will not prevent anyone from accessing your end point.
Authentication for REST calls
When using the REST calls via call templates you have a few options. Which option to use is dictated by the service you are trying to call. For any of the below authentication types to work you will have to configure a call account. This call account should be linked on the call template.
No authentication
This option can be chosen when no authentication is required and the service is accesible for anyone.
Basic authentication
Basic authentication uses a username and password to verify the identity of the novulo application. This information can be stored in the username and password field on the call account.
Bearer authentication
Bearer authentication requires a bearer token. This bearer token can be saved in the call account at the bearer token field, and will be sent when making a call.
OAuth 1.0a authentication (one-legged)
OAuth 1.0a uses the username to create a signature
OAuth 2.0 authentication
For Oauth 2.0 authentication you use a refresh token to make a call to a service which will return an access token. This access token in turn is used to make the actual call. In order to set this up you will have to first define the call template for the access token. Next you can add a refresh token to a call account manually.
After setting up the call template for the token, you can fill in the call template for access token on the actual call template used to call the service. See the image below.
