Custom Authentication and SSO

Overview

• What you’ll learn:
  • How iDempiere’s authentication architecture works, from the Login class through session establishment and security context
  • How to integrate LDAP and Active Directory for centralized user management, and how to implement custom authentication providers
  • How to configure Single Sign-On using OAuth2 and SAML, implement two-factor authentication, and harden security for production deployments
• Prerequisites: Lesson 40 — System Architecture Design, Lesson 26 — Plugin Development Fundamentals, familiarity with authentication protocols
• Estimated reading time: 25 minutes

Introduction

Enterprise deployments of iDempiere rarely operate with standalone user management. Organizations have existing identity infrastructure — Active Directory forests, LDAP directories, identity providers like Okta or Azure AD — and they expect iDempiere to participate in their established authentication and authorization ecosystem. Users should not need a separate password for the ERP system, administrators should not need to maintain user accounts in multiple places, and security policies (password complexity, account lockout, multi-factor authentication) should be enforced consistently across all enterprise applications.

This lesson takes you through iDempiere’s authentication architecture, shows you how to integrate with external identity systems, and provides practical guidance on implementing Single Sign-On, custom authentication providers, and security hardening for production environments.

Authentication Architecture in iDempiere

Understanding the default authentication flow is essential before you can extend or replace it. The authentication process in iDempiere follows a well-defined sequence.

The Login Class

The core authentication logic resides in the org.compiere.util.Login class. This class is responsible for:

1. Credential validation: Checking the username and password against the AD_User table. Passwords are stored as hashed values (SHA-512 with salt in recent versions).
2. Role enumeration: After successful authentication, querying the AD_User_Roles table to determine which roles the user can assume.
3. Context population: Once the user selects a role, client, organization, and warehouse, the Login class populates the Env context with session parameters (#AD_Client_ID, #AD_Org_ID, #AD_Role_ID, #M_Warehouse_ID, #AD_User_ID, and many others).
4. Session creation: Creating an AD_Session record that tracks the login timestamp, client IP address, and session state for audit trail and concurrent session management.

The Web Login Flow

In the ZK web client, the login flow passes through several components:

1. WLogin.java: The ZK window component that renders the login form and handles user input.
2. LoginPanel.java: Contains the two-stage login UI — first for username/password, then for role/client/org/warehouse selection.
3. SessionManager.java: Manages HTTP session binding, session timeout, and session cleanup.
4. The authentication call chain: LoginPanel calls Login.authenticate(), which returns the list of available roles. After role selection, Login.validateLogin() establishes the full security context.

Key Database Tables

• AD_User: User accounts, including Password (hashed), Salt, IsLocked, DatePasswordChanged, FailedLoginCount.
• AD_User_Roles: Many-to-many relationship between users and roles.
• AD_Role: Role definitions including access permissions.
• AD_Session: Active and historical session records for auditing.

LDAP Integration

LDAP (Lightweight Directory Access Protocol) integration allows iDempiere to authenticate users against an external directory service, most commonly Microsoft Active Directory. This eliminates the need to maintain separate passwords in iDempiere.

iDempiere’s Built-in LDAP Support

iDempiere includes built-in LDAP configuration at the System level. The configuration is found in the System Configurator or directly in the AD_System record:

• LDAP Host: The hostname or IP address of the LDAP server (e.g., ldap://ad.company.com or ldaps://ad.company.com:636 for SSL).
• LDAP Domain: The Active Directory domain (e.g., company.com).

When LDAP is configured, the login process changes: instead of comparing the entered password against the hash stored in AD_User, iDempiere attempts an LDAP bind operation using the provided credentials. If the bind succeeds, the user is authenticated.

Configuration Steps

1. Set LDAP parameters: In the System window, configure the LDAP Host and Domain fields. For Active Directory, the host is typically ldaps://your-dc.domain.com:636.
2. Create iDempiere users: Each LDAP user who needs access to iDempiere must still have an AD_User record. The LDAPUser field should contain their LDAP identifier (typically the sAMAccountName or userPrincipalName). The password field in iDempiere can be left empty since authentication will be handled by LDAP.
3. Assign roles: Role assignment remains in iDempiere. LDAP handles authentication (proving who you are), while iDempiere handles authorization (what you can do).
4. Test connectivity: Ensure the iDempiere server can reach the LDAP server on the required port (389 for LDAP, 636 for LDAPS). Firewall rules and DNS resolution must be in place.

Practical Example: Active Directory Integration

# LDAP connection test from iDempiere server using ldapsearch
ldapsearch -H ldaps://ad.company.com:636 \
  -D "CN=svc_idempiere,OU=ServiceAccounts,DC=company,DC=com" \
  -W \
  -b "OU=Users,DC=company,DC=com" \
  "(sAMAccountName=jsmith)" \
  cn mail memberOf

This verifies that the iDempiere service account can query the directory and retrieve user attributes. In production, always use LDAPS (LDAP over SSL/TLS) to encrypt credentials in transit.

LDAP Failover

For high availability, configure multiple LDAP servers. If your directory environment has multiple domain controllers, you can specify a space-separated list of hosts or use DNS SRV records. Implement a custom authentication provider (described below) if you need more sophisticated failover logic than the built-in support provides.

Custom Authentication Provider Implementation

When the built-in LDAP support is insufficient — for example, when you need to authenticate against a custom identity store, implement multi-provider authentication (try LDAP first, fall back to database), or add pre/post-authentication logic — you can implement a custom authentication provider as a plugin.

The Authentication Extension Point

iDempiere defines an extension point for authentication through model event handlers and the login process. A custom authentication plugin typically works by intercepting the login process. The approach involves:

1. Creating an OSGi plugin bundle.
2. Implementing a factory or service that replaces or wraps the default authentication logic.
3. Registering the custom authenticator via OSGi Declarative Services or an event handler.

Implementation Pattern

/**
 * Custom authentication provider that checks LDAP first,
 * then falls back to database authentication.
 */
public class CustomAuthenticator {

    private static final String LDAP_URL = "ldaps://ad.company.com:636";
    private static final String LDAP_BASE_DN = "DC=company,DC=com";

    /**
     * Authenticate user against LDAP directory.
     * Returns true if authentication succeeds.
     */
    public boolean authenticateLDAP(String username, String password) {
        Hashtable<String, String> env = new Hashtable<>();
        env.put(Context.INITIAL_CONTEXT_FACTORY,
            "com.sun.jndi.ldap.LdapCtxFactory");
        env.put(Context.PROVIDER_URL, LDAP_URL);
        env.put(Context.SECURITY_AUTHENTICATION, "simple");
        env.put(Context.SECURITY_PRINCIPAL,
            username + "@company.com");
        env.put(Context.SECURITY_CREDENTIALS, password);
        env.put(Context.SECURITY_PROTOCOL, "ssl");

        try {
            DirContext ctx = new InitialDirContext(env);
            ctx.close();
            return true;  // LDAP bind succeeded
        } catch (AuthenticationException e) {
            log.info("LDAP auth failed for " + username +
                ": " + e.getMessage());
            return false;
        } catch (NamingException e) {
            log.warning("LDAP connection error: " + e.getMessage());
            return false;  // LDAP unavailable, allow fallback
        }
    }

    /**
     * Multi-provider authentication: try LDAP first,
     * then database.
     */
    public boolean authenticate(String username, String password) {
        // Try LDAP authentication first
        if (authenticateLDAP(username, password)) {
            log.info("User " + username +
                " authenticated via LDAP");
            return true;
        }

        // Fall back to database authentication
        // (useful for service accounts or when LDAP is down)
        return authenticateDatabase(username, password);
    }
}

Registering the Custom Provider

The custom authentication provider is registered as an OSGi service. You can hook into the login process by implementing a model event handler that intercepts the AD_User login validation, or by using iDempiere’s event-based extension mechanism to replace the default authenticator. The component definition in OSGI-INF would declare the service and its dependencies on the core authentication interfaces.

OAuth2 as Authentication Provider

OAuth2 enables users to authenticate with iDempiere using their existing identity from providers like Google, Microsoft Azure AD, Okta, or Keycloak. The standard flow for web applications is the Authorization Code Grant.

OAuth2 Authorization Code Flow

1. User clicks “Sign in with [Provider]” on the iDempiere login page.
2. iDempiere redirects the browser to the OAuth2 provider’s authorization endpoint with the client ID, redirect URI, requested scopes, and a state parameter (CSRF protection).
3. User authenticates at the provider (if not already logged in) and grants consent.
4. Provider redirects back to iDempiere with an authorization code.
5. iDempiere’s backend exchanges the authorization code for an access token (and optionally a refresh token and ID token) via a server-to-server request.
6. iDempiere reads the user’s identity from the ID token or by calling the provider’s userinfo endpoint.
7. iDempiere looks up the corresponding AD_User record (matching on email or a stored provider subject ID), validates that the user is active and has roles assigned, and establishes the iDempiere session.

Implementation Considerations

• User mapping: The OAuth2 provider returns a subject identifier (email, unique ID). You need a reliable mapping to AD_User records. Store the provider’s subject ID in a custom column on AD_User (e.g., OAuthSubjectID) for exact matching.
• First-time provisioning: Decide whether to auto-create AD_User records for authenticated users who do not yet exist in iDempiere (just-in-time provisioning), or require an administrator to pre-create accounts.
• Role selection: After OAuth2 authentication, the user still needs to select a role, client, organization, and warehouse. You can either present the standard role selection dialog or auto-select defaults based on the user’s profile or group membership in the identity provider.
• Token management: Store access and refresh tokens securely (encrypted in the database or in an HTTP-only secure cookie). Implement token refresh logic to maintain the session without requiring re-authentication.

OpenID Connect (OIDC)

OpenID Connect is an identity layer built on top of OAuth2. While OAuth2 provides authorization (access to resources), OIDC adds authentication (identity verification) by defining a standard ID token format (JWT) and a userinfo endpoint. Most modern identity providers (Azure AD, Okta, Google, Keycloak) support OIDC natively. When implementing SSO for iDempiere, prefer OIDC over plain OAuth2 because it provides standardized identity claims (subject, email, name) and eliminates the need for an additional userinfo API call.

SAML Integration for Enterprise SSO

SAML (Security Assertion Markup Language) is the dominant SSO protocol in enterprise environments. It enables users to authenticate once with their organization’s Identity Provider (IdP) — such as ADFS, Okta, Ping Identity, or Azure AD — and access multiple Service Providers (SP) including iDempiere without entering credentials again.

SAML Flow

1. SP-initiated SSO: User navigates to iDempiere. iDempiere (acting as SP) detects no active session and generates a SAML AuthnRequest, which it sends to the IdP via browser redirect.
2. IdP authentication: The IdP authenticates the user (using whatever method it supports — password, MFA, smart card) and generates a SAML Response containing assertions about the user’s identity and attributes.
3. Assertion consumption: The IdP posts the SAML Response to iDempiere’s Assertion Consumer Service (ACS) URL. iDempiere validates the response signature, checks the assertion conditions (timestamps, audience), and extracts user attributes.
4. Session establishment: iDempiere maps the SAML NameID or attributes to an AD_User record and establishes the iDempiere session.

Implementation Approach

Implementing SAML in iDempiere requires a plugin that includes a SAML library (such as OpenSAML or OneLogin’s SAML toolkit) and registers the necessary servlet endpoints:

• Metadata endpoint: Publishes the SP metadata (entity ID, ACS URL, signing certificate) that the IdP needs for configuration.
• ACS endpoint: Receives and processes the SAML Response from the IdP.
• SLO endpoint (optional): Handles Single Logout — when the user logs out of the IdP, all SP sessions are terminated.

// SAML Assertion Consumer Service - processing the IdP response
@WebServlet("/saml/acs")
public class SAMLConsumerServlet extends HttpServlet {

    @Override
    protected void doPost(HttpServletRequest request,
                          HttpServletResponse response)
            throws ServletException, IOException {

        String samlResponse = request.getParameter("SAMLResponse");

        // Decode and validate the SAML Response
        Response samlResp = decodeSAMLResponse(samlResponse);
        validateSignature(samlResp);
        validateConditions(samlResp);

        // Extract user identity
        String nameId = samlResp.getAssertions().get(0)
            .getSubject().getNameID().getValue();
        String email = getAttributeValue(samlResp, "email");

        // Map to iDempiere user
        int userId = findUserByEmail(email);
        if (userId <= 0) {
            response.sendError(403, "No iDempiere account for: " + email);
            return;
        }

        // Establish iDempiere session
        establishSession(request, userId);
        response.sendRedirect("/webui/");
    }
}

SAML vs OAuth2: When to Use Which

• SAML: Preferred in traditional enterprise environments with ADFS, Shibboleth, or legacy IdPs. Better for browser-based SSO in corporate intranets. More mature and widely supported in enterprise software.
• OAuth2/OIDC: Preferred for modern cloud-first environments. Better for API-based authentication. Simpler to implement. Required when integrating with consumer identity providers (Google, GitHub).
• Both: Many identity providers (Okta, Azure AD, Keycloak) support both protocols. You may implement both in iDempiere to accommodate different integration scenarios.

Custom LoginDialog Modifications

To support SSO and custom authentication, you may need to modify the iDempiere login interface. This is done through a plugin that extends or replaces the default login components.

Adding SSO Buttons

Create a custom login panel that extends the default LoginPanel and adds SSO initiation buttons:

public class SSOLoginPanel extends LoginPanel {

    @Override
    protected void initComponents() {
        super.initComponents();  // Render default login form

        // Add a visual separator
        Separator sep = new Separator();
        sep.setBar(true);
        loginPanel.appendChild(sep);

        Label orLabel = new Label("Or sign in with:");
        loginPanel.appendChild(orLabel);

        // Add SSO button below the standard login form
        Button ssoButton = new Button("Corporate SSO (SAML)");
        ssoButton.addEventListener(Events.ON_CLICK, event -> {
            String ssoUrl = buildSAMLAuthnRequestUrl();
            Executions.getCurrent().sendRedirect(ssoUrl);
        });
        loginPanel.appendChild(ssoButton);

        // Add OAuth2 button
        Button oauthButton = new Button("Sign in with Microsoft");
        oauthButton.addEventListener(Events.ON_CLICK, event -> {
            String oauthUrl = buildOAuthAuthorizationUrl();
            Executions.getCurrent().sendRedirect(oauthUrl);
        });
        loginPanel.appendChild(oauthButton);
    }
}

Registering the Custom Login Panel

Use iDempiere’s form factory mechanism or a ZK page extension to replace the default login panel with your custom version. This is typically done by registering an OSGi component that provides the custom form, overriding the default login window definition in the Application Dictionary or through a ZUL page customization.

Two-Factor Authentication

Two-factor authentication (2FA) adds a second verification step beyond the password. After entering the username and password (first factor — something you know), the user must provide a second factor — typically a time-based one-time password (TOTP) generated by an authenticator app (something you have).

TOTP Implementation Approach

1. Secret generation: When a user enables 2FA, generate a random secret key and store it (encrypted) in the AD_User table or a related table. Display the secret as a QR code that the user scans with their authenticator app (Google Authenticator, Microsoft Authenticator, Authy).
2. Code verification: After successful password authentication, present a TOTP code entry dialog. Use a TOTP library (e.g., GoogleAuth for Java) to validate the entered code against the stored secret.
3. Backup codes: Generate a set of one-time backup codes that the user can store securely for use if they lose access to their authenticator app.
4. Recovery: Provide an administrative process to reset 2FA for a user who has lost both their authenticator device and backup codes.

// TOTP verification using GoogleAuth library
GoogleAuthenticator gAuth = new GoogleAuthenticator();

// During 2FA enrollment - generate and store secret
GoogleAuthenticatorKey key = gAuth.createCredentials();
String secret = key.getKey();
// Store 'secret' encrypted in AD_User or a custom table
// Generate QR code URL for the authenticator app
String qrUrl = GoogleAuthenticatorQRGenerator.getOtpAuthURL(
    "iDempiere", user.getEMail(), key);

// During login - verify the TOTP code
boolean isValid = gAuth.authorize(storedSecret, userEnteredCode);
if (!isValid) {
    throw new AuthenticationException("Invalid 2FA code");
}

Session Management and Security

Proper session management is critical for security in any web application, and especially so for an ERP system that handles sensitive financial and business data.

Session Timeout Configuration

Configure appropriate session timeouts in the web.xml or iDempiere system configuration:

• Idle timeout: Terminate sessions after a period of inactivity (typically 30-60 minutes for ERP systems). Shorter timeouts are more secure but may frustrate users working on long data entry tasks.
• Absolute timeout: Terminate sessions after a maximum duration regardless of activity (e.g., 8-12 hours) to limit the window of exposure for stolen session tokens.

Concurrent Session Control

The AD_Session table tracks active sessions. You can implement concurrent session control by:

• Limiting the number of active sessions per user (prevent credential sharing).
• Terminating the oldest session when a new one is created (single-session policy).
• Alerting administrators when a user has sessions from multiple IP addresses simultaneously.

Security Hardening for Production

Beyond authentication, a production iDempiere deployment requires comprehensive security hardening.

Password Policies

• Complexity requirements: Enforce minimum length (12+ characters), character class requirements (uppercase, lowercase, digits, special characters), and prohibit common passwords.
• Password expiration: Require password changes at regular intervals (90 days is common, though modern guidance from NIST suggests against forced rotation if passwords are strong).
• Password history: Prevent reuse of recent passwords (maintain a history of the last 10-12 password hashes).

Account Lockout

iDempiere tracks failed login attempts in the AD_User.FailedLoginCount field. Configure automatic account lockout after a threshold of failed attempts (typically 5-10). Implement a lockout duration (e.g., 30 minutes) after which the account automatically unlocks, or require administrative intervention for unlock.

SSL/TLS Configuration

All iDempiere web traffic must be encrypted with TLS in production. The recommended approach is TLS termination at a reverse proxy:

# Nginx reverse proxy with TLS termination for iDempiere
server {
    listen 443 ssl http2;
    server_name erp.company.com;

    ssl_certificate /etc/letsencrypt/live/erp.company.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/erp.company.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers on;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Audit Trail

Enable comprehensive auditing for security-sensitive operations:

• All login and logout events (successful and failed) — tracked in AD_Session and AD_ChangeLog.
• Changes to security-sensitive records (users, roles, access rules) — tracked by iDempiere’s change log mechanism.
• Document completions and voids — tracked in the document’s processing history.
• Export and report execution — for data exfiltration monitoring.

Network Security

• Restrict direct access to the iDempiere application port (8080) — only the reverse proxy should reach it.
• Restrict database access to the application server only — never expose PostgreSQL to the internet.
• Use a Web Application Firewall (WAF) to protect against common web attacks (SQL injection, XSS, CSRF).
• Implement IP allowlisting for administrative access if possible.

Security Best Practices Summary

The following checklist summarizes the essential security measures for a production iDempiere deployment:

1. Enforce TLS for all web traffic and database connections.
2. Integrate with the organization’s identity provider (LDAP, SAML, or OAuth2/OIDC).
3. Implement two-factor authentication for privileged users at minimum.
4. Configure password policies appropriate to your organization’s security requirements.
5. Enable account lockout after failed login attempts.
6. Set appropriate session timeouts (idle and absolute).
7. Enable change logging for security-sensitive tables.
8. Restrict network access using firewalls and security groups.
9. Regularly review user accounts and role assignments — remove inactive users promptly.
10. Monitor authentication logs for anomalies (failed login spikes, unusual access patterns, off-hours logins).

Summary

Enterprise authentication in iDempiere extends well beyond the default username/password mechanism. A production deployment should integrate with the organization’s identity infrastructure through LDAP, OAuth2, or SAML, enforce strong security policies, and maintain comprehensive audit trails. The key takeaways are:

• iDempiere’s authentication is centered on the Login class and can be extended through plugins.
• LDAP integration is supported natively for basic authentication delegation; custom providers handle more complex scenarios.
• OAuth2/OIDC and SAML provide enterprise SSO, reducing password fatigue and centralizing identity management.
• Two-factor authentication adds a critical layer of protection for ERP systems handling sensitive business data.
• Security hardening is a holistic effort spanning passwords, session management, encryption, and auditing.

In the next lesson, we will tackle data migration — how to plan and execute the transfer of data from legacy systems to iDempiere with minimal risk and maximum confidence.

# LDAP connection test from iDempiere server using ldapsearch
ldapsearch -H ldaps://ad.company.com:636 \
  -D "CN=svc_idempiere,OU=ServiceAccounts,DC=company,DC=com" \
  -W \
  -b "OU=Users,DC=company,DC=com" \
  "(sAMAccountName=jsmith)" \
  cn mail memberOf

/**
 * Custom authentication provider that checks LDAP first,
 * then falls back to database authentication.
 */
public class CustomAuthenticator {

    private static final String LDAP_URL = "ldaps://ad.company.com:636";
    private static final String LDAP_BASE_DN = "DC=company,DC=com";

    /**
     * Authenticate user against LDAP directory.
     * Returns true if authentication succeeds.
     */
    public boolean authenticateLDAP(String username, String password) {
        Hashtable<String, String> env = new Hashtable<>();
        env.put(Context.INITIAL_CONTEXT_FACTORY,
            "com.sun.jndi.ldap.LdapCtxFactory");
        env.put(Context.PROVIDER_URL, LDAP_URL);
        env.put(Context.SECURITY_AUTHENTICATION, "simple");
        env.put(Context.SECURITY_PRINCIPAL,
            username + "@company.com");
        env.put(Context.SECURITY_CREDENTIALS, password);
        env.put(Context.SECURITY_PROTOCOL, "ssl");

        try {
            DirContext ctx = new InitialDirContext(env);
            ctx.close();
            return true;  // LDAP bind succeeded
        } catch (AuthenticationException e) {
            log.info("LDAP auth failed for " + username +
                ": " + e.getMessage());
            return false;
        } catch (NamingException e) {
            log.warning("LDAP connection error: " + e.getMessage());
            return false;  // LDAP unavailable, allow fallback
        }
    }

    /**
     * Multi-provider authentication: try LDAP first,
     * then database.
     */
    public boolean authenticate(String username, String password) {
        // Try LDAP authentication first
        if (authenticateLDAP(username, password)) {
            log.info("User " + username +
                " authenticated via LDAP");
            return true;
        }

        // Fall back to database authentication
        // (useful for service accounts or when LDAP is down)
        return authenticateDatabase(username, password);
    }
}

// SAML Assertion Consumer Service - processing the IdP response
@WebServlet("/saml/acs")
public class SAMLConsumerServlet extends HttpServlet {

    @Override
    protected void doPost(HttpServletRequest request,
                          HttpServletResponse response)
            throws ServletException, IOException {

        String samlResponse = request.getParameter("SAMLResponse");

        // Decode and validate the SAML Response
        Response samlResp = decodeSAMLResponse(samlResponse);
        validateSignature(samlResp);
        validateConditions(samlResp);

        // Extract user identity
        String nameId = samlResp.getAssertions().get(0)
            .getSubject().getNameID().getValue();
        String email = getAttributeValue(samlResp, "email");

        // Map to iDempiere user
        int userId = findUserByEmail(email);
        if (userId <= 0) {
            response.sendError(403, "No iDempiere account for: " + email);
            return;
        }

        // Establish iDempiere session
        establishSession(request, userId);
        response.sendRedirect("/webui/");
    }
}

public class SSOLoginPanel extends LoginPanel {

    @Override
    protected void initComponents() {
        super.initComponents();  // Render default login form

        // Add a visual separator
        Separator sep = new Separator();
        sep.setBar(true);
        loginPanel.appendChild(sep);

        Label orLabel = new Label("Or sign in with:");
        loginPanel.appendChild(orLabel);

        // Add SSO button below the standard login form
        Button ssoButton = new Button("Corporate SSO (SAML)");
        ssoButton.addEventListener(Events.ON_CLICK, event -> {
            String ssoUrl = buildSAMLAuthnRequestUrl();
            Executions.getCurrent().sendRedirect(ssoUrl);
        });
        loginPanel.appendChild(ssoButton);

        // Add OAuth2 button
        Button oauthButton = new Button("Sign in with Microsoft");
        oauthButton.addEventListener(Events.ON_CLICK, event -> {
            String oauthUrl = buildOAuthAuthorizationUrl();
            Executions.getCurrent().sendRedirect(oauthUrl);
        });
        loginPanel.appendChild(oauthButton);
    }
}

// TOTP verification using GoogleAuth library
GoogleAuthenticator gAuth = new GoogleAuthenticator();

// During 2FA enrollment - generate and store secret
GoogleAuthenticatorKey key = gAuth.createCredentials();
String secret = key.getKey();
// Store 'secret' encrypted in AD_User or a custom table
// Generate QR code URL for the authenticator app
String qrUrl = GoogleAuthenticatorQRGenerator.getOtpAuthURL(
    "iDempiere", user.getEMail(), key);

// During login - verify the TOTP code
boolean isValid = gAuth.authorize(storedSecret, userEnteredCode);
if (!isValid) {
    throw new AuthenticationException("Invalid 2FA code");
}

# Nginx reverse proxy with TLS termination for iDempiere
server {
    listen 443 ssl http2;
    server_name erp.company.com;

    ssl_certificate /etc/letsencrypt/live/erp.company.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/erp.company.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers on;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

# LDAP connection test from iDempiere server using ldapsearch
ldapsearch -H ldaps://ad.company.com:636 \
  -D "CN=svc_idempiere,OU=ServiceAccounts,DC=company,DC=com" \
  -W \
  -b "OU=Users,DC=company,DC=com" \
  "(sAMAccountName=jsmith)" \
  cn mail memberOf

/**
 * Custom authentication provider that checks LDAP first,
 * then falls back to database authentication.
 */
public class CustomAuthenticator {

    private static final String LDAP_URL = "ldaps://ad.company.com:636";
    private static final String LDAP_BASE_DN = "DC=company,DC=com";

    /**
     * Authenticate user against LDAP directory.
     * Returns true if authentication succeeds.
     */
    public boolean authenticateLDAP(String username, String password) {
        Hashtable<String, String> env = new Hashtable<>();
        env.put(Context.INITIAL_CONTEXT_FACTORY,
            "com.sun.jndi.ldap.LdapCtxFactory");
        env.put(Context.PROVIDER_URL, LDAP_URL);
        env.put(Context.SECURITY_AUTHENTICATION, "simple");
        env.put(Context.SECURITY_PRINCIPAL,
            username + "@company.com");
        env.put(Context.SECURITY_CREDENTIALS, password);
        env.put(Context.SECURITY_PROTOCOL, "ssl");

        try {
            DirContext ctx = new InitialDirContext(env);
            ctx.close();
            return true;  // LDAP bind succeeded
        } catch (AuthenticationException e) {
            log.info("LDAP auth failed for " + username +
                ": " + e.getMessage());
            return false;
        } catch (NamingException e) {
            log.warning("LDAP connection error: " + e.getMessage());
            return false;  // LDAP unavailable, allow fallback
        }
    }

    /**
     * Multi-provider authentication: try LDAP first,
     * then database.
     */
    public boolean authenticate(String username, String password) {
        // Try LDAP authentication first
        if (authenticateLDAP(username, password)) {
            log.info("User " + username +
                " authenticated via LDAP");
            return true;
        }

        // Fall back to database authentication
        // (useful for service accounts or when LDAP is down)
        return authenticateDatabase(username, password);
    }
}

// SAML Assertion Consumer Service - processing the IdP response
@WebServlet("/saml/acs")
public class SAMLConsumerServlet extends HttpServlet {

    @Override
    protected void doPost(HttpServletRequest request,
                          HttpServletResponse response)
            throws ServletException, IOException {

        String samlResponse = request.getParameter("SAMLResponse");

        // Decode and validate the SAML Response
        Response samlResp = decodeSAMLResponse(samlResponse);
        validateSignature(samlResp);
        validateConditions(samlResp);

        // Extract user identity
        String nameId = samlResp.getAssertions().get(0)
            .getSubject().getNameID().getValue();
        String email = getAttributeValue(samlResp, "email");

        // Map to iDempiere user
        int userId = findUserByEmail(email);
        if (userId <= 0) {
            response.sendError(403, "No iDempiere account for: " + email);
            return;
        }

        // Establish iDempiere session
        establishSession(request, userId);
        response.sendRedirect("/webui/");
    }
}

public class SSOLoginPanel extends LoginPanel {

    @Override
    protected void initComponents() {
        super.initComponents();  // Render default login form

        // Add a visual separator
        Separator sep = new Separator();
        sep.setBar(true);
        loginPanel.appendChild(sep);

        Label orLabel = new Label("Or sign in with:");
        loginPanel.appendChild(orLabel);

        // Add SSO button below the standard login form
        Button ssoButton = new Button("Corporate SSO (SAML)");
        ssoButton.addEventListener(Events.ON_CLICK, event -> {
            String ssoUrl = buildSAMLAuthnRequestUrl();
            Executions.getCurrent().sendRedirect(ssoUrl);
        });
        loginPanel.appendChild(ssoButton);

        // Add OAuth2 button
        Button oauthButton = new Button("Sign in with Microsoft");
        oauthButton.addEventListener(Events.ON_CLICK, event -> {
            String oauthUrl = buildOAuthAuthorizationUrl();
            Executions.getCurrent().sendRedirect(oauthUrl);
        });
        loginPanel.appendChild(oauthButton);
    }
}

// TOTP verification using GoogleAuth library
GoogleAuthenticator gAuth = new GoogleAuthenticator();

// During 2FA enrollment - generate and store secret
GoogleAuthenticatorKey key = gAuth.createCredentials();
String secret = key.getKey();
// Store 'secret' encrypted in AD_User or a custom table
// Generate QR code URL for the authenticator app
String qrUrl = GoogleAuthenticatorQRGenerator.getOtpAuthURL(
    "iDempiere", user.getEMail(), key);

// During login - verify the TOTP code
boolean isValid = gAuth.authorize(storedSecret, userEnteredCode);
if (!isValid) {
    throw new AuthenticationException("Invalid 2FA code");
}

# Nginx reverse proxy with TLS termination for iDempiere
server {
    listen 443 ssl http2;
    server_name erp.company.com;

    ssl_certificate /etc/letsencrypt/live/erp.company.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/erp.company.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers on;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-XSS-Protection "1; mode=block" always;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}