Created by Jakub Ukrop, last modified on Nov 25, 2022

One of the responsibilities of backoffice-manager is providing data of all domains to the backoffice front-end (BOFE).

  • backoffice-manager is meant to be the ONLY backend component BOFE communicates with

  • E.g. when BOFE needs customer info if calls backoffice-manager and only that one calls customer-manager (service-to-service)

    • This we call “endpoint proxy-ing”

  • The proxied endpoints do not store any data in backoffice-manager

In some domains there are endpoints prefixed by /admin (like customer-manager) and these are dedicated endpoints to be used only by the Backoffice (BE).

However it is not a general rule and it’s ok to proxy also non-admin endpoints.

APIs

Naming

The proxy endpoint should mirror the name of the original endpoint

For example

GET customer-manager/v2/address-catalogue/areas/{areaId}/children

should be proxied as

GET backofice-manager/customer-proxy/v2/address-catalogue/areas/{areaId}/children

Extra functionality

The proxy endpoints are meant to behave the same as the original proxied endpoints in other managers. The exceptions to this rule are documented here

Permissions

The proxy endpoints have, in general, only one extra functionality - they check BO user permissions.

For more details see Access-control

Bank user info limitations

The /bank-user/v2/{uid} endpoints

  • Returns the full user information only if that user is the caller

  • Otherwise, it only returns the user name

The reason is to prevent users accessing personal details (like email) of other users.

Customer search changes

The customer search proxy differs from the original one:

  1. isBankEmployee is not available as search criterion

  2. Only these minimal combinations of search criteria are allowed (extra search criteria can be added freely to any of the 4 sets)

    1. By id

    2. By accountNumber

    3. By countryCode and phoneNumber (both must be present)

    4. By firstName, lastName and dateOfBirth (all must be present)

      • traditionally used together with optional middleName

  3. If the caller does not have the permission to view profiles of bank employees (CUSTOMER_EMPLOYEE_VIEW) there is a special logic

    1. Search for isBankEmployee= false only

    2. If any results are found, return them like normal

    3. If no results are found

      1. Try the same search with isBankEmployee=true

      2. If there are results found, return 403 forbidden

      3. If no results are found, return nu results

The reasoning behind the overcomplicated flow 3. is that

  • We don’t want to ever return employee data when the callor does not have permission to view it (hiding it on FE would not be secure enough)

  • The requirements was to show some info in case no results are return due to this particular permission issue