...

There are several ways to reduce or eliminate the risks that have been identified, like adding authentication and roles to the software, running the REST API through a proxy or even fine-tuning the firewall configuration. A combination of the three could probably achieve the most secure and flexible solution. There's likely a whole set of additional ways to solve the situation, but we will consider three (complementary) alternatives in this proposal.

Custom Implementation

A custom implementation could allow several levels of granularity on its configuration:

• Authentication
• Roles
• Access restriction or whitelisting (Components, types (IDLs), methods. etc.)

The CDB configuration of the Component Caller API could be used to easily configure the different security profiles.

For authentication, it could either be used the CDB configuration (cdbRead could access credentials / tokens), or a service such as LDAP, ALMA Registry, etc.

Proxy

A proxy could be configured either for the server or the APE environment as a whole, which limits the access to the resources. It could be used for:

• Authentication (Through CAS / KeyCloak)
  • Would most likely require changes to software to take advantage of CAS / KeyCloak tokens
• Roles (Associated with the source IP)
• Access whitelisting (Components, types (IDLs), methods. etc.)
  • Associated with source IP
  • Would require software changes to consider /<component>/<method> endpoints.

Firewall

The existing firewall could be configured for the APE environment to limit the access to the Component Caller API, allowing specific services to make use of the REST API

• Access whitelisting
  • Black / White access limitation

Comparison

Discussion

Conclusions

...