D2L is committed to helping customers implement secure, scalable authentication models that align with industry standards. D2L supports both Single Sign-On (SSO) and local authentication and works with customers to identify the approach that best supports modern security practices and enterprise identity requirements. This approach helps protect users, data, and institutional trust.
Recommended authentication model
D2L recommends Single Sign-On (SSO) as the preferred authentication model for new customers because it aligns with current industry best practices. In enterprise SaaS environments, SSO supports:
- Centralized identity and access management
- Stronger enforcement of multi-factor authentication and conditional access policies
- Streamlined user onboarding and offboarding
- Alignment with enterprise security and compliance requirements
This approach aligns with modern security frameworks and customer expectations while continuing to support local authentication where appropriate.
For more information about configuring SSO, securing local authentication, and using Brightspace multi-factor authentication for administrators who use local authentication, refer to Enhancing Security with Single Sign-On (SSO) and Local Authentication Controls within D2L Brightspace.
|
Important: When implementing Single Sign-On (SSO), local login must be disabled in Brightspace for every role that is required to authenticate through SSO. This ensures that users can access Brightspace only through the customer’s identity provider and prevents local credentials from bypassing centralized identity, authentication, and access controls.
For instructions on disabling local login after configuring SSO, refer to Disable local login.
If some users, such as test learners, must continue to use local login while production learners authenticate through SSO, create two separate roles. Disable local login for the production learner role and retain local login only for the dedicated test learner role.
|
Local authentication requirements
When local authentication is required, D2L strongly recommends enabling two-factor authentication (2FA) for all locally authenticated accounts.
Although Brightspace local authentication is implemented securely, passwords alone do not provide sufficient protection against current security threats. 2FA is an industry-standard security control that helps reduce the risk of account compromise and supports a stronger authentication model.
For customers using local authentication, enabling 2FA should be considered a baseline security requirement.
When local authentication is required, D2L strongly recommends enabling two-factor authentication (2FA) for all locally authenticated accounts.
Although Brightspace local authentication is implemented securely, passwords alone do not provide sufficient protection against current security threats. 2FA is an industry-standard security control that helps reduce the risk of account compromise and supports a stronger authentication model.
For customers using local authentication, enabling 2FA should be considered a baseline security requirement.
For instructions on enforcing 2FA for specific roles, refer to Enable or enforce two-factor authentication for specific roles.
Password policy settings
Regardless of the authentication method used, D2L recommends aligning Brightspace password policies with the organization’s established password standards. This alignment is particularly important when local authentication is enabled and provides an additional layer of protection when Single Sign-On (SSO) is used.
For information about configuring password policies in Brightspace, refer to Set password policy restrictions.
At a minimum, Brightspace password standards should meet the following requirements. Institutions may apply stricter requirements to align with their internal security policies but should not use standards that are less stringent than those listed below.
- Password age:
- Set the maximum password age no longer than one year.
- Require users to change their password after this period.
- Password reuse:
- Prevent users from reusing their previous 24 passwords.
- Password complexity:
- Require a minimum password length of 12 characters.
- Require at least one uppercase letter.
- Require at least one lowercase letter.
- Require at least one number from 0 to 9.
- Require at least one non-alphanumeric character.
- Prevent passwords from containing the user’s:
- Username
- First, middle, or last name
- Organization-defined ID
- Account clean-up:
Regularly review user accounts and inactivate any account that has not been used for more than 12 months. This reduces the risk of stale accounts or credentials being used to gain unauthorized access.