ADR-0023 Use Custom Claims
Publication Date | 2021-09-22 |
---|---|
Last Update | 2021-09-22 |
Status | Accepted |
Context
In ADR 6 we note that we will use Firebase Authentication in all the user-facing applications. ADR 16 expands on this and describes the authentication requirements for each use-case. The following table summarizes the roles identified in ADR 16.
Use Case | Role | Firebase Auth? | Registration Ux? |
---|---|---|---|
1 | Designer | Yes | No |
1 | Product Manager | Yes | No |
1 | eTryOn Admin | No | No |
2 | Influencer | Yes | Yes |
2 | Marketing Exec | No | No |
3 | User | Yes | Yes |
3 | 3D Tech Designer | No | No |
The roles that don’t use Firebase Auth will instead use standard Google Cloud IAM permissions and are out of scope of this document.
Use cases 2 and 3 allow users to self-register to use the eTryOn applications and all self-registered users have the same permissions: these cases require no special treatment.
For use case 1, we will not provide a Ux for users to self-manage their accounts: account creation will be done by eTryOn staff through the Firebase Admin Auth API. However, a malicious user might still be able to access the public Firebase APIs for our project and create unauthorized accounts.
Decision
We will use a Custom Claim when we
create accounts through the Admin API. This could either be a role
field or an authorized
flag. These claims cannot be set by a self-registered user.
Consequences
-
We will have to write security rules for the VR Asset Store (Cloud Storage) and VR Data Store (Firestore) with conditions restricting access to users with the required custom claim set. See Custom-claim attributes and roles for some examples.
-
Cloud functions called from a Firebase app will have to check for the custom claim in the auth context and reject attempts at unauthorized access.