rvesse commented on issue #1767: URL: https://github.com/apache/jena/issues/1767#issuecomment-1451984143
> maybe something like this: https://archive.ph/9yXqV > > (haven't tried) Well as that example shows configuring Bearer Authentication is non-trivial needing a lot of configuration information, and that particular example implies a number of new dependencies e.g. pac4j. There's also the problem of use cases, that particular example is for Apache Zeppelin which is a web UI used by end users in a browser. So it can do the full OIDC flow where you get redirected off to your OIDC provider, authenticate with them and then get redirected back. That's only practical for UI based use cases. A lot of Fuseki usage is as an API server, often without any UI running. In this use case the immediate user of Fuseki is some HTTP client library which is not necessarily going to understand OIDC flow nor is it necessarily sensible for it to do so. In those use cases you really want users to provide their HTTP library with a token (which they already obtained somehow) and have it pass that to Fuseki with its requests. The goal of what has been put into Fuseki core was to provide an extension point whereby people can add Bearer token verification if they so desire. While I appreciate the desire to have a non-code way to do this I don't think there's an obvious solution that covers both use cases (UI and API) in a practical fashion that isn't horribly complex for the end user regardless. And for context at my $dayjob we're deploying Fuseki in AWS with Cognito as the authentication provider. This uses JWT Bearer tokens for authentication **but** this being AWS it passes them around in completely non-standard HTTP headers, and makes the public keys for verification available in a non-standard way. So we have custom code for token verification plugged in via Fuseki modules. Ultimately Bearer Authentication, and OIDC in particular, are non-trivial to configure, while Jena has security features, it isn't itself, and shouldn't be a security framework. Even if we added support for configuring the simplest possible setup it wouldn't cover most real-world setups and once you support something feature creep likely sets in. Sometimes things like this are left as extension points for a good reason -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
