Should be able to modify how credentials are extracted from the HTTP request

[merose]

The authentication/authorization process is configurable via a custom AuthModule. However, the process of extracting the credentials from an HTTP request is currently hard-coded in the HttpAuthorizationChecker class. It would be convenient if the process of obtaining credentials could be configured, perhaps through a custom class, as is done for AuthModule, or perhaps by a set of configured custom and builtin classes, so that multiple schemes for the credentials could be supported simultaneously.

[fqqb]

The code was reorganized a bit in recent commits. I think you’re referring to making the handling of this clause configurable:

yamcs/yamcs-core/src/main/java/org/yamcs/http/HttpRequestHandler.java

Line 243 in 203b6c3

throw new BadRequestException("Unsupported Authorization header '" + authorizationHeader + "'");

So support hooking other schemes than “Basic” and “Bearer” in the Authorization header.

This can be done, but I’d like confirmation that this will really help your use case, as you should be aware that all official clients (web interface, Yamcs Studio, Python client) rely on those bearer tokens. The “Basic” support is only there for convenience with curl.

An alternative way to go about this, is to generate standard Yamcs bearer tokens based on your custom HTTP constraints. This was the original design choice we had. The idea being that all clients use bearer tokens, and that if a deployment has specific HTTP-level constraint, this could somehow be abstracted into a custom (unprotected) HTTP path where the custom mechanism is first converted into a standard Yamcs bearer token.

In the source code there’s currently only one example of this: SPNEGO. Details don’t matter, but basically there’s a token exchange that occurs between the browser and the server (independent of Yamcs bearer tokens) but we do that only on the /auth/spnego path and the end result is that a Yamcs bearer token is generated representing the real underlying token. From that point onwards all official clients can keep on working with the standard Yamcs bearer tokens.

Note that there’s already a low-level hook in place for adding custom URI routes that are not subject to any standard authorization checks:

yamcs/yamcs-core/src/main/java/org/yamcs/http/HttpServer.java

Line 269 in 203b6c3

public void addHandler(String pathSegment, Supplier<Handler> handlerSupplier) {

Of course this approach suffers from similar problems in that all official clients will not support your custom exchange. The python client is extensible in this regard, but for the Web interface and Yamcs Studio this is a bit more difficult. Would that be a problem for you?

One typical case we don’t have good support for is where the login occurs via an external login page. In this case also the Yamcs web interface would need to be aware of this, so it can properly redirect. I guess I’m wondering if your situation would fall under this use case.

[merose]

Closing this issue because the Yamcs code has changed considerably. I believe our use case, which is a little different than @fqqb has outlined, is now supported.