giseldo/neodataset huggingface dataset:
Set inway default authorization model to whitelist

**As an** user
<br>**I want** my inway to use the whitelist authorization model by default
<br>**so that** I don't accidentally publish private APIs to everyone on the NLX network.

**:white\_check\_mark: Acceptance criteria**

1. Inway uses whitelist authorization model by default
1.

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

* [Project Definition of Done](https://gitlab.com/commonground/nlx/nlx/blob/master/CONTRIBUTING.md#4-2-definition-of-done)
*

Story points: 1.0
Add information about support in docs

**As a** user of NLX
<br>**I want to** know how to get support
<br>**so that** I don't feel alone when I have a problem

**:white\_check\_mark: Acceptance criteria**

1. Update existing menu item Support
1. Add contact as subpage of Support
1. Add support@nlx.io e-mail to contact page
1. Add https://community.commonground.nl to contact page
1. Add https://gitlab.com/commonground/nlx/nlx to contact page
1. Move common errors to subpagina of support
1. Add link to Support section as part of the navbar (for the marketing website, directory ui, insight ui, docs)

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

* [Project Definition of Done](https://gitlab.com/commonground/nlx/nlx/blob/master/CONTRIBUTING.md#4-2-definition-of-done)
*

Story points: 2.0
Docs: how to implement whitelist authorization on inways

**As a** user
<br>**I want to** know how to create an authorization whitelist for my inway 
<br>**so that** I can prevent unwanted access to my API's

**:white\_check\_mark: Acceptance criteria**

1. Description of how use the authorization whitelist functionality of the inway in the docs
1. Just the config via .toml, management UI documentation follows later

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

* [Project Definition of Done](https://gitlab.com/commonground/nlx/nlx/blob/master/CONTRIBUTING.md#4-2-definition-of-done)
*

Story points: 2.0
Replace IRMA server

**As a** maintainer
<br>**I want to** move our product to use the new IRMA server
<br>**so that** our demo keeps working

---
Note: related to #750 as the whole relevant code base will be moved there.

**:white\_check\_mark: Acceptance criteria**

1. Use the new IRMA server
1. Purge the old one from our code

---

We got notice from the IRMA team:
```
The irma_api_server is now officially deprecated, and to those still using it this is a last call to move away from the irma_api_server to its successor, the irma server command (see https://irma.app/docs/irma-server/). In particular this means the following:
- The irma_api_server is now no longer able to handle attribute based signatures due to a recent change in how the IRMA app produces these, and this will not be fixed, nor will any other feature or fix be applied to the irma_api_server.
- The privacybydesign/irma_api_server docker image will be deleted one month from now.
```

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

* [Project Definition of Done](https://gitlab.com/commonground/nlx/nlx/blob/master/CONTRIBUTING.md#4-2-definition-of-done)
*


Story points: 2.0
Add explanation about config-api and management UI in the NLX ecosystem to docs

**As an** aspiring NLX administrator
<br>**I want to** know what the config-api and management UI are
<br>**so that** I can use them to my benefit

**:white\_check\_mark: Acceptance criteria**

1. Documentation about what the config-api and management UI are
1. Documentation about how to install

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

* [Project Definition of Done](https://gitlab.com/commonground/nlx/nlx/blob/master/CONTRIBUTING.md#4-2-definition-of-done)

**Acceptance by:** Eelco

Story points: 3.0
Add explanation about IRMA / insight-api in the NLX ecosystem to docs

**As an** aspiring NLX administrator
<br>**I want to** know what IRMA and the insight-api are
<br>**so that** I can use them to my benefit

**:white\_check\_mark: Acceptance criteria**

1. Information about the role of IRMA and the insight-api in the NLX ecosystem

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

* [Project Definition of Done](https://gitlab.com/commonground/nlx/nlx/blob/master/CONTRIBUTING.md#4-2-definition-of-done)
* 

**Acceptance by:** Eelco

Story points: 3.0
Add basic-auth to management ui in Traefik

**As a** developer/ops
<br>**I want to** restrict access to the management ui's of our voorbeeld organizations
<br>**so that** hackers have no joy

**:white\_check\_mark: Acceptance criteria**

1. Add basic auth to traefik Ingress
1. Sub-domain  management.* requires authentication

**:hammer\_and\_wrench: Proposed technical solution**

Traefik ingress annotations:
```
    ingress.kubernetes.io/auth-type: basic
    ingress.kubernetes.io/auth-secret: "basic-auth"
```

Secret:
```
apiVersion: v1
kind: Secret
metadata:
  name: basic-auth
  namespace: <namespace where the ingress lives>
type: Opaque
data:
  auth: #base64 encoded user:password as htpasswd
```

**:link: Reference links**

* [Project Definition of Done](https://gitlab.com/commonground/nlx/nlx/blob/master/CONTRIBUTING.md#4-2-definition-of-done)

**Acceptance by:** Geert

Story points: 2.0
Configure insight/irma in the management UI

**As a** user
<br>**I want to** configure insight/irma for my organization
<br>**so that** users can view log records that contain attributes they own.

**:white\_check\_mark: Acceptance criteria**

1. insight-api address is configurable in the management UI, values are saved to the config-api/etcd.
1. IRMA server address is configurable in the management UI, values are saved to the config-api/etcd.
1. Create new API call on directory-registration-api, to modify organization-level values such as irma-api, insight-api
1. Let config-api use new directory-registration-api method to update organization-level values.

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

* [Project Definition of Done](https://gitlab.com/commonground/nlx/nlx/blob/master/CONTRIBUTING.md#4-2-definition-of-done)
*

Story points: 5.0
Further reading subsection is empty

Further reading menu items shopws not the expected list of pages

*Expected behaviour*

* https://docs.nlx.io/further-reading/ should show a list of all child items

*Actual behaviour*

* Shows just 1 item

--- 

Depends on move to Gatsby, suggestion to do this first

**:clipboard: Steps to reproduce**

1. Go to https://docs.nlx.io/further-reading/ 

**:beetle: Cause**

* (if cause is known, details here)
* (if you can pinpoint a piece of code, link to line number)


**:mag: Details**

(Paste any relevant logs - please use code blocks to format console output, logs, and code)

(Add screenshots using `Attach a file`)

---

Story points: 1.0
Move "Compliancy with EU regulations" page to compliancy section

**As a** PO
<br>**I want to** see the Compliancy with EU regulations page moved
<br>**so that** it doesn't distract from the clear documentation

---

**:white\_check\_mark: Acceptance criteria**

1. Move page to a new "Compliancy" section
1. Format .md to make the layout better readable   (@spreeker made this already)

Current docs: https://docs.nlx.io/introduction/compliancy/

Story points: 1.0
Configure PKI-O EV certificates on www.nlx.io

**As a** end-user
<br>**I want to** have EV certificates on www.nlx.io
<br>**so that** it looks more secure

**:white\_check\_mark: Acceptance criteria**

1. EV certificates are configured on www.nlx.io

![image](/uploads/6b15cc56994476ab01a0f0785156f8f4/image.png)

Story points: 1.0
Rework feedback when synchronisation of access request fails

**As a** _user_
<br>**I want** _goal_
<br>**so** _purpose_

The toasters showing an error when synchronizing access requests are currently too intrusive for the user.

**:white\_check\_mark: Acceptance criteria**

1. Do not poll the synchronization endpoint for the service detail pane (overview page only is sufficient)
1. Show a warning icon in the 'Access' column, when an organization is not reachable
1. Remove all toasters as feedback
1. In the service detail pane, display a warning icon and reason why synchonization failed
1. Ensure we only poll once every 3 seconds. Currently the poller starts multiple times when opening / closing the detail pane. Or opening / closing the directory overview page.


Voorstel feedback:

- Interne fout: raadpleeg eigen systeembeheerder
- Geen organisatie Inway bekend bij `<org x>`
- Organisatie Inway van `<org x >` niet bereikbaar
- Interne fout bij `<org x>`

**:link: Reference links**

1.

Story points: 5.0
Include transaction log in the E2E tests

We do not validate the creation of transaction logs in our E2E this has caused a bug like https://gitlab.com/commonground/nlx/nlx/-/issues/1630 to be possible. 

In a perfect world we should test that:

1. The consuming org creates a transaction log record with the direction `out` 
2. The providing org creates a transaction log record with the direction `in`
3. In case of delegation a transaction log record should contain "x on behalf of y"

Story points: 5.0
Remove scheduler

**As a** user
<br>**I want** _goal_
<br>**so** _purpose_


_Chosen solution: NLX management takes over the job of the scheduler_

**:desktop_computer: How to demonstrate / e2e test(s):**

1. Create access request
2. Revoke access request
3. Sync access request state
4. Retrieve access proof
5. Add an order should still work

**:white\_check\_mark: Acceptance criteria**

1. Scheduler for access requests should be removed
1. Management UI, directory overview: should display checkmark if at least one Outway has access to the service (poll every 5 seconds)
1. Management UI, directory service detail: should display access status per Outway  (poll every 5 seconds)
1. Update documentation in `technical-docs/sequence-diagrams`

**Technical notes**

- add API endpoint to synchronize the access requests.
- re-fetch service details if the synchronization was successful
- update E2E tests to execute the synchronize API endpoint if a request has been updated
- Move logic for sending an access request from the scheduler to the send call

**:link: Reference links**

1.

Story points: 13.0
Change implementation of NLX error messages

**As a** implementator of the NLX standard
<br>**I want** to know which error messages I should return
<br>**so** that I can implement the standard.

NLX added error codes and error messages to the components see issue https://gitlab.com/commonground/nlx/nlx/-/issues/1557. With the chosen implementation all the possible error codes are contained in a single file which makes it easy for anyone implementing the standard to get a overview of the error codes. 

The actual error message is not part of the standard. The fields with extra information are. 
This allows implementors to define error messages in their own language. But we ensure all relevant fields are provided by the standard.

Example: `permission denied, organization <ORG> or public key fingerprint <PUBLIC_KEY> is not allowed access.`

`<ORG>` and `<PUBLIC_KEY>` are defined in the standard required to be part of the message.

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Move error messages to the same file as the error codes

**:link: Reference links**

1.

Story points: 3.0
OIDC: correctly handle different notations of the audience in the Access Token

Dex stores the audience as a string in the Access Token, Keycloak stores it as an array of strings. Both approaches are valid but the Management API can only handle the audience as a string. We should fix this.

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. 

**:link: Reference links**

1. https://github.com/coreos/go-oidc/blob/2d47dd95152744f41009de5797efe6cc07832a41/oidc/oidc.go#L475

Story points: 2.0
Update "Request a production certificate" section of the docs

The current Openssl command doesn't add a SAN to the CSR. Go has deprecated the CommonName field in the certificate and uses the SAN instead. Without a SAN go cannot validate the certificate. 

New command (openssl 1.1.1 required): 

```
openssl req  -addext "subjectAltName = DNS:mijn.inway.nl" -utf8 -nodes -sha256 -newkey rsa:4096 -keyout org.key -out org.csr
```

Story points: 1.0
Remove Outway in NLX Management

**As a** NLX user
<br>**I want** to remove an Outway in NLX Management
<br>**so** that I can remove the second Outway entry that appears after I change the name of the Outway

This is feedback from Wego4it from the Hackathon.

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**



**Technical proposal**

- add API endpoint to remove Outway
- Add remove button to Management UI
- Make sure only admin is allowed to perform this
- Add E2E test

**:link: Reference links**

1.

Story points: 5.0
Run txlog-api migrations in Helm chart

**As a** NLX user
<br>**I want** that txlog database migrations are done when I update my Kubernetes deployment to the latest version
<br>**so** that I can automate updating my deployment

Currently the txlog database migrations are done by manually running a job in Kuberenetes for which we provide a template( `technical-jobs/txlog-api-job-migrations.yaml`). This makes automating NLX deployment updates not as easy as it could be. 


**:desktop_computer: How to demonstrate / e2e test(s):**

1.

Technical solution:

Use the same approach as the Managment API; Include running the migrations in the txlog-api binary and add it as a init container to the txlog-api deployment chart. 

**:white\_check\_mark: Acceptance criteria**

1. 

**:link: Reference links**

1.

Story points: 3.0
Inject NLX headers for clients who do not include them

Not all clients are able to add the correct NLX http headers to the request to the Outway. although we prefer that the client provides them themselves, a client which can't be changed for whatever reason still needs to be able to work with NLX. Old vs new principle. So in NLX management a sort of general header config per service should be possible which adds the headers to the request. 

The outway must have this general config in memory and apply it when necessary. 

Add documentation page similar to the [url rewrite](https://docs.acc.nlx.io/reference-information/rewrite-base-url) in which we provide a example of a proxy that adds order headers to the request.

Story points: 3.0
Update Bitnami PostgreSQL chart  in NLX Try Me

We currently use version 10.x.x of the bitnami postgres chart in the Try Me guide. Our guide is incompatible with the latest version of the bitnami postgres chart.

Release notes v11: https://docs.bitnami.com/kubernetes/infrastructure/postgresql/administration/upgrade/

Docs: https://docs.nlx.io/try-nlx/helm/postgresql

Check the NLX Haven add-on too.

Once the upgrade is completed, we should upgrade to future versions as part of the maintenance maister job.

Story points: 5.0
Add docs on re-writing OpenAPI spec base URLs

Add Nginx-template + Dockerimage file for the 'madrid-proxy'.
These have been added to the MR for the OGC demo, see https://gitlab.com/commonground/nlx/nlx/-/merge_requests/3680


1. Move relevant files to separate repo
2. Link to the repo in the docs as part of 'Reference information'
3. Done

Story points: 2.0
Add fixed error codes to nlx error messages

We created a clear distinction between NLX errors and API errors. Now add fixed error codes to the error messages and document that fixed list of error codes with a description so that clients can process based on fixed codes in stead of possibly changing descriptions. 

When the Outway/Inway returns a NLX specific error message (status code 540), the body of the response should contain both an error message and an error code. All the possible errors should be in 1 file so we have a clear overview.

Story points: 8.0
RBAC for NLX Management

**As a** NLX user
<br>**I want** a flexible RBAC system
<br>**so** that I am able to setup roles which match my organization structure 

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Actions which are possible with the Management API are translated to permissions
1. Assign permissions to the admin role 
2. API endpoint should check if the endpoint can be used by the authenticated user/role
3. Enable passing credentials to NLX CTL (to pass to the API) (figure out if this should be a JWT or something else)
4. Basic auth should keep working


**Technical notes**

1. Assign a key to every API-endpoint / page in UI. These can then be assigned to roles. Eg. `permissions.service.add`.

**:link: Reference links**

1.

Story points: 21.0
Add OPA to demo setup

**As a** NLX promoter
<br>**I want** to be able to demo the OPA integration
<br>**so** that I can show people how the OPA intergration works

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Add a client secret to the parkeerrechten admin interface
2. If a request fails because of OPA the error message in the UI should reflect that
3. Add links to `auth-opa/inway`and `auth-opa/outway` to the links page

**:link: Reference links**

1.

Story points: 3.0
Als gemeente Stijns wil ik alle inwoners van alle gemeenten kunnen zien

**As a** gemeente Stijns
<br>**I want** alle inwoners van alle gemeenten kunnen zien
<br>**so** we can use this during the hackathon

**:white\_check\_mark: Acceptance criteria**

- [x] replace current [demo basisregister-fictieve-personen API (Flask)](https://gitlab.com/commonground/nlx/demo/-/tree/main/basisregister-fictieve-personen) with a CRUD API (Golang)
- [x] introduce a database (simple scheme, put all data in a single column of type JSON)
- [x] the current API should still work (GET `/natuurlijke_personen`)
- [ ] introduce UI which lists all records from the fictieve-personen-api for the current municipality

---

**Out of scope**

- [ ] return the address of a persoon [in the same format as Haal Centraal](https://vng-realisatie.github.io/Haal-Centraal-BRP-bevragen/swagger-ui#/Ingeschreven%20Personen/GetIngeschrevenPersoon) (search for `verblijfplaats`)

**:link: Notities**

1. UI bij Stijns, API bij RvRD

Story points: 5.0
Make clear separation between NLX errors and API errors

Use the following HTTP status codes for the http endpoint on the NLX outway so that the apis calling the outway know that it's a NLX error instead of a error from the service itself.
  - ~~502~~ 540 Bad Gateway - The server was acting as a gateway or proxy and received an invalid response from the upstream server.
  - ~~504~~ 541 Gateway Timeout - The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
  - 542 Unauthorized - 

~~We also could use the [`Proxy-Status`](https://tools.ietf.org/id/draft-ietf-httpbis-proxy-status-01.html#rfc.section.2) header, but its still a draft~~

Current possible errors:
- 400 Bad Request
- 401 Unauthorized
- 500 Internal Server Error
- 501 Not Implemented
- 503 Service Unavailable

Proposal:
540 - 559 reserved codes for NLX
- 540 Bad Request
- 541 Unauthorized
- 550 Internal Server Error
- 551 Not Implemented
- 553 Service Unavailable

Or just one reserved code:
- 540 NLX Gateway Error

Story points: 5.0
Upgrade React to v18

# TODO

- decouple management ui from shared eslint config
- decouple directory ui from shared eslint config
- decouple design system from shared eslint config
- upgrade design system to react v18
- upgrade management ui to react v18
- upgrade directory ui to react v18

---

[React v18](https://reactjs.org/blog/2022/03/29/react-v18.html) has been released, we should upgrade from v17 to v18.

However, there's a couple of projects tight together, which requires a coordinated effort in order to upgrade.

There's other dependencies that come along with this upgrade. Eg. `@testing-library/user-event`, `jest`, Create React App etc.

Projects that should upgrade first:

- https://gitlab.com/commonground/core/eslint-config
- https://gitlab.com/commonground/core/eslint-config-cra-standard-prettier

Then:

- https://gitlab.com/commonground/core/design-system

Then:

- https://gitlab.com/commonground/nlx/demo (contains multiple UIs)
- https://gitlab.com/commonground/nlx/nlx.io
- https://gitlab.com/commonground/nlx/nlx (contains multiple UIs)

Story points: 8.0
Enable configuring the Management API proxy address separately from the Organization Inway address

**As a** user
<br>**I want** to be able to use a single predictable port (`443` or `8443`) for my Inway and the management traffic going through the Inway
<br>**so** I can use my current setup using Otomi don't have to expose a custom port (port+1) for NLX

Currently, the Management API proxy address is derived from the Organization Inway address (port + 1).

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. When registering an Inway to the Directory, the Management API proxy address must be registered separately from the Organization Inway address
1. The management API proxy address flag should be required
1. The Inway data and management addresses stored in the directory should include portnumbers 
1.  I want to be able to expose both the Inway and the Inway Management API proxy on the same port and use domainnames to differentiate traffic. (eg. the Inway is registered at `https://my-inway.gemeente.nl` and the Management API Proxy is registered at `https://my-inway-proxy.gemeente.nl`)
1. Document extra flag in the commit message in such a way that it is clear to our users how they can use the new flag when upgrading (eg. clearly state the required upgrade path in the commit)
1. Ensure Try me is updated accordingly

**Proposed workflow**

1. Build this
1. Ensure its not a breaking change (keep track of time) (except for orders)
1. Release

Note: the estimation of this issue is without the work for making it non-breaking

**Remaining questions about breaking changes:**

- what if (existing) Inways do not register a management API Proxy address to the directory?


**:link: Reference links**

1.

Story points: 8.0
Implement auth plugin for the Outway

We have implemented the auth plugin in the Outway so that it can communicate with an OPA server. Implement the same plugin for the Inway and make Outway auth plugin production ready.

Include demo of OPA-server for the demo environment for the Parkeervergunningen Admin.

Enable stripping custom headers for requests from the Outway to the Inway. So the headers can be used by OPA but not intercepted by the Inway.

- [ ] add tests
- [ ] change docs
- [ ] include links to OPA-server to the links overview page

The same should happen for the Inway as part of #1502+

Story points: 8.0
Implement E2E-tests: access a service using an outway

**As a** user
<br>**I want** to access a service using an outway
<br>**so** ?

**:desktop_computer: How to demonstrate / e2e test(s):**

```gherkin
Scenario: Access a service using an outway
    Given "Gemeente Stijns" has an outway
        And "Gemeente Stijns" has access to "basis-register-fictieve-kentekens" of "RvRD"
    When the outway of "Gemeente Stijns" calls the service "basis-register-fictieve-kentekens" from "RvRD"
    Then "Gemeente Stijns" receives a successful response
```

**:white\_check\_mark: Acceptance criteria**

1. Implement the scenario as described above

**:link: Reference links**

1.

Story points: 5.0