Access in WBAMS is decided in two places: who has an administrator account, and which role that account carries. Everything else — two-factor, sign-in protection, fraud checks — hardens those two decisions.

Administrator accounts

Each administrator has their own account. Shared logins destroy the audit trail, because every entry in the administrator log then names the same person. Invite a new administrator by email; the invitation is accepted on a page of its own where they set their own password.

Keep at least two recoverable full administrators.

A single super-administrator account whose password is lost is an outage. Verify the second account can actually sign in rather than assuming it can.

Roles and the permission list

A role is a named set of the 153 permissions, presented under the administration area’s own headings so a role can be reasoned about area by area rather than as one undivided list. Each heading has Check All and Uncheck All.

  1. Start from the narrowest role that could do the job, not from a copy of the full administrator role.
  2. Grant whole areas where the job needs them; grant individual permissions where it does not.
  3. Test the role by signing in as a non-super-admin account holding it. Reading the checkboxes is not a test.
  4. Review roles after staffing changes rather than on a schedule.
A permission that is not granted hides the page.

Pages do not appear greyed out; they are absent from the menu and return access denied if addressed directly. An administrator reporting a missing page is usually reporting a permission, not a bug.

Two-factor authentication

Two-factor applies to administrator sign-in. Enable it, then enroll accounts individually. Keep recovery arrangements for an administrator who loses their device, and confirm the recovery path works before you need it.

Security questions

Security questions are used for account recovery. Maintain the question list deliberately: a question whose answer is discoverable from a public profile is not a control.

Sign-in protection

Repeated invalid sign-in attempts ban the originating address for a period. Bans are visible and removable under blocked addresses.

Automated requests to the sign-in endpoint count as failures.

A monitor, uptime check or crawler that hits the administrator sign-in URL will ban itself, and can ban an office address that shares the same egress IP. Point health checks at a page that does not authenticate.

Blocked addresses and emails

Blocked IP addresses and blocked email addresses are separate lists. The IP list governs who may reach the sign-in and ordering flows; the email list governs which addresses may register or open tickets. Both are reviewed rather than accumulated — an entry added during an incident and never removed becomes a support mystery months later.

Fraud checks

Fraud checking runs against orders at the point they are placed. Configure the provider, decide what a failed check should do to the order, and make sure somebody is reviewing what it flags. A fraud rule nobody acts on is a queue, not a control.

Sign-in integrations

OpenID and third-party sign-in let customers authenticate with an existing identity provider. Configure the provider credentials, decide whether an account may be created on first sign-in, and confirm the callback address matches exactly — a trailing slash difference is the usual cause of a failed round trip.