Secure Configuration Guide

No rows match your filter.

1. Before you begin

RediReview Platform grants access through roles. A role is a set of modules, and each module unlocks one part of the dashboard. A tenant is an organization (an IDRE, or Independent Dispute Resolution Entity). Each role assignment is tied to one tenant, so a role applies only within that tenant and limits which disputes and users it can see. One user can have access to several tenants, with a different role in each. For example, a RediMinds user can be Tenant Administrator for one tenant and operational_member for another. Within a tenant, a person's access is the union of the modules in all of their roles for that tenant.

Account types

The built-in roles are super_admin (Tenant Administrator), operational_admin and operational_member. super_admin cannot be edited, renamed or deleted. Because roles are assigned per tenant, being a Tenant Administrator in one tenant gives no access to any other tenant.

RediMinds staff hold separate platform-level accounts that operate the service. You never need one. The Outreach administrative console is also operated by RediMinds, so you work with outreach from the dashboard's Outreach module.

Modules

More modules will be added over time. Each new module appears in this list and is granted only through roles, so no one gains access to it unless an administrator assigns a role that includes it.

2. Secure access

Sign in safely

1. Ask RediMinds to set up your Tenant Administrators. Contact RediMinds support. RediMinds creates each person's identity and an active dashboard user in your tenant with the super_admin role. Name at least two people so that one can always deactivate the other. Later additions or removals of super_admin go through the same request.
2. Sign in at https://gov.rediminds.com and choose Sign in with SSO. Enter your password and, on first sign-in, enrol a security key or passkey when prompted.
3. Use a named, individual account. Every administrator signs in as themself. Every administrative action is attributed to the signed-in user, so shared administrator accounts make that record meaningless.
4. Sign out when you finish (user menu → Sign out). On a shared device, also close the browser.

What to expect when signing in

Roles and active status are checked on every request. Deactivating a user or changing a role takes effect on that person's next click.

3. Secure configuration

Add a user

1. Create the user only after the access request is approved.
2. Go to Admin → Users → Add user.
3. Use the person's work email exactly as it is registered with the Identity Service. An email that does not match cannot sign in.
4. Start with operational_member, and add access only if the job needs it.

Assign roles

• Give people the minimum role for the job: operational_member (read-only) or operational_admin (operations) instead of super_admin.
• Have a second administrator approve every increase in access, and record the approval. The dashboard's confirmation dialog does not count as a second-person approval.
• Hold the Admin module only through super_admin. Do not request custom roles that include it.
• Assign roles only for your own tenant. A person who works with several tenants holds a separate role in each, and you manage only the assignments in yours.

Keep enough administrators

Keep at least two Tenant Administrators, and no more than your organization needs. Review the list monthly.

Issue an API token

Create a token only for a named automation need.

1. Sign in through the dashboard. Tokens can be issued only from an interactive, MFA-protected session, never by another token.
2. Call POST /auth/tokens with a descriptive name, a ttl_days as short as practical, and scopes limited to what the automation calls. Leave out admin unless the automation administers users.
3. Copy the token and store it in a secrets manager. It is shown only once.

A token lasts 30 days by default and at most 90 days; tokens without an expiry are refused. A token acts with the issuer's permissions, without a fresh MFA challenge, until it expires or is revoked.

4. Secure operation

5. Secure decommissioning

To remove an administrator, or any user:

1. Deactivate the dashboard user. In Admin → Users, set the user to Inactive, or call PATCH /admin/users/{id} with {"is_active": false}. The account loses access on its next request. Users are deactivated rather than deleted, so their history stays attributable. An administrator cannot deactivate their own account; a second administrator must do it.
2. Remove their privileges. Replace the user's roles with operational_member so the account holds no privilege if it is ever reactivated. Removing super_admin is a request to RediMinds support.
3. Revoke their API tokens. List them with GET /auth/tokens?scope=all and revoke each with DELETE /auth/tokens/{id}. Revocation takes effect at once in the dashboard. If a token may be exposed, also ask RediMinds support to rotate the token signing key.
4. Ask RediMinds to disable the person's identity in the RediMinds Identity Service.
5. Keep a record of the request, the date and the administrator who performed it.

Keep at least two Tenant Administrators at all times. To offboard your whole organization, contact RediMinds support. RediMinds then handles data retention and return under your agreement.

6. Settings reference

These are the security-related settings you can change, where to find them, and what we recommend.

7. What RediMinds manages for you

You cannot change these settings, but you should know they are in place.

• Sign-in. Everyone signs in through the RediMinds Identity Service with required multi-factor authentication. Shared-password sign-in is not used.
• Encryption. Every connection to the service uses HTTPS (TLS 1.2 or higher). Database connections require TLS, and data at rest is encrypted.
• Tenant isolation. Your disputes and users are kept separate from other organizations' data, enforced in the database as well as the application. A user with access to several tenants sees only one tenant's data at a time, under the role held in that tenant.
• Brute-force protection. Sign-in endpoints are rate-limited per source address, in addition to the delay after failed sign-ins.
• Browser protections. The dashboard sends standard browser security headers, and its session cookie is Secure, HttpOnly and SameSite=Lax.
• Outreach. Outbound email is off unless RediMinds enables it for your organization. Dispute parties reach the recipient portal through an expiring link, and a portal session lasts 1 hour.

8. A new organization at a glance

RediMinds sets up a new tenant in this state. Check it against your first monthly access review.