Frontegg Environments Entitlements
Originally
ADR-0018-FRONTEGG-ENVIRONMENTS-ENTITLEMENTS (v6) · Source on Confluence ↗Frontegg Tenants, Environments and Entitlements
Context
DroneUp needs to create Frontegg Environments, Roles, and Permissions in order to control access to the DroneUp ecosystem.
Decision
Environments
When validating users, each DroneUp service should use the configuration, roles, and permissions from a cooresponding environment in frontegg based on the droneup environment:
DroneUp Sandbox/Dev -> Frontegg Development
DroneUp Production -> Frontegg Production
Configuration
Configuration should be created in lowest environment (development) and promoted to production.
Examples of configurations that can be promoted:
Login box/sign up box customizations
Workspace settings like webhooks enabled
Admin portal theming
Token Validation
In order to ensure secure access to the various services, each service is tasked with the responsibility of verifying that a valid token is present in either the HTTP header or the gRPC metadata. To undertake this important task, token validation is conducted using the public key of the corresponding FrontEgg environment. Standard token validation libraries such as https://github.com/droneup/common-middleware-golang should be used with the correct environment issuer url provided by frontegg. The service is also responsible for validating that the user’s role has the correct permissions to access the service.
Roles/permissions
Roles and permissions should be managed in the following Tenants:
Droneup - the tenant for all DroneUp employees logging into interal applications
Mobile Commerce - the tenant for all users ordering through the DroneUp mobile app/site
Vendor Tenants - tenants created for each external vendor so they can access public services in the DroneUp Ecosystem (ie - deliveries)
DroneUp
Tenant configuration and setup is owned by ACS (Apis and Core Services league - https://droneup.atlassian.net/wiki/spaces/API/overview)
Roles/Permissions are owned by the league who owns the product
for example - If an internal user needed access to the UTM documentation portal, then the UTM team would own
creating the roles/permissions required and validating them in code.
General guidelines for setting up roles are to have the following permissions:
- Read Only - user can only view data in the application
- Application User - user can view data as well as perform basic application level actions
- Admin - User has full control over the product and can perform any action and view any data
Teams should create new roles and permissions as needed for more fine grained control of their system.
The Droneup login box will be owned and customized by the ACS League
The DroneUp tenant will be the parent of all other tenants so that DroneUp employees with the appropriate roles and permissions can assume the roles and login as vendors as needed for support
Mobile Commerce
The mobile commerce use case is not well supported by Frontegg, and another adr will be created to address Mobile Commerce’s authenitcation needs
Vendor Tenants
Vendor tenants will be managed by the vendors themselves via the management portal. In the event that a vendor is unable or unwilling to self manage then management will fall to the ACS league
Vendor Tenants should only have access to the delivery api functionality
Vendor tenants will be able to log in via the admin portal, which is owned and maintained by droneup. The admin portal serves as a place where vendors can rotate secrets and manage child accounts
Vendor tenants will all be children of the DroneUp tenant
Consequences
The DroneUp frontegg account will be integrated with Okta so that internal users can use SSO
We will need to investigate using lumos for access/role requests
QA and Staging frontegg environments will be removed
We have to host the login front-end pages on our side to have the opportunity to customize it.