1
votes

In a Spring Security/Boot application I have configured basic authentication for a specific URL-pattern:

http.antMatcher(StringUtils.join("myURL", "/**")).authorizeRequests().anyRequest().authenticated().and().httpBasic().realmName("realmName");

This works like a charm, as in when I request an URL of that pattern I am prompted by the browser to provide credentials and afterwards I can access that endpoint. However, after successfully authorizing for this endpoint, the browser sends the Authorization header with the "Basic ..." token even for requests to URLs that have nothing to do with the one configured in the above code. For example the websites homepage.

This causes other authorization mechanisms of the webapp, namely keycloak, to fire because they expect valid tokens inside of the Authorization header. I know that I can configure keycloak in a way that it does not try to interpret an Authorization-Header that begins with "Basic ", but it seems like the root cause of this dilemma is that the Header get's sent for requests that don't belong to the basic-auth URL.

Is there any way that I can tell Spring Security / the browser / whoever that the basic-auth Authorization header should only be included in the request if the request is for an URL matching the pattern that http-basic was configured for? Shouldn't this be standard behavior anyway?

Example URLs:

  • localhost:8083/myURL : I expect the browser to send the Authentication Header
  • localhost:8083/myURL/moreURL : I also expect the browser to send the Authentication Header
  • localhost:8083/someOtherURL : I do not expect the browser to send the Authentication Header, but it does!
  • localhost:8083/someOtherURL/moreURL : Same thing, browser sends the Header unexpectedly
1

1 Answers

1
votes

Your applications have to use different containing directories and different realms, see RFC 2617:

2 Basic Authentication Scheme

[...]
A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server.

and see also Chromium source:

// Helper to find the containing directory of path. In RFC 2617 this is what
// they call the "last symbolic element in the absolute path".
// Examples:
//   "/foo/bar.txt" --> "/foo/"
//   "/foo/" --> "/foo/"

In your case the containing directory is / for one of your applications. The other application is in a sub-path of that containing directory. Hence, your browser preemptively send the the same Authorization header to both applications.