Provide Trusted Contributors with the ability to import data in opencre.org

[northdpole]

Status: Blocked — Auth Work v2

This issue is not ready for implementation. Maintainer direction is to sequence trusted-contributor import capabilities after the auth foundation and role model land. Do not assign or start implementation work against this issue until the dependencies below are complete.

Dependency chain (in order)

1. Auth foundation (v1) — Stable, persistent user identity and OAuth session contract per the User Authentication and MyOpenCRE RFC (merged in RFC: User Authentication and Online MyOpenCRE Mapping #876). Track implementation via:

   • #963 — migrate OAuth routes to /rest/v1/auth/*
   • #943 — frontend useUser hook and header auth UX
   • #949 — GET /api/capabilities feature-flag contract
   • #966 — auth-wrap MyOpenCRE CSV import (deprecate anonymous import)

2. Roles (Auth v2) — Extend auth with a role model that introduces the concept of a trusted contributor (distinct from anonymous users and from full maintainers). Role assignment, enforcement, and admin UX are part of this step; no issue number yet — design alongside auth v1 completion.

3. Trusted-contributor capabilities (this issue) — Once (1) and (2) are done, grant trusted contributors access to:

   • MyOpenCRE import — authenticated mass-import UI/API (today restricted to code maintainers running import scripts)
   • GSoC ingestion pipeline — the autonomous LLM-assisted cheat-sheet → CRE mapping workflow per the Cheatsheets LLM Autonomous Mapping RFC and the broader OWASP living knowledge base design (docs/owasp-graph/)

Blocked until: auth v1 (#963 and related) and the roles/trusted-contributor model are implemented and deployed.

---

Background

What is the issue?

Currently, new data in opencre.org can be inputted by way of a code-maintainer running an import script. This is inefficient as it greatly restricts who can import data and forces a hard coupling between code maintainers and data authors.

Expected behaviour

Data authors who are trusted contributors should have a strongly authenticated UI which allows them to easily mass-import data into opencre.org. They should also be given the freedom to either manipulate or replace individual mappings. However, special care should be taken to preserve CRE immutability.

Possible implementations (deferred — revisit after Auth v2)

Admin panel connected to an IdP

There is an admin page which uses OpenID Connect and an external identity provider (e.g. Okta) to authenticate a data author. Data authors could provide an email address which, when added to an identity provider solution, gives them access to said admin panel. From there they can provide the URL of a spreadsheet that fits the mapping template and the backend runs the equivalent of python cre.py --add --from-spreadsheet <url>.

Pros: industry-standard solution; on-prem users can hook their own IdP.

Cons: needs an external IdP solution; maintenance burden.

Note: With Auth v1 using Google OAuth and a future trusted-contributor role model, the IdP approach above may be superseded or narrowed. Re-evaluate implementation options once dependencies (1)–(2) are complete.

Related

• Parent/epic: #586 — user accounts and MyOpenCRE online
• Auth RFC: docs/rfc/user-auth-myopencre.md
• GSoC / ingestion RFC: docs/rfc/cheatsheets-llm-autonomous-mapping-rfc.md

[shreeshtripurwarcomp23-coder]

@northdpole
Hi!

This is a great enhancement to improve the data ingestion workflow. I would like to work on this issue.

I'm planning to look into the Admin panel connected to an IDP approach, ensuring we use industry-standard OIDC for authentication while keeping a close eye on preserving CRE immutability during mass imports and individual mapping updates.

Could you please assign this to me? I'll follow up with a draft PR or questions if I run into any roadblocks.

[northdpole]

@shreeshtripurwarcomp23-coder Thanks for your interest in improving the data ingestion workflow — much appreciated!

This issue has been reframed as Auth Work v2 and is not assignable yet. Implementation is sequenced after the auth foundation lands first (see #963 and the User Authentication and MyOpenCRE RFC), then a roles/trusted-contributor model, and only then the import capabilities described here.

Please see the updated issue body for the full dependency chain. Happy to revisit assignment once auth v1 + roles are in place.