Skip to content

Tenant Administration

Tenant administrators can manage the settings that control how AMLMaster behaves for their tenant.

Tenant Options

Use tenant options to review or adjust tenant-level behavior. Changes here affect the current tenant only.

LawMaster options include AML status writeback settings. Administrators can independently enable writing the FirstAML status to a LawMaster matter attribute, writing a mapped code to Matter Sub Status, and writing the last status update timestamp to a LawMaster matter attribute.

Matter Sub Status codes must be two characters or fewer. Blank mappings are allowed and mean that AMLMaster will not update Matter Sub Status for that FirstAML status.

Access

Tenant access is managed through memberships and invites.

  • Invite users who need access to the tenant.
  • Review existing memberships.
  • Remove or update access when responsibilities change.

Available tenant roles are:

  • TenantUser: Home, Verifications, and Client Authorisations.
  • AccountingUser: all Tenant User areas plus Billing.
  • TenantAdmin: all tenant areas, including Billing and Administration.

Tenant administrators can set a new password for another tenant user, accounting user, or tenant administrator from the member list. They cannot reset their own password there or reset any account that holds the Platform Admin role.

Authentication

AMLMaster supports local accounts and optional tenant-specific OpenID Connect single sign-on.

Use the authentication area to configure the tenant's external sign-in settings. Test sign-in changes carefully, because incorrect sign-in settings can prevent users from accessing the tenant.

Authentication modes:

  • LocalOnly: users sign in with AMLMaster local accounts only.
  • LocalOrOidc: users can sign in with either local accounts or the configured OpenID Connect provider.
  • OidcRequired: users must sign in with the configured OpenID Connect provider. Local password sign-in is hidden for tenant users.

OIDC fields:

  • OIDC display name: the label shown on the sign-in button, such as Microsoft Entra ID or Google Workspace.
  • OIDC authority: the HTTPS issuer or authority URL from the identity provider.
  • OIDC client id: the application or OAuth client ID from the identity provider.
  • OIDC client secret: the secret generated for the application or OAuth client.
  • Additional scopes: optional scopes to request in addition to openid, profile, and email.

AMLMaster uses the authorization code flow with PKCE. Configure these redirect URIs in the identity provider, replacing <tenantSlug> with the tenant slug used in the AMLMaster URL:

  • Sign-in: https://app.amlmaster.com.au/signin-oidc/<tenantSlug>
  • Sign-out: https://app.amlmaster.com.au/signout-callback-oidc/<tenantSlug>

For development or testing, use the matching dev host:

  • Sign-in: https://app.dev.amlmaster.com.au/signin-oidc/<tenantSlug>
  • Sign-out: https://app.dev.amlmaster.com.au/signout-callback-oidc/<tenantSlug>

Microsoft Entra ID OIDC

  1. In the Azure portal, open Microsoft Entra ID and go to App registrations.
  2. Create a new registration for AMLMaster. Use the supported account type that matches the tenant policy, normally single tenant.
  3. Add a Web platform redirect URI for the AMLMaster sign-in URL, for example https://app.amlmaster.com.au/signin-oidc/<tenantSlug>.
  4. Add the AMLMaster sign-out callback URL where Entra ID asks for a front-channel logout URL or post-logout redirect URL, if that option is used by the organisation.
  5. Under Certificates & secrets, create a client secret and record the secret value before leaving the page.
  6. Under API permissions, ensure Microsoft Graph delegated permissions include openid, profile, and email. Add any organisation-required consent.
  7. In AMLMaster, set:
  8. Authentication mode: LocalOrOidc for a staged rollout, or OidcRequired once ready.
  9. OIDC display name: Microsoft Entra ID.
  10. OIDC authority: https://login.microsoftonline.com/<tenantId>/v2.0, using the Entra tenant ID.
  11. OIDC client id: the app registration application client ID.
  12. OIDC client secret: the client secret value.
  13. Additional scopes: leave blank unless the organisation has requested extra scopes.
  14. Save the settings and test sign-in with a user who is allowed to access the Entra application.

Google Workspace OIDC

  1. In Google Cloud Console, create or select the project used for AMLMaster sign-in.
  2. Configure the OAuth consent screen for the organisation. For Workspace-only access, use the internal user type where available.
  3. Go to APIs & Services > Credentials and create an OAuth client ID.
  4. Choose Web application as the application type.
  5. Add the AMLMaster sign-in URL as an authorised redirect URI, for example https://app.amlmaster.com.au/signin-oidc/<tenantSlug>.
  6. Record the generated client ID and client secret.
  7. In AMLMaster, set:
  8. Authentication mode: LocalOrOidc for a staged rollout, or OidcRequired once ready.
  9. OIDC display name: Google Workspace.
  10. OIDC authority: https://accounts.google.com.
  11. OIDC client id: the OAuth client ID.
  12. OIDC client secret: the OAuth client secret.
  13. Additional scopes: leave blank unless the organisation has requested extra scopes.
  14. Save the settings and test sign-in with a Google Workspace user who is allowed by the OAuth consent configuration.

Webhooks

Tenant webhook screens let administrators configure webhook subscriptions and review received webhook events.

Use webhook event history when checking whether AMLMaster received and processed an event from an external service.