What are Application Owner Requests?

The, so called, "application owner requests" are a possibility to CRUD data within your business logic with elevated permissions. These actions are then done on behalf of the app-backend owner, which is the account that always exists and has the highest permissions on the data of an app-backend. The functionality exists within ApiOmat Native Modules, as well as in ApiOmat Services, that are attached to an app-backend. In Native Modules, the application owner requests are used by default, because modules are directly bound to the ApiOmat code itself. Services, on the other hand, are encapsulated and only have a loose band to ApiOmat, so application owner requests are disabled by default.

In general modules and services should always have a bounded context and should keep the interactions between each other low to avoid tight coupling and strong dependencies (in favor of decreasing latencies). Especially for static usecases it is best practice to tighten the access flow between modules or services to gain robustness. In contrast to this, ApiOmat needs to handle very dynamic usecases as the application setup is modifiable at runtime by the user. So, ApiOmat provides features with a high level of automation on the one hand and with high restriction regarding accessing data in specific application contexts on the other hand. The application owner request is one way to balance these technical needs that diverge.

The following scenarios describe the circumstances where you may want to use this feature:

Scenario: Accessing Data

Imagine you implemented a Native Module with one class. Your class creation hook method is implemented to first read an object from another module which is also attached to the backend. You need the object to aggregate some of the contained data to set some values on the object that gets created. But the requesting user is not authorized to read the object under usual circumstances.
With activated application owner requests you can just call to get the object of the other module and progress with your business logic.

Scenario: Cronjobs

Imagine you implemented a Service that contains a CronJob. So, for example, your service logic is called within the service periodically to create E-Mail class object which then sends an e-mail. At this point, you have no request, but you'll need write permissions on the backend for the object creation. this can be done by activating the application owner request.

Differences between Native Module and Service

The implementation is depending on the context in which it is used, which means there are differences between the application owner requests in Native Modules and in Services.

Native Module

After you implemented your Native Module you need to upload the code e.g. via maven plugin ( see Upload, Update, Use (JAR) ). This means that your compiled Native Module becomes part of ApiOmat YAMBAS. The Native Module needs to be attached to your ApiOmat application.

By default all requests in Native Modules are authenticated using the application owner. In case you want to authenticate the real request user you can disable the application owner request by enabling the attribute authenticateUser within the Request object in your Native Module Code (see Java documentation for more details).

Service

Since ApiOmat Services are separated from ApiOmat YAMBAS, application owner requests are deactivated by default to ensure secure APIs. To be able to use the application owner requests in services you need to attach the service to your ApiOmat application ( see Development Advanced Topics > Application Owner Request for more details regarding the usage ). In background an access token refresh is done by the implemented service that makes it possible to send requests as application owner to another services.

There is an additional option in ApiOmat Dashboard within the context menu of your attached service to re-initialize the access token exchange:

images/download/attachments/95833711/image2021-4-15_18-1-52.png

After clicking on "Allow Customer Request" the application owner token exchange is initialized again and the service is able to do the access token refreshs. Internally the following sub-process are executed:

1. service client is created (if non-existing) for access token exchange
2. service token is exchanged with application owner token for your application context
3. refresh token is saved as service configuration for your application context

Also keep in mind that after 30 days of inactivity the refresh token gets invalidated automatically by the Secure Token Service (ApiOmat Bouncer). In that case just initialize the access token refresh again by clicking on the button above. Inactivity means, that there was no token refresh within the last thirty days. Either because the service was not running during the thirty days at all, or the service was running, but there was no request for the respective app backend and therefore no token-refresh job running.