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 containier, 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

Metaport separates collections of applications, teams and users with "Organisation" records. Users themselves are added to role-groups. Additionally, if a Metaport superuser arranges it, users can also gain visibility over multiple organisations and become members of multiple role-groups.

Metaport is designed to be used by a variety of users from within an organisation. There are five roles, of which one or more may be conferred upon a user by means of role-group membership.

Users can have a membership of one or more Team, but not in more than one Organisation. Should the same person at a company require access to a Team in a different Organisation, that person will need to possess two entirely separate accounts within the Metaport server.

Organisation records are useful for logically separating groups of teams and applications. You might use organisations in order to separate apps belonging to a particular client perhaps with onerous data-privacy requirements, away from apps with lesser such requirements.

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

When setting-up Metaport Server for the first time, it is the job of an Administrator to create the initial range of Organisations and Teams, and invite Managers to the right Team. Once setup, Managers can login and add their own User or additional Manager users to their Teams.

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.