feat(server): anonymous read access to /w3c/ and /oa/ when auth enabled

[hairmare]

This is a feature request. I would like to be able to use eludicate as a backend for some public frontends while still keeping auth.enabled=true.

How to reproduce
Deploy server, enable and configure auth.

Expected results

1. Managing the users/groups, creating/updating annotations + collections is only possible for logged in users ✅
2. There is a way to allow public (GET) access to annotations and collections and the respective search interfaces 🔴

Actual results
The only way to allow anonymous access I can think of are middleware based approaches that always involve authenticaded access to the server when auth.enabled=true.

Additional Info
The code in this branch is an example attempt at implementing this by allowing anonymous access on GET requests for all /w3c/* and /oa/* routes. Non ephemeral methods (the user/group admin parts and creating/mutation annotations) still need proper auth when auth.enabled=true.

The new feature can configured using the auth.anonReadAccess boolean property.

Adding a middleware adds complexity when starting off with w3c annotations. My primary motivation for using elucidate over other servers is that what is needed to run it is simple and doesn't required multiple nosql stores, queues and, indexing services. This feature makes it easier to get up and running in cases like mine where I am greenfielding a linked data experiment and can live without having full fledged policy/rbac/whatever control over access to annotations.

I'm not a Java nor a Sprint developer so please be very critical of the actual contents of this PR. This only covers one way to acheive this that will work for my current use case, I'm open to a discussion about possible alternative ways to achieve the laid out requirements, so I wont be mad if we don't merge it as is 😉

To get this running on my dev box I also did some work on getting elucidate running with java 11... Let me know if you would be interested in a PR containing that. I'm hesitant to propose it as a PR since it's not at a stage where it won't break java 8. fwiw updating to java 11 would pave the way to an updated oauth client that supports jwks, This would have saved me quite some time during my auth config.

[garyttierney]

Hi @hairmare, thanks for the contributions!

This is a feature request. I would like to be able to use eludicate as a backend for some public frontends while still keeping auth.enabled=

A reasonable feature request! My only consideration here is whether we'd also want to support anonymous users at the ACL/annotation container level. That way you could default to anonymous access for most of your containers and have full RBAC on the rest of your data.

I'm doing a bit of work on Elucidate for a couple of days now, so I'll get this looked at before the end of the week. Part of that is upgrading to Java 11 and bumping all of our dependencies, so if you already have something on that front I'm happy to work off what you already have.

[hairmare]

I'm doing a bit of work on Elucidate for a couple of days now, so I'll get this looked at before the end of the week. Part of that is upgrading to Java 11 and bumping all of our dependencies, so if you already have something on that front I'm happy to work off what you already have.

My java 11 work is in #107

[garyttierney]

Hm, the effect of this is that anonymous users are authorized for every action over an annotation. Is this what you're after? I think it's missing an operation == Permission.READ check.

[hairmare]

I was under the impression that the READ part already is taken care of because of the antMatcher only covering GET methods (only the permitAll() path creates a AnonymousAuthenticationToken):

elucidate-server/elucidate-server/src/main/java/com/digirati/elucidate/infrastructure/config/AuthConfig.java

Lines 135 to 141 in 041ab5e

	.authorizeRequests()
	.antMatchers(HttpMethod.GET, "/w3c/**", "/oa/**")
	.permitAll()
	.and()
	.authorizeRequests()
	.anyRequest()
	.authenticated();

I'll take a closer look into doing more checking on the operation in JwtUserSecurityDetailsContext which would be more robust anyway.

[garyttierney]

Ah, you're right. This is fine as is then. I don't think the test for the anonymous token would be any clearer without representing an anonymous user as a complete UserDetails instance.

I'm happy to merge this as is.

[hairmare]

I pushed a container image based on this and #107 so I can move elucidate closer to production in my environment:

ghcr.io/hairmare/elucidate-server:1.5.2-SNAPSHOT

I'm using it with the following docker-compose.yml:

version: '3'

services:
  api:
    image: ghcr.io/hairmare/elucidate-server:1.5.2-SNAPSHOT
    environment:
      LOG4J_CONFIG_LOCATION: "classpath:logging/log4j2.console.xml"
      BASE_SCHEME: "https"
      BASE_HOST: "annnotations.api.example.org"
      BASE_PORT: "443"
      BASE_PATH: "/v1"
      DATABASE_URL: "jdbc:postgresql://postgresql.int.example.org:5432/elucidate"
      DATABASE_USER: "elucidate"
      DATABASE_PASSWORD: "secure"
      AUTH_ENABLED: "true"
      AUTH_VERIFIER_TYPE: pubkey
      AUTH_VERIFIER_KEY: |
        -----BEGIN PUBLIC KEY-----
        MIIB...IDAQAB
        -----END PUBLIC KEY-----
    ports:
      - 8080:8080
    volumes:
      - ./:/usr/local/src/docker
    command: /usr/local/src/docker/entrypoint.sh
    restart: always

The file entrypoint.sh looks like this:

#!/bin/bash

AUTH_OPTS=" -Dauth.enabled=$AUTH_ENABLED -Dauth.token.verifierKey='$AUTH_VERIFIER_KEY' -Dauth.token.verifierType=$AUTH_VERIFIER_TYPE -Dauth.anonReadAccess=true "

export CATALINA_OPTS=" -Dlog4j.config.location=$LOG4J_CONFIG_LOCATION -Ddb.url=$DATABASE_URL -Ddb.user=$DATABASE_USER -Ddb.password=$DATABASE_PASSWORD -Dbase.path=$BASE_PATH $AUTH_OPTS "

exec /usr/local/tomcat/bin/catalina.sh run $@

[hairmare]

@garyttierney