[Authentication] Ability to configure fuseki authentication through the config file

[bioinfornatics]

Version

latest

Feature

Dear, Currently Apache Jena throug its API support the bearer authentication, but for non java developer user is often a no go. It is possible to add some buisness logic into fuseki to do the job (maybe in other executable too) in order to configure it through the config file

As example below a tool which allow such feature for inspiration:

• https://github.com/matrix-org/synapse/blob/4eb2f4e02b83c90519a8a55c562d1fafab7caf0b/docs/openid.md Personally I am interested for the Keycloak support

such config file would allow enoug flexibility for end user and enough information for Jena services to works as expected without the need to develop a Java application.

Thanks

Are you interested in contributing a solution yourself?

None

[afs]

Is there a way that Fuseki can have authentication support without needing a specific integration with each option? Via Apache Shiro perhaps?

[SimonBin]

maybe something like this: https://archive.ph/9yXqV

(haven't tried)

[rvesse]

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