Hi Mridul, Thank you for testing and your valuable feedback, I will review your Above design points and comments in the PR's and work on the enhancements required, and get back to you.
Kind Regards, Krishna Uprit Application Security Engineer *HotWax Systems* *Enterprise open source experts* cell: +91-7999304341 <+91%2079993%2004341> http://www.hotwaxsystems.com On Thu, Nov 12, 2026 at 5:50 PM Mridul Pathak via dev <[email protected]> wrote: > Hi Krishna, > > Thanks for putting this together. Native MFA is something OFBiz has needed > for a long time, and the staged login (holding back the successful-login > bookkeeping until the second factor passes) looks like the right foundation > to me. I read the document and both PRs, then applied them on current trunk > and tried the flows locally with MFA enabled. Enrollment, the login > challenge, replay rejection of a used code and the isolation of the pending > session all worked well for me. > > Here is what I ran into while testing: > > * Wrong codes are limited per challenge only. I entered 18 wrong codes > across three password logins and could still log in with a valid code > afterwards; successiveFailedLogins was never touched. I think failed > second-factor attempts need to count towards the account lockout, on both > the web and REST paths. > * An account that is disabled while its login is waiting at the challenge > page gets logged in and re-enabled (enabled=Y, disabledBy cleared) once the > code is submitted. The account state probably needs to be re-checked at > completion. > * With HTTP header login, the challenge is shown but a valid code ends in > "Unable to complete login" (completeUserLoginMfa returns > "Authentication-factor policy changed; restart login"). From the code I > expect the same for the JWT, remote user and certificate paths. > * On REST, a challenge created through /rest/auth/token can be verified > through /rest/auth/{anyGroup}/mfa/{challengeId}/verify, and the token is > issued for that group without the group being validated or its base > permission checked. > * The Basic auth filter still runs the full userLogin service, so > UserLoginHistory is written at step 1, before the second factor. > * Once the re-authentication window has passed, password change and factor > management ask the user to "sign in again", and I could not find a way to > re-verify a code without logging out. > > A few design points I would like to discuss: > > * Recovery: there are no backup codes, and email password recovery is > blocked for MFA accounts, so a lost phone needs an administrator. That may > be hard on storefront customers. > * Channels: it would help to list every authentication channel in the > proposal (service-level login.username/login.password, REST, JWT SSO, > header and certificate login, external login key) and how each one behaves > when MFA is required. > * Library: dev.samstevens.totp has not had a release since 2020 and brings > in commons-net and zxing javase, while we only use its code and secret > generators. Since zxing core is already a dependency and RFC 6238 is small, > I would lean towards implementing it on javax.crypto and testing against > the RFC vectors, or picking a maintained library. > * Standards: I believe "totp" is not a registered amr value in RFC 8176 > ("otp" and "mfa" are). It would also be good to confirm the factor model > leaves room for WebAuthn/passkeys later, since TOTP alone is not phishing > resistant. > > Some smaller things: > > * The document and the code differ in places: the QR code is a PNG rather > than SVG, the acr claim and the totp.window property are not in the code, > and the re-authentication window is 300 seconds. > * A few changes apply even when MFA is disabled: the updatePassword event > replacement, the form macro changes in the common theme, and the external > login key lifetime going from 2 to 15 minutes. I think these are better as > separate tickets so that nothing changes for existing deployments. > * * Most of the new UI text is hardcoded in English, and Working.md at the > repository root would be better placed with the rest of the documentation > rather than at the top level. > > Would it be possible to create a Jira ticket and split the work into > smaller PRs (entities and services, web login flow, REST, storefront)? That > would make it much easier to review and test each part. I am happy to add > line-level comments on the PRs and to help test the next iteration. > > Thanks again for the effort on this. > > Regards, > Mridul Pathak > > On Wed, Nov 11, 2026 at 4:55 PM Krishna Uprit < > [email protected]> wrote: > > > Hi everyone, > > > > Modern identity security standards (*NIST SP 800-63B, PCI-DSS 4.0*) > > increasingly require *Multi-Factor Authentication (MFA)* for enterprise > and > > administrative applications. > > > > - While Apache OFBiz provides solid primary credential handling, > > secondary factor > > verification has historically required custom integration or third-party > > gateways. > > > > Over the past few weeks, I have designed and implemented a native, *RFC > > 6238 Time-Based One-Time Password (TOTP)* architecture for Apache OFBiz. > > The goal is to provide a production-ready, zero-trust MFA capability that > > adheres strictly to core OFBiz idioms without breaking existing > > deployments. > > > > - *Detailed Proposal Document:* > > > > I have compiled a comprehensive architecture proposal covering entity > > models, session state boundaries, controller flows, and REST token > > specifications: > > > > *Document:* > > > > > https://docs.google.com/document/d/1Ugqe8Z5vm2Ikkr55o2eDlYbjpvszVbuuEK8P-e-tzYw/edit?usp=sharing > > > > *Architectural Highlights:* > > > > • *Staged Authentication Lifecycle:* > > > > -- Introduces an isolated intermediate stage (*PRIMARY_VERIFIED ➔ > > MFA_PENDING ➔ AUTHENTICATION_COMMITTED*). > > -- This guarantees that user sessions, cookies, or successful login > > histories are never committed to the database until the second factor > > is successfully > > verified, preventing pre-MFA state poisoning. > > > > • *Air-Gapped RFC 6238 TOTP:* > > > > -- Compatible with standard authenticators (*Google Authenticator, > > Microsoft Authenticator,* etc.). > > -- QR codes are generated directly *in-memory *as SVG Data URIs—no > external > > CDNs or third-party web APIs (like Google Charts) are ever contacted. > > > > • *Double Session Rotation:* > > > > -- HTTP session IDs are regenerated upon primary password entry, and > > regenerated again immediately upon TOTP verification to mitigate session > > fixation. > > > > • *Granular Policy & Interstitials:* > > > > -- Supports self-service enrollment under user profiles as well as > > group-level mandatory enforcement (requireAuthFactor="Y" on > SecurityGroup) > > with forced enrollment interstitials. > > > > • *Two-Step REST API Handshake:* > > > > *-- *The /rest component supports an interactive two-step token exchange > > (HTTP > > 202 MFA_REQUIRED challenge returning opaque ID ➔ verification returning > JWT > > with RFC 8176 amr: ["pwd", "totp"] and acr: "loa-mfa" claims). > > > > • *Complete UI Support (Backoffice + B2C Storefront):* > > > > *-- *Fully integrated into core backoffice themes, as well as the > > public customer > > storefront (plugins/ecommerce). > > > > • *100% Backward Compatibility:* > > > > -- The feature is globally disabled by default ( > > *security.login.authFactor.enable=false*). > > -- Existing service calls, automated integration test suites, and > > password-only workflows continue to operate without any breaking changes. > > > > *Implementation & Verification:* > > > > The code has been verified with comprehensive integration tests > > (UserLoginTests.groovy, LoginEventsTests.java, and > > JWTManagerAssuranceTests.java > > covering challenge lifecycles, replay rejection, forced enrollment, > step-up > > password changes, and token claims). > > > > - The implementation is split cleanly across the framework and plugins > > repositories: > > > > • *Framework Pull Request:* > > https://github.com/apache/ofbiz-framework/pull/2620 > > • *Plugins Pull Request:* > > https://github.com/apache/ofbiz-plugins/pull/523 > > > > I would like to invite the community to review the proposal document, > look > > through the PR's, and share your valuable thoughts and feedback. > > > > Kind Regards, > > Krishna Uprit > > Application Security Engineer > > *HotWax Systems* > > *Enterprise open source experts* > > cell: +91-7999304341 <+91%2079993%2004341> <+91%2079993%2004341> > <+91%2079993%2004341> > > http://www.hotwaxsystems.com > > >
