We have an slowly growing collection of internal web sites (for staff) that need authentication, and we also have a web single sign on (SSO) system. But despite having a SSO system, we barely use it and we keep using Apache based HTTP Basic Authentication instead, despite the annoyance and inconvenience of having to tell various websites the same thing. The fundamental problem that keeps us doing this is the tradeoff between a SSO system and availability.

A SSO system is very convenient when it works, but if and when it's down for some reason, it's a single point that prevents you from using anything else (unless you happen to be lucky). Many of the staff things that we could protect with SSO are in fact exactly the things we most want to be available when the rest of our systems are falling over; for example, it would be pretty bad if our metrics system's dashboards weren't accessible during an outage. Grafana Loki? Our searchable archive of our worklogs? All things that we really, really want to have access to if at all possible, and that need access restrictions.

In an ideal world, you could use either authentication method, so you'd use SSO while it was working and be able to fall back to another way, such as HTTP Basic Authentication, if SSO wasn't up. However as far as I know Apache doesn't directly provide any easy way to do this, either as a choice you make in your browser or as something that happens automatically on the server side. The mechanics of HTTP Basic Authentication in practice would make a browser choice somewhat difficult, as the browser only knows to send HTTP Basic Authentication when challenged (more or less).

You can imagine a collection of hacks that would achieve this in a hypothetical web server (and possibly be something you could realize in Apache). There are two possible approaches I see. First, most SSO systems wind up setting a cookie in your browser for the site, so you could in theory create a separate web app on the site, protected by HTTP Basic Authentication, that 'forges' the SSO cookie itself. Second, you could have a similar HTTP Basic Authentication protected web application that sets a browser cookie that causes the authentication protected section of the site to switch from SSO to HTTP Basic Authentication. In both cases, your actual authentication protected web area would default to SSO, and you'd visit another, special URL on the site to authenticate with HTTP Basic Authentication instead.

(The first approach is likely more complicated but has the advantage that the complexity is concentrated in the web app, which has to be able to generate a valid local 'SSO has been done' cookie and any other stuff necessary, such as session database entries.)

You might be able to do this backward as well; if you can switch behavior on a cookie, you can switch on the SSO cookie instead. You'd probably want to make the authentication protected area switch to the full SSO setup at that point, so that if people have an outdated or made up SSO cookie, they get forced through the SSO re-authentication process. However, things will get complicated in your life if someone has an outdated SSO cookie while your SSO system isn't working.