Data Security, Accounts, and Roles

The basic concepts of managing security within a Dodgeball Environment are Accounts, Users, Roles, and Privileges. The structure is as follows:

1. Every data element in the Dodgeball System is owned by exactly one Customer Account and, in some cases, by a single user within that account. General data shared across all accounts is specifically owned by the Dodgeball-Support account (which is present in every Deployment).
2. Data elements are only read, modified, or deleted by means of Web Service Requests. Each such Web Service Request is marked up with a Constraining Privilege, for example, the requirement that any user attempting to call this service must have the READ permission on the “case” principal.
3. Every Web Service Request comes in with Account and/or User credentials:

                A. Requests from the Dodgeball Trust Console pass through Auth0 and receive credentials for a specific user within a specific account.

                B. Every Runtime Web Service Request (dispatched by a Client or Server SDK operation) is received with a public/private API key, which maps to an Account.

4. Each Web Service Method is marked up with either:

                A. An explicit assertion that the method is open to the public (Opening a new account).

                B. A statement that the method is open to any account.

                C. A statement that the method is open to any user holding specific privileges.

5. As soon as we receive a web service request, we validate that the specific security constraints are supported, erroring out otherwise

We have a list of standard roles, which Adam wrote long ago in support of Staples, but I can’t seem to find it.

Roles Defined in Database

The exact list of roles and their associated privileges is actually configured within the database as part of our Data Seeding Operation. Looking forward, it would be very easy to meet customer requests for new role structures, or even to make the exact privileges available to each role configurable within the UI (though this would have little value at present).

Takeaway

All Dodgeball Data Resources are protected by Role Based Access Control privileges.

Example hierarchy

Customer (Staples)

• Env Prod

• Account Staples Prod

• User a
• User b

• Env Sandbox

• Account Staples Sandbox

• User a
• User b
• User c

Creating a New Account

While anyone could, in principle, create a new account, it’s best to have Engineering do this since the best approach I’ve found to date requires one database step. But to ensure that the steps are documented (and leaving the option later for a very small software change to pass this over to Customer Success), the steps are as follows:

1. Enable Self Sign-Up: A long time ago, we opened up Dodgeball for account self-signup. The underlying software remains available, but is now controlled by the Dodgeball Support Account. To enable it:

            A. Log in using the service_admin@dodgeballhq.com login and the password found in 1Password.

            B. Open up the Dodgeball Management Service and enable “Allow Account Signups”

            C. Click on the Save button.

2. Log Out of Dodgeball: Otherwise, Auth0 will get confused.

3. Sign Up for the New Account:

            A. Navigate to https://${app_url}/signup

            B. Fill out the signup form:

                      B1. Use the full name for the company. This will become the slug.

                      B2. Sign up with the personal name: Dodgeball Support

                      B3. Provide a unique email that will forward to yourself. This will allow you to receive the account verification email

                C. The complete signup form for Neuco is included below. Click on the “Signup (sic) with email” option.

                D. Complete the signup by entering a password for the new email address.

4. Activate the new Account: Within a few minutes, you will receive a Dodgeball Account Activation email. Click “Activate my Account” and log in using the email address you previously provided.
5. Create Auth0 Support Email: Using your Auth0 Google Auth credentials, log in to Auth0, if necessary change tenant for Production, and:

               A. Create a new user with an appropriate support email, for example, “neuco_support@dodgeballhq.com”

               B. Set a password for this user. I prefer long song-based passwords with a letter and symbol replacement.

               C. Store the password in 1Password in the Account Management Vault

               D. Mark this user as verified

6. Change Support Email in Database: This is the one step that we currently don’t support in the app. Get an engineer with system access to execute an update on the users table mapping andrew+neuco@dodgeballhq.com to neuco.support@dodgeballhq.com
7. Invite Customers: We generally get a list of users to be invited into the given account. Invite them using the Admin page to manage users.
8. Turn Off Self-Signup:

               A. Log out of the Trust Console

               B. Log in to the trust console as service_admin@dodgeballhq.com

               C. Navigate to the Dodgeball Management Service.

               D. Disable self-signup.

               E. Save the service.

The signup sheet should look like:

Note: There’s nothing special about this sequence, but it is important to click the buttons correctly. Thus, it’s generally best to get Engineering Leadership to do this very cleanly.

FAQ

How do we Control Which Users see the Billing Page

This is controlled by the “billing” security principal, which is only available to the Account Owner role.

How do we add a user to Dodgeball

Use the “Invite Users” page: