We use the custom http-auth-handler mechanism described here:

https://developer.atlassian.com/bitbucket/server/docs/latest/reference/plugin-module-types/http-authentication-handler.html

On the mirror server, it calls out to /rest/mirroring/1.0/authenticate to delegate authentication to the upstream server. On the upstream server, the resource handler for this method calls com.atlassian.bitbucket.internal.mirroring.upstream.auth.AuthenticationService.authenticateForUser() which calls com.atlassian.bitbucket.internal.mirroring.upstream.auth.DefaultAuthenticationService.authenticateForUser() which calls crowdControl.authenticate(). This effectively bypasses the http-auth-handler capability.

In our case, we have two different types of usernames. One which is the one most people know and remember, that is related to their email address, and one which is an internal form that is permanently unique. Normally we use http-auth-handler to recognize both of these, and return the right ApplicationUser whether they login with one form or the other. You can think of this similar to how your jira.atlassian.com site allows users to login with their email address but once logged in you can clearly see that the backend username used in JIRA is something different.

Now that we are trying to use the Smart Mirror capability, it doesn't work when using "http://USERNAME@MIRROR/..." when the user uses the form they know and remember. It only works when the USERNAME is the same as the backend username form. The http-auth-handler has no effect.

I did try to put our http-auth-handler on the mirror by adding the plugin to the bitbucket-data/shared/plugins/installed-plugins directory, but that made them both fail. After some investigation, it seems this is because it needs to implement the "internal" DelegatedHttpAuthenticationHandler which also seems problematic to pursue.

For now, I am thinking that we can recommend users use SSH on the mirror when they need to authenticate, and HTTPS on the mirror for anonymous access (important new feature in Bitbucket 4.4.2, thanks!). However, there may be cases where they still want to use HTTPS on the mirror with authentication, and requiring them to be aware of their backend username when this requirement does not exist on the upstream server, will be confusing for users.