Rely on per-entity filtering for listing instead of list-level gates

[p-hoffmann]

Why

WebAPI authorizes every request through a security principal (authenticated user or the built-in anonymous principal), deciding access from permission grants + per-entity filtering. #2521 hardened authorization and kept that model. #2521 gated list endpoints behind read/write permissions, when listing should stay open and have its contents filtered per principal (which several lists already did). This PR removes those list gates and relies on filtering, and removes a handful of isAuthenticated() checks that cut against the model. #2521's genuine endpoint protections are kept.

Kept from #2521 (these endpoints were genuinely open before — leave gated)

• Source-scoped CDM data reads (vocabulary, evidence, cdmresults) → read:source / hasSourceAccess
• Person-level data (person profile, cohort-sample) → source + cohort grants
• Feature-extraction → read:feature-analysis
• Admin operations (user/role/permission mgmt + LDAP import, source mgmt, cache, statistics, tag management) → admin:*

The fix: listing is open, contents are filtered

Content is protected one of two ways:

• Filtered (open list, rows trimmed to grants) — the 7 artifact lists + /source/sources. 4 already did this (cohort-definition, concept-set, cohort-characterization, pathway); this PR adds IR, feature-analysis, reusable, and the source list. /byTags list-by-tag queries are opened too.
• Gated with a new list permission (migration V2.99.0005, also in the B3.0.0 baseline), granted to the built-in public role, where there's no per-entity scope to filter — user/role/permission registries, jobs, tools, and the DDL/SqlRender utilities (which read no source data). Authenticated users can list; anonymous → 403.

Secondary cleanups

• Removed the isAuthenticated() gates (getCurrentUser, generation reads, notifications) — generation reads keep their in-body entity+source checks.
• Renamed the anonymous-access toggle security.anonymousAccess.enabled → security.allowAnonymousAccess (default true serves token-less requests as the anonymous principal; false requires a valid JWT for every endpoint outside the bootstrap allow-list).

Other fixes

• Cohort-sample IDOR — require cohort + source access and bind the sample to the cohort/source in the path.

[chrisknoll]

I have concerns about read:platform. I understand what you're doing where you're tyring to restrict listing of permissions, groups, users, i am 1) not sure we need to gate that (what's the implication of not having that restricted?) and 2) calling it a 'platform reading' type of permission is awkward (which is a symptom of why we neglected to gate these types of operations).

The second issue is that the tag management stuff that was under admin:tags got mapped over to read:platform. I don't think that's correct. Admin doesn't necessarily mean you have god level permissions to things: in our environment we would allow users to create their own tags and assign them to things they own. But that may be a restricted operation (as, only certain users shoudl be able to assign and create tags). Therefore, we put admin:tags and operations related to tags requires that permission. I have to check further, but it may be the case that owners can assign tags to their own assets without admin:tag....

[chrisknoll]

This migration should be put as V2.99.0005 so that it will be considred 'transitional migration leading up to the 3.0 version. The version you have specified here makes it look like there is a V3.0.1 of webapi, but there's not.

The idea for making all the migrations leading up the the 3.0 baseline is everything we're cahing from 2.15 to the 3.0 release goes in migration scripts V2.99.xxxx so that it will be present when we do the 3.0 baseline script. So please put this script into V2.99.0005, and add this permission to the 3.0 baseline script.

Future migrations leading up to the 3.0 release should be put into V2.99

[chrisknoll]

IN addition, the other examples of inserting permissoins is like this:

insert into ${ohdsiSchema}.sec_permission(id, value, description)
select nextval('${ohdsiSchema}.sec_permission_sequence'), value, description
FROM (
	VALUES
	('*', 'All Permissions'),
	('admin', 'All Admin Permissions'),
	('admin:source', 'Manage Sources'),

This example above is used to insert a bunch of permissions, but the point is we use nextval() to use the sequence, and also, we shoudl not be using 'where not exists'. If the permission actually exists, we want to throw an error in the migration because it is not expected.

[chrisknoll]

I think that it's not a bad option to disable anonymous access to webapi, so if you want, you can restore this setting, and we can put in the JWT servlet filter chain that if this is not enabled, we reject the request if it doesn't have a valid JWT.

I wonder if this is better under security.xxx configuration options vs putting this at the top-level of the application.yaml.

[chrisknoll]

@p-hoffmann , thank you for updates, I think this is good enough to merge in. We can always revisit the list functions if it needs to be more refined, and I appreciate granting it to the public role by default.

I have work on a api-key branch so when this gets merged in, i will be able to merge my branch and add that function next.

Changes look good