A legacy permitting app cannot speak SAML, yet the county refuses to weaken MFA for everyone. Which interoperability approach is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
When an old permitting box cannot speak SAML, you build a careful on-ramp—not tear MFA off the whole county. Bridge the gap; do not lower the drawbridge for attackers.
Full Explanation
Legacy permitting applications that cannot speak SAML still must not force the county to weaken MFA and federation for everyone else. The appropriate interoperability approach is a bridge or wrapper—such as a reverse-proxy/web application portal, identity gateway, or protocol translation layer—that fronts the legacy app, enforces modern authentication (MFA/SSO) at the edge, and connects users without disabling organization-wide controls. That pattern modernizes access to the old permitting box while preserving the municipal identity baseline.
Turning off MFA organization-wide so the legacy app matches weaker peers lowers security for all systems to the least capable dependency. Forcing everyone off SSO onto sticky-note passwords multiplies credential sprawl and help-desk risk. Publishing the app anonymously on the Internet without authentication exposes permitting data and workflows to the world.
Exam caveat: bridges add components that need hardening, patching, and careful session handling—do not treat the wrapper as automatically safe. Long term, plan remediation or replacement of the legacy app rather than perpetual exceptions.
Operational check: place the permitting app behind an IdP-integrated access proxy that requires MFA, confirm direct legacy login paths are blocked from the Internet, monitor bridge logs for auth failures and anomalies, and track a roadmap item to replace or federate the app natively.