Microsoft Identity Configuration

Password policies, lockout settings, user validation, and sign-in configuration

Password Configuration

Password configuration settings define the security requirements and validation rules for user passwords. These settings help ensure password strength and compliance with security policies.

Password Requirements:

RequiredLength: Minimum password length (default: 6 characters)
RequiredUniqueChars: Minimum number of unique characters required
RequireNonAlphanumeric: Requires special characters (!@#$%^&*)
RequireLowercase: Requires at least one lowercase letter
RequireUppercase: Requires at least one uppercase letter
RequireDigit: Requires at least one numeric digit

AllowedPasswordRegex Pattern:

^[\w;.:\-!|$*()@\\{}]+$

Pattern Explanation:

  • • \w - Word characters (letters, digits, underscore)
  • • ;.:|-!|$*() - Common special characters
  • • @\\{} - Additional symbols (@ backslash, braces)
  • • ^...$ - Must match entire string from start to end
  • • + - One or more allowed characters

Security Recommendations:

  • • Minimum length of 8-12 characters for better security
  • • Enable all character type requirements for strong passwords
  • • Consider unique character requirements to prevent simple patterns
  • • Regular expressions should allow sufficient character variety

Lockout Configuration

Lockout settings protect against brute force attacks by temporarily disabling accounts after multiple failed login attempts. These settings balance security with user accessibility.

Lockout Settings:

DefaultLockoutTimeSpanInMinutes: Duration of account lockout after maximum failed attempts are reached. Default is typically 5 minutes, but can be adjusted based on security requirements.
MaxFailedAccessAttempts: Number of failed login attempts before triggering account lockout. Common values range from 3-5 attempts.
AllowedForNewUsers: When enabled, newly registered users are subject to lockout policies immediately. When disabled, new users have a grace period.

Best Practices:

  • • Use 3-5 failed attempts before lockout to balance security and usability
  • • Set lockout duration between 5-15 minutes for most applications
  • • Enable lockout for new users to prevent account enumeration attacks
  • • Consider implementing progressive lockout times for repeated offenses

User Settings

User settings control username validation rules and email uniqueness requirements. These settings define how users can create and manage their account identifiers.

Username & Email Configuration:

RequireUniqueEmail: Ensures that each email address can only be associated with one user account. Critical for preventing account confusion and security issues.

AllowedUserNameRegex Pattern:

^[a-zA-Z0-9]+([._+][a-zA-Z0

Pattern Explanation:

  • • [a-zA-Z0-9] - Must start with alphanumeric character
  • • ([._+][a-zA-Z0]) - Allows dots, underscores, plus signs between characters
  • • Prevents usernames starting or ending with special characters
  • • Ensures readable and valid username format

DefaultUserGroup

This setting allows you to select a default user group that will be automatically assigned to every new user created through the registration flow. The value is selected through a dropdown listing all available groups, excluding the Administrator group for security reasons.

When configured, the selected group is applied during account creation, ensuring that new users start with a consistent permission set aligned with your application's policies.

Behavior

  • Displays a dropdown containing all groups except Admin.
  • The selected group is automatically assigned to newly registered users.
  • Existing users are not affected by changes to this setting.
  • The value can be updated at any time without retroactive impact.

Username and Email Handling

IdentitySuite automatically manages the relationship between usernames and email addresses to provide optimal user experience while maintaining data integrity. This section explains how this system works and what administrators can expect to see in the database and user management interfaces.

How IdentitySuite Handles Username and Email:

User Registration: When users register with their first name, last name, email, and password, IdentitySuite automatically assigns the email address as the UserName in the database. This creates the initial username-email relationship.
Login Process: IdentitySuite automatically handles authentication using the user's current email address, regardless of what's stored in the UserName field. Users always login with their current email and password.
Email Address Changes: When users update their email address through the user interface, IdentitySuite updates the Email field in the database while preserving the original UserName. This maintains data consistency while allowing seamless authentication with the new email.
💡

What You'll Observe in the System:

  • • In the database, UserName contains the original registration email
  • • The Email field reflects the user's current email address
  • • Users can successfully login with their current email, even if it differs from UserName
  • • Login interfaces display "Email" prompts, as this is what users should enter

Administrative Considerations:

Database Queries: When examining user data, note the distinction between UserName and Email fields
User Management: Email changes don't affect the user's internal identity or existing references
Audit and Reporting: UserName provides a stable identifier for historical tracking
System Integration: External systems can rely on consistent UserName values for stable references
User Support: Users authenticate with their current email, making account recovery intuitive
Data Export: Both UserName and Email fields are available for comprehensive reporting

Benefits of This Approach:

  • • Users can update their email address without losing account access
  • • Simplified login process - users only need to remember their email
  • • Maintains data consistency for existing user relationships and audit trails
  • • Follows modern web application patterns and user expectations

Sign-In Settings

Sign‑in settings define the verification requirements that users must satisfy before they are allowed to authenticate. These options control whether email and phone number confirmation are mandatory, ensuring that only identities with validated contact information can access the application.

Verification Requirements:

RequireConfirmedEmail: Users must verify their email address before they can sign in. Helps ensure valid contact information and reduces spam accounts.
RequireConfirmedPhoneNumber: Requires phone number verification before account activation. Useful for two-factor authentication and account recovery.

Security Considerations:

  • • Email confirmation prevents fake account creation and ensures communication channels
  • • Phone verification adds an extra security layer

Login Options

These options define how users can authenticate and access the platform, enabling or disabling specific login mechanisms such as social providers, passkeys, email- or phone‑based authenticators, and controlling whether registration is open or restricted. They allow administrators to tailor the identity experience to the security posture and UX requirements of the application.

Registration Control:

EnableUserRegistration: Defines whether the platform allows self-registration or whether account creation is centralized via administrative tools or integrated systems.
EnableSocialLogin: Controls whether users can use Social login button for login or registration.
EnablePasskeyLogin: Controls whether users can use Passkey login button for login.
SoftEmailVerification: When RequireConfirmedEmail is enabled, grants immediate access after registration without waiting for email confirmation. The session remains active while the user is using the application; once the session expires, login is blocked until the email is confirmed.
EnableEmailAuthenticator: Enables the built‑in email‑based authenticator, which uses the platform’s integrated email delivery system. Email sending can be configured in the General section of the IdentitySuite options.
EnablePhoneAuthenticator: Enables authentication via SMS one‑time codes. Requires RequireConfirmedPhoneNumber to be enabled and a valid ISmsSender implementation.

How Phone-based Authentication works

Prerequisites

  • RequireConfirmedPhoneNumber must be enabled
  • An ISmsSender implementation must be registered
  • The user must have a verified phone number

Authentication Flow

  1. The user signs in with their primary credential (e.g., password, external login, passkey)
  2. If SMS-based 2FA is enabled for the account, a one‑time code is generated
  3. The code is sent via SMS using the registered ISmsSender implementation
  4. The user enters the received code to complete the second factor
  5. Upon success, a standard session token is issued
Implementation Note: The ISmsSender interface must be implemented by the host application to integrate with the chosen SMS provider (e.g., Twilio, AWS SNS, Infobip, custom gateway), and the implementation must be registered in the application's dependency injection container.
Important: This feature is ignored if RequireConfirmedPhoneNumber is false. Both options must be enabled together.

How SoftEmailVerification works

First Access

  1. User completes registration
  2. User is immediately signed in and redirected to the application
  3. The token includes the claim email_confirmation_pending: true
  4. A confirmation email is sent in the background

Subsequent Access

  1. While the user remains active, the session is transparently renewed
  2. Once the session expires, the next login is blocked until the email is confirmed
  3. After confirmation, the user logs in normally and email_confirmation_pending is no longer issued
Client-side usage: Read the email_confirmation_pending claim from the token to differentiate the experience for unverified users — for example by showing a confirmation banner, restricting sensitive operations, or limiting access to features that require a verified identity.
Note: This property has no effect if RequireConfirmedEmail is false. Both options must be enabled together.

Security Considerations:

  • • Disable self-registration for internal applications or high-security environments
  • • Consider the user experience impact of requiring multiple verification steps
  • • Use SoftEmailVerification for transactional flows where blocking registration increases abandonment risk

Store Settings

Store settings control data storage and privacy protection features for user information. These settings determine how sensitive data is handled and protected within the identity system.

Data Protection Settings:

MaxLengthForKeys: Maximum length for data protection keys used to encrypt sensitive information. Setting this to 0 typically means no limit is applied. Proper key length is crucial for encryption security.
ProtectPersonalData: When enabled, personally identifiable information (PII) such as email addresses, phone numbers, and usernames are encrypted when stored in the database. This provides additional protection for sensitive user data.

Additional Considerations:

  • • Enabling personal data protection may impact query performance
  • • Requires proper data protection key management and rotation
  • • Essential for GDPR compliance and privacy regulations
  • • Backup and recovery procedures must account for encrypted data
🚨

CRITICAL: Database Recreation Required

Enabling or disabling ProtectPersonalData requires a complete database recreation. There is no automatic migration path - existing data cannot be automatically encrypted or decrypted when toggling this setting.

Plan accordingly: This setting must be decided before initial deployment. Changing it later will result in data loss unless you implement custom migration procedures.

Implementation Notes:

  • • Personal data protection uses ASP.NET Core Data Protection APIs
  • • Encryption keys should be properly managed and backed up
  • • Consider performance implications for large user databases
  • • Test backup and restore procedures with encrypted data