Security

System and Development Security

Reporting A Security Issue

If you think that you've found an issue which may be considered to have security implications to Metaport itself or its users, please report it in confidence to: security@dcentrica.com, even if you're unsure (it's aways best to report it, than not). Please do not create an issue in any project backlog.

Note

Dcentrica does not currently operate any kind of bug-bounty program.

Maintenance Calendar

By default team members can generate a .ics file for each app, which once imported into calendar software such us Mozilla Thunderbird, Proton Calendar or Google Calendar, provides users with the complete lifecycle of their application's components available to be reminded of.

However, the route to each app's calendar is obfuscated but not secure! For example, the route /teams/2/application/dcc396ad-3bd8-4182-9d9d-492f76740cee/calendar does not have any authentication available. All users need in order to view another app from another team is the team ID and the UUID of the application. If your instance of Metaport is available to multiple organisations (not just business units of the same company), it is recommended to disable this feature with the MP_CALENDAR_ENABLE environment variable: If it's set to 0, null or doesn't exist, then the calendar route will return an HTTP 403 response.

Application Icons

Team members can optionally upload an icon for each application-group their team manages. The icon is only intended to aid internal asset identification, however, the route to the image store is not secure! It is possible for non-authenticated users to guess the image's file-path. That said, the dirctory to which it is uploaded, is named for a hash of the team's UUID. So while not terribly worthy of consideration, if your instance of Metaport is available to multiple organisations (not just business units of the same company), you should consider the impact of this scenario. Icon upload can be globally disabled with the MP_APP_ICON_ENABLE environment variable: If set to 0, null or doesn't exist, then the icon upload UI will not be shown. Note if this environment variable is set after one or more icons have already been uploaded, these icons will be available until a Metaport admin is able to remove them completely.

Developer Bundle

To make the job of developers as easy as possible, Metaport users can generate a "Bundle" of credentials from the "Application" UI (See Usage). No part of this data is stored anywhere, it is simply delivered to the user's browser which prompts for download. The contents of this file should not be stored unencrypted and should be copy and pasted into a suitable password vault such as 1Password, LastPass, KeePass or similar and the text-file itself should then be destroyed.

MFA

MFA is setup out of the box for native Metaport users. The superuser may make MFA optional or opt-in (the system default).

Warning

If you wish to use a 3rd party IDP such as Active Directory or OpenLDAP through Keycloak for example, then Metaport's MFA system won't work for these users. They should have MFA configured within the IDP user account itself.

Encryption Key

Metaport relies on the existence of an asymmetric encryption key for its proper function, which is used for:

• Automatically created API Users (See below) used in each team
• Encrypting email attachments when apps report-in using the Email transport.

The key is located in a file-path specified by the environment variable MP_MASTER_KEY_PATH. The key itself is automatically generated so as to ensure the same algo and curves are used which Metaport expects.

Warning

DO NOT REMOVE, DELETE OR MODIFY ENCRYPTION KEYS! If the encryption key is changed, removed or deleted, then Metaport will be unable to decrypt email attachments which were encrypted with it. Similarly, existing API user accounts will no longer work. See the troubleshooting guide.

Warning

For containerised setups, the key file should be stored on a different volume which is mounted at runtime. This is required for the key file to survive container, pod and VM restarts/rebuilds.

Note

The encryption key should be readable by the www-data user which both the webserver and PHP runtime run as. Consult the metaport system log if necessary when debugging.

Mail

All mailbox connection features assume SSL mode is "on".

Single Sign On

Metaport has been developed with Keycloak as IDP which can be connected to any number of parallel identity servers like AAD or OpenLDAP.

Review the settings in .env.example and build a local Keycloak server in your development environment with the docker-compose-idp.yml file. Refer to the Development Docs. Once these enviromment variables exist, Metaport's login screen will show a "Sign in with Keycloak" button.

Role Comparison Table

When setting-up Metaport Server for the first time, it is the job of an Administrator to create the initial organisations and teams, and invite Managers to the appropriate team. Once setup, a Manager may login and add their own standard or additional Manager users to their teams.

Metaport operates on collections of applications, teams and users using organisation records. Organisations logically separate teams and applications. You might use an organisation to separate apps belonging to a particular client which has onerous data-privacy requirements, or for separate business units of the same physical organisation or company.

There are five roles within a Metaport server, one or more of which may be conferred upon a user by means of role-group membership. Users can have membership of one or more teams, but only of the same organisation. Should the same person at a company require access to team(s) in a different organisation, that person will need to possess two separate Metaport accounts within the server.

Generally speaking, users of each group possess all the subordinate system roles, as illustrated in the following table.

Group	Roles	Capabilities
Administrators	All	Configure and administer a Metaport server. Manage settings, organisations, teams, policies, applications etc
Owners	Owner Manager User	Create teams in an organisation. Manage own organisations' teams' policies. Add users to those teams and perform any action on organisations' teams' applications.
Managers	Manager User	Add users to own Teams. Manage own teams' policies. Perform any action on own teams' applications.
Users	User	Limited capabilities on teams and own teams' applications.
API Users	API	Automatically created on team creation. Limited ability to modify applications only.