Loading ...

Site Security Best Practices | Axero Documentation

Home » axero documentation » Wiki » Documentation » Site Security Best Practices
Axero Documentation  Wiki
Public Space
Activity Stream Content
Version 14

Site Security Best Practices

0 
 /5
0 (0votes)

Applies to: Cloud & Self-Hosted

Audience: Site Administrators

Introduction

This reference covers the main security settings in the Axero platform. Review each recommendation to protect your organization's data and control who can get into your site.

Overview

Login

These settings control the login page and how people sign in. For full documentation, see Login and Edit Registration Page.

Edit Login Page

The login page is the entry point to your Axero platform. Set it up to offer only the sign-in methods your organization actually uses (e.g., SSO, email/username and password, or social logins). For more protection, see the Two-Factor Authentication and Password Policy sections below.

Tip: Set the permission for inactive login widgets to Site Administrator only so they do not appear on the login page.

SSO Auto-Login

If your Axero platform uses Single Sign-On (SSO) and all users authenticate through your SSO provider, enable auto-login. Users then go straight to the SSO provider's sign-in page instead of seeing the Axero login page.

To enable this, go to Control Panel > System > System Properties and search for EnableAutoLoginViaSaml. Set the value to true.

Important: Only enable SSO auto-login if all users sign in through your SSO provider. If any users sign in with a username and password, enabling this setting will prevent them from reaching the Axero login page.

Login Page Without SSO

When your Axero platform does not use SSO, users sign in with their username or email and password. Make sure these fields stay on the login page:

  • Email or username
  • Password
  • Sign-in button

If your platform has Two-Factor Authentication enabled, also keep the "Enter Your Passcode" section on the login page.

Edit Registration Page

Hiding the registration form changes only what people see. To stop people creating their own accounts, turn off Allow self-registration (listed in the settings table below). With it off, the registration page is not available to anyone who is not signed in.

Tip: Hide the registration form if you provision users (create their accounts automatically) through an integration such as SCIM or Active Directory sync.

Maximum Invalid Login Attempts

Limit the number of failed sign-in attempts before an account is locked. Go to Control Panel > System > System Properties and search for MaxInvalidLoginAttempts. Axero ships with this set to 5, so most sites already have a limit. Check the value rather than assuming it is unset. Setting it to 0 switches lockout off altogether, so do not use 0 to mean no attempts are allowed.

Setting Best Practice
MaxInvalidLoginAttempts 5, which is also the shipped default. Any value above 0 sets the limit; 0 disables lockout

Password Policy

Password requirements are set in the user profile field settings. Go to Control Panel > People > User Profiles and select the Password field to set its validation rules.

Setting Description Best Practice
Minimum length The minimum number of characters required for a password. 8 or more characters
Maximum length The maximum number of characters allowed for a password. 64 or more characters to support passphrases
Regex validation A regular expression (a text pattern written in a special syntax) that passwords must match. When set, this overrides the minimum and maximum length settings. Use this to enforce complexity requirements such as requiring uppercase letters, digits, or special characters. Define a regex that requires at least one uppercase letter, one digit, and one special character

Note: Password policy settings do not apply to users who sign in exclusively through SSO. SSO users authenticate against your identity provider, which enforces its own password policy.

Two-Factor Authentication

Two-Factor Authentication (2FA) adds a second verification step after the user enters their password. When enabled, users must enter a time-based passcode from an authenticator app (such as Microsoft Authenticator or Google Authenticator) to complete sign-in.

To enable 2FA, go to Control Panel > System > System Properties and search for TwoFactorAuthenticationEnabled. Set the value to true.

Setting Best Practice
TwoFactorAuthenticationEnabled Enabled for all organizations that use username/password authentication

Important: When you enable 2FA, make sure the "Enter Your Passcode" section is on your login page. Without it, users cannot finish signing in. 2FA does apply to people who sign in through SSO. If the site setting is on and the person has set up an authenticator, single sign-on sends them to the passcode screen, just as a username and password sign-in does. That comes on top of whatever multi-factor check your identity provider already enforces. Decide deliberately whether you want both. For full setup details, see Edit Edit Profile Page.

Session Management

Session settings control how long users stay signed in before they must sign in again. Shorter sessions reduce the risk of someone else using a device left unattended. To change them, go to Control Panel > System > General Settings.

Setting Description Best Practice
Session timeout The number of minutes a user can remain inactive before they are automatically signed out. 30 to 60 minutes depending on your organization's security requirements
Remember me When enabled, users can choose to stay signed in across browser sessions. This extends the session beyond the timeout period. Disabled for organizations with strict security requirements

Site Settings

The following settings are located under Control Panel > System > General Settings. For full documentation, see Site Settings.

Setting Description Best Practice
Allow self-registration When enabled, anyone can access the Registration page to create an account. When disabled, only administrators or moderators can create accounts on behalf of users. Disabled
Auto-approve members When enabled, users are automatically approved after confirming their email. When disabled, a site administrator must manually approve every user. Disabled
Allow access only to registered members When enabled, users must register and sign in before accessing any content. When disabled, guests can view the platform in read-only mode. Enabled
Allowed email domains Restricts user registration to specific email domains. Enter a comma-separated list of domains (e.g., yourdomain.com, yourotherdomain.com), or enter * to allow any domain. Restrict to your company email domain only

General Settings page showing self-registration, auto-approve, access restriction, and allowed email domain settings

User Section Permissions

The following settings are located under Control Panel > People > User Section Permissions. For full documentation, see User Section Permissions.

Review all permissions for roles other than the Site Administrator. Follow the principle of least privilege: give each role only the permissions it needs to do its job.

Permission Risk Level Best Practice
Delete Users High Site Administrator only
Manage Roles High Site Administrator only
Import Users High Site Administrator only
Edit User Profile Medium Enable only for roles that manage user profiles (e.g., HR moderators)
View User Profile Low Safe to enable for all roles

Tip: Review user section permissions regularly, and again after organizational changes (e.g., new roles, team restructuring), so no role builds up more permissions than it needs.

REST API Settings

The following settings are located under Control Panel > System > General Settings > REST API. For how API access works today, see Transitioning to Bearer Tokens.

Setting Description Best Practice
Enable REST API Turns on the REST API, which gives other software access to platform data and functions. Disabled if your organization does not use the REST API
Select users who can access the REST API The REST API key is tied to the user's roles and permissions, so through the API a user can reach only the content their platform permissions allow. For administrative API tasks, it is standard practice to create a dedicated service account (an account used by software rather than a person) with the Site Administrator role. Only the Site Administrator role should be enabled

Email Settings

The following settings are located under Control Panel > System > General Settings > Email Settings. For full documentation, see Email Configuration Overview.

Setting Description Best Practice
Enable email sending Controls whether the platform sends notification emails based on user activity (comments, mentions, content updates). Disabling this stops all outbound notification emails. Organization preference

Tip: If your organization uses a custom email domain for outbound notifications, configure SPF and DKIM records (settings that prove email really comes from your domain) for that domain to keep notification emails from being flagged as spam. Your email provider or IT team can tell you how to set them up.

Support and Feedback

If you run into an issue not covered here, or a step could be clearer, let us know through a Support Case so we can help you and improve this guide for everyone.

Wiki Index

Pages