giseldo/neodataset huggingface dataset:
Enable testing the grant access flow for the Review Apps

**As a** developer
<br>**I want** the be able to manually test the access grant flow
<br>**so** that we deliver a flawless product

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Creating an access request can be tested manually
1. Accepting an access request can be tested manually
1. Revoking an access grant can be tested manually
1. Out of scope: automate test flow using E2E-tests

**Notes**

1. Add NLX Management for the organization Haarlem
1. Keep config for BRP 'as is' to make sure the Parkeervergunning app still works
1. NLX Management for Haarlem should be accessible from the Review Overview page

**:link: Reference links**

1.

Story points: 3.0
Revoke access grant

**As a** nlx management user
<br>**I want** to able to revoke granted access
<br>**so** that organizations no longer have access to my services

revoke:<br>
![toegangsbewijs](/uploads/d6b5a8b7e520f627a2992dca3fec20d7/toegangsbewijs.png)

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

> Above design is shown in sub drawer, which is similar to access request.  

1. Revoking an access grant optimistically updates the UI state
1. On error while saving, show toaster with error. Reset UI to initial state.
1. Show confirmation dialog before revoking access
1. Organization no longer has access
1. State should automatically update in UI of requesting organisation (without refresh)

Story points: 3.0
View organizations with access

**As a** nlx management user
<br>**I want** view organizations with access grants to my service
<br>**so** I known which organizations have access

![Incoming_access_requests_-_no_deny_yet](/uploads/2cce29c142f852198148cf2e73a5e6b6/Incoming_access_requests_-_no_deny_yet.png)

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Access grants are displayed in the service detail view
1. Displaying difference between public keys of a organization is out of scope


**:link: Reference links**

1.

Story points: 3.0
Add audit logging to NLX Management

**As a** compliancy officer
<br>**I want** to see all user-initiated actions in the audit trail
<br>**so** that I can make informed statements about compliancy and

**As a** system admin
<br>**I want** to see all user-initiated actions in the audit trail
<br>**so** that I see what actions led to the current situation

Add the following events to the audit trail:
- User logs in/out
- Login attempts
- New service CRUD
- Incoming/Outgoing access requests - all actions
- Access grants created/revoked
- Access proof created/revoked
- Settings page - all changes

**:white\_check\_mark: Acceptance criteria**  

1. All actions which can be done in NLX management should be logged
1. Every action that is logged should contain structured data:
   - the action (type)
   - date/time
   - organization
   - device used (~~ip-address~~[**](#ip-address)/browser/terminal/client)
   - user
   - a field for meta data
1. If logging fails no actions should be executed. After the action there is no second log to confirm the action has succeeded
1. Audit trail is visible on new 'audit log' page in NLX Management (only list items, without filters/pagination)


> This should be all the icons. Could one of you check if it is complete? -Peter

![image](/uploads/0b88d1d17dd97d1125adaa3c70a344b8/image.png)

![_todo__Audit_log](/uploads/5ba48479c1285ccd0be9637255806d27/_todo__Audit_log.png)

**Out of scope**

- NLX Management role granted/revoked to new user
- Relevant part of audit trail on each specific detail page
- Audit logs are 'immutable' (e.g. if a row is deleted, this breaks a hash chain) For now I think we should keep this in mind but not implement it yet, as it comes with requirement for UX/Design. But we  should 

**:desktop_computer: How to demonstrate / e2e test(s):**

1. When one of the actions (described above) is performed, add to audit log
1. go to audit log page
1. see my actions


--- 

> **<a name="ip-address"></a> ip-address CAN be seen as too privacy-sensitive. So we are not including it for now
> 
> ![image](/uploads/87fb7be614ca4ff3e7d3c8c6563f8354/image.png)

Story points: 5.0
Show state of access request  in requesting organisation

Progress:

- [x] Polling mechanism (api to api) !1921
- [x] Expose ~~`lastestAccessGrant`~~ `latestAccessProof` !1935
- [x] Show latest access request states !1931
- [x] Show latest access grant states !1961

---

**As a** user that requests access
<br>**I want** to see the status of my request
<br>**so** that I know if I have access yet

After requesting access:
- keep polling of state of access request changes
- once request accepted, fetch the grant

After grant is fetched and stored:
- change status in UI to 'ACCEPTED'  
   Note: the UI does NOT do polling. See accepted state by closing and opening the drawer.

When access revoked (unknown yet for requesting org):
- keep polling for state change
- revoke local access grant
- change UI to 'Toegang ingetrokken'  (detail drawer and on service row in directory)


**implementation**

Access grant:
1. api will poll every 5 seconds to inway of org B to retrieve access request status
1. API will poll for access grant once status changes to 'approved'
1. When refreshing the UI, 'Je hebt toegang' will be visible once grant is available in requesting organisation 

Revoke: 
1. Access request state has to be in sync on both sides, this requires a poll mechanism that polls until resolved
1. After access granted, this grant needs to be exchanged and stored on requesting side


**:white\_check\_mark: Acceptance criteria**

1. For all below, UI = service row on directory page and service detail pane
1. When access request is clicked and 'ack' is received, UI shows 'Toegang gevraagd' 
1. When grant is received, 'Je hebt toegang' is shown. 
1. When access is revoked, UI in requesting org shows 'Toegang ingetrokken' 
1. After access to a service is revoked, a new request for access to that same service can be made


Out of scope: showing what happens when 'rejected'  
Out of scope: polling in the UI  

**:link: Reference links**

1.![Toegang_ingetrokken](/uploads/f0f66a2ab2d9a5666ede814f01a18adf/Toegang_ingetrokken.png)

![Toegang_ingetrokken_directory](/uploads/049c2380f0386eaad36534b91cafb736/Toegang_ingetrokken_directory.png)

![Screenshot_2020-09-24_at_12.51.07](/uploads/f464c71c333ad576cadafdef203f00f7/Screenshot_2020-09-24_at_12.51.07.png)

![image](/uploads/d4f6ef3b78729da4142108189cc7d1bb/image.png)

Story points: 8.0
Deprecation of treating TLS CommonName as host name


The certificates that we produce with our unsafe CA, based on the instructions [here](https://docs.nlx.io/try-nlx/retrieve-a-demo-certificate), are not compatible with the deployment on demo enviroment. This results in all services that use those certificates being offline. 

A temporary fix was applied, by temporarily re-enabling the old behavior by adding the value x509ignoreCN=0 to the GODEBUG environment variable and deploying the relevant demo environment components.

A permanent fix is required.

Urgent:  

- [x] We will automatically add the common name to the subject alternative name in the CA cert portal
- [ ] We will create new demo pki*
- [ ] We will include the intermediate cert in the request cert response
- [ ] We will inform the demo users about the breaking change
- [ ] We will document that a certificate must be newer than and why AND something about the intermediate certificate

Next steps:
- [ ] If possible/feasable, add a test that catches this error when deploying


*We will create a new pki because we do not sign demo the same way as prod and will change demo so it resembles prod


*Expected behaviour*

* Online services are shown online in directory of demo environment

*Actual behaviour*

* Online services are shown offline in directory of demo environment

**:clipboard: Steps to reproduce**

Note: due to temporary fix no longer visible in demo environment. Reproducing is not recommended.

1. Deploy an environment which trusts our Unsafe CA root, without the x509ignoreCN=0 env variable
1. Use certs generated according to the instructions on https://docs.nlx.io/try-nlx/retrieve-a-demo-certificate
1. See all services fail in directory


**:beetle: Cause**

* In Go 1.15 implementation of X5.09 certs, treatment of CommonName field as hostname is deprecated
https://golang.org/doc/go1.15#commonname
* The certificates that we instruct new users of NLX to generate, do no longer work correctly with our release that uses Go 1.15


**:mag: Details**

Example logs due to this bug:

`{"level":"INFO","time":"2020-09-21T15:37:31.326Z","caller":"inway/inway.go:250","message":"directory registration successful","version":"v0.87.1","inway-organization-name":"utrecht"}
2020-09-21 15:37:36.057073 I | http: TLS handshake error from 192.168.73.0:45365: remote error: tls: bad certificate
2020-09-21 15:37:36.075355 I | http: TLS handshake error from 192.168.73.0:4044: remote error: tls: bad certificate
2020-09-21 15:37:36.075481 I | http: TLS handshake error from 192.168.73.0:63007: remote error: tls: bad certificate
2020-09-21 15:37:36.082503 I | http: TLS handshake error from 192.168.73.0:11627: remote error: tls: bad certificate
2020-09-21 15:37:36.082776 I | http: TLS handshake error from 192.168.73.0:45641: remote error: tls: bad certificate
2020-09-21 15:37:36.090492 I | http: TLS handshake error from 192.168.73.0:55237: remote error: tls: bad certificate
2020-09-21 15:37:36.090559 I | http: TLS handshake error from 192.168.73.0:24471: remote error: tls: bad certificate`

---

Story points: 5.0
Remove Whitelist / Open access radio buttons from UI

**As a** beheerder
<br>**I want** to use the whitelist only when not using NLX management
<br>**so** both type of users can still restrict access to their services and NO whitelist option in NLX management


**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. all code which is used to store / add / etc entries to the whitelist must be removed

**:link: Reference links**

1.

Story points: 2.0
Show number of access requests on services overview

**As a** provider of services
<br>**I want** to see which of my services have open access requests (and how many)
<br>**so** that I know where my action is required

**:white\_check\_mark: Acceptance criteria**

1. Counter is shown on services overview on each row with open access requests
1. Visual Design is implemented

**Implementation**

1. BE: Add number of incoming access requests to service object (in list view)
1. FE: make sure the "counter" updates when fetching service detail

**:link: Reference links**

1.![Screen_Shot_2020-09-16_at_15.26.05](/uploads/54345e6e5114f4f53c3a76c367840d1b/Screen_Shot_2020-09-16_at_15.26.05.png)

Story points: 3.0
Add installation guide for NLX management to docs for testing purposes

**As a** system operator
<br>**I want** to known how to install NLX management
<br>**so** that I can play around with it

This is part of #1024.
Before starting with this, discuss with @ehotting and Ingebrid if our proposed solution is ok.

**:desktop_computer: How to demonstrate / e2e test(s):**

1. Go to docs.nlx.io
1. Follow steps in the NLX Management installation guide available on docs.nlx.io
1. End up with a working NLX Management setup

**:white\_check\_mark: Acceptance criteria**

1. Next to 'Try NLX', add the section 'Try NLX Management'
1. Add warning to the 'Try NLX' section that we're working on 'Try NLX Management' and the `config.toml` configuration will be deprecated in the future
1. Add warning to the 'Try NLX Management' section that this is a WIP.

**Notes**

1. Installation guide is aimed at a system running Docker
1. Installation steps available for:
- ETCD
- Dex
- Management API
- Management UI

1. Use Docker compose to setup local setup
1. Use environment variable to configure OIDC `.well-known-config-path`

**:link: Reference links**

1. Previous effort: https://nl-x.slack.com/archives/CU78R12LQ/p1601468678172700

Story points: 8.0
Reject access request

Implement the view for approving and rejecting access requests, and revoking when already accepted

Choice:  
![Group_17_Copy_3](/uploads/f7d430f7f8256bcb8bbf6279b5dcee95/Group_17_Copy_3.png)

> Note: also see state flow model in [Epic](https://gitlab.com/groups/commonground/nlx/-/epics/12).

> Note 2: this component can be accessed from [service detail](#1004) or [dashboard](#998).

**:white\_check\_mark: Acceptance criteria**

1. Add endpoint to reject access
1. Rejecting an access request optimistically updates the UI state
1. On error while saving, show toaster with error. Reset UI to initial state.

TODO: @petervermeulen can you think of another icon to reject? The cross looks like deleting or throwing something away.

**:link: Reference links**

1.

Story points: 2.0
Accept incoming access requests and authorize requests based on access requests

**As a** provider of a service
<br>**I want** accept access requests 
<br>**so** that the other organization can use my service

![Incoming_access_requests_-_no_deny_yet](/uploads/2cce29c142f852198148cf2e73a5e6b6/Incoming_access_requests_-_no_deny_yet.png)

**:white\_check\_mark: Acceptance criteria**

1. My service detail pane should list open access requests
1. The accept request should display the requesting organization name
1. I can accept the access request by clicking accept and confirm through a dialog box
1. The result of the action is displayed in a toaster
1. After accepting the request should disapear from the service detail pane
1. After accepting the requesting organization has access
1. "Organizaties met toegang" is out of scope

**:link: Reference links**

1.

Story points: 13.0
FE: Access requests visible on dashboard

**As a** [beheerder]
<br>**I want** to see an overview of access requests on the dashboard
<br>**so** I can always see the requests regardless of the existence of the service 

:warning: We don't have endpoints to collect all outgoing/incoming access requests. Only by servicename. So this story is not purely FE.

**:desktop_computer: How to demonstrate / e2e test(s):**

1. login to nlx management
1. dashboard is shown with a section displaying access requests
1. I can view incoming or outgoing access requests
1. I can click "view more" if there are more access requests, these will open in a drawer
1. click on a request, it will show details in a drawer
   - this drawer will overlap the list view if it was open
1. I see a placeholder for the access request detail view

**:white\_check\_mark: Acceptance criteria**

1. Work with mock data on the frontend
1. view (max 5) access requests grouped by service
1. I can open the list view in drawer to see more/all access requests
1. able to open the request; To see details in drawer
   - if clicking on a request in the section: directly show details
   - if clicking on a request in the "list drawer": show "drawer-in-drawer"
1. the detail pages show placeholders


**:link: Reference links**

1.
![_todo__Overview_-_Toegangsverzoeken](/uploads/2ca946bfa2a852dc85274d1e8c66ad2b/_todo__Overview_-_Toegangsverzoeken.png)

![_todo__Overview](/uploads/77ebf9d532d2b5e4be20a93fad4b18f1/_todo__Overview.png)

Story points: 5.0
Remove IE11 support

**As** many stakeholders
<br>**I want** to drop IE11 support
<br>**so** I can spend more resources to actually implementing features

**:desktop_computer: How to demonstrate / e2e test(s):**

1. Visit the app with IE11 and see a redirect to a page explaining it doesn't support IE11  
   (Not sure if we can automate this single test as an e2e-test)

**:white\_check\_mark: Acceptance criteria**

1. A good feature to test for (check if browser supports it) is [Proxy](https://caniuse.com/#feat=proxy)  
   If the browser does not support it, we should redirect to a page explaining we don't support outdated browsers
   (Note: Proxy is also a feature used by [mobx v5](https://mobx.js.org/README.html#browser-support))
1. Revisit the currently used polyfills, remove any that don't apply anymore to save bundle size
1. Whatever page the user opens (via bookmark of just the login page), the redirect should work.
1. List supported browsers. 

**layout proposal**
https://www.sketch.com/s/89b1e1ac-ec61-482a-bc78-8d1b811bf210/a/R0Wn8j<br><br>
![ie11](/uploads/11f563c2121770d3778528dad000af18/ie11.png)

**Tech sollution**

> Agreed upon by Niels & Jorn

- Create the above design in `public/index.html`, which is the base template for the app
   - Inside the `<div id="root">`
- This way if there is an error you will see the "browser support" page
- To prevent this page flashing before the app loads, we can use CSS Transitions to only show the page after X seconds
   - On slow connections you may still see the browser support page before the app loads
- If there is NO error, react will simply overwrite the `#root` div and you won't see the page

This is a nice universal approach we can also use in our other projects

Story points: 2.0
Access Request reaches the other organization

**As a** user of a service
<br>**I want** to send acces requests to the organization that provides the service
<br>**so** that the other organization knows that I want access

**Tasks**
- [x] Create an AccessRequest when the user clicks "Request access"
- [x] Send a created AccessRequest from org A -> org B
- [x] Being able to set the primary inway for management requests
- [x] Implement a management-api proxy on the inway for org B
- [x] Set organization inway address in postgres after selecting the default ingress
- [x] Receive and store AccessRequest from org A in org B
- [x] Implement proper unique constraint on out/in-coming access requests

**Steps**
- access request can have state=created
- ar sending succeeds
  - communication between organizations runs through a proxy on the Inway of the receiving organizations
  - ar state changes to received
  - ar received is known in the management api 


**:desktop_computer: How to demonstrate / e2e test(s):**

1. 

**:white\_check\_mark: Acceptance criteria**

1. The public key finger print should be stored with the access request on both sides
1. There can only be one access request open per service/public key finger print
1. An access request can be send and received with a response about the state

**:link: Reference links**

1.

![image](/uploads/8cf41e71ca8687c8b07986a15c485e10/image.png)

list: https://www.sketch.com/s/89b1e1ac-ec61-482a-bc78-8d1b811bf210/a/zPE5ka  
detail: https://www.sketch.com/s/89b1e1ac-ec61-482a-bc78-8d1b811bf210/a/Jlbwz9

Story points: 13.0
One service can only be exposed by one Inway

**As a** NLX beheerder
<br>**I want** have a one on one relation between service and inway
<br>**so** the service is only exposed by one inway

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

**BE**

1. NLX mgt UI - can only choose one inway. No choice will show the current not available message
1. mgt API - model must be changed so it a service can only contain one inway
1. Directory - model must be changed to one service on one inway relationship
1. Directory - must reject the registration when a inway tries to register the same service with a different self address

Dirctory: There will be a breaking change  
- We prefer to do this immediately
- Another option is to make a backward-compatible version in between

This depends on a chat with users of "prod" & "pre-prod"

Same goes for inways

**FE**

NLX Management:  
This currently expects an array for connected inways in services  
This should change to a single entry

![Screenshot_2020-07-16_at_14.17.34](/uploads/4f4b9b0809005b02246e8b190c9333e3/Screenshot_2020-07-16_at_14.17.34.png)

Directory UI:  
Also work with a single entry instead of array for displaying status

![Screenshot_2020-07-16_at_14.17.13](/uploads/1d2add359fbd7113beaaf091a03e3f9c/Screenshot_2020-07-16_at_14.17.13.png)


**UI changes**<br>
[https://www.sketch.com/s/89b1e1ac-ec61-482a-bc78-8d1b811bf210/v/eaaEyz/a/Jlbwz9/r/RMomoj](https://www.sketch.com/s/89b1e1ac-ec61-482a-bc78-8d1b811bf210/v/eaaEyz/a/Jlbwz9/r/RMomoj)

**:link: Reference links**

1.

Story points: 5.0
Semantic release for Helm charts

The Helm chart have two versions: the version of the chart and the version of the application. The application version reflects the version of NLX.

- When we release a new version of NLX the application version should be updated.
- When the application version changes, the chart version should increase.

Right now it is a manual step to change the version numbers of the charts. A of writing we didn't release a new version of NLX and the charts didn't need a version change.

We can solve this in two ways:

- Give the Helm charts their own version numbering<br>
  `Chart        0.1.0  -> 0.2.0  -> 0.3.0`<br>
  `Application  0.86.0 -> 0.87.0 -> 0.87.1`
  
- Use the NLX version also for the chart<br>
  `Chart        0.86.0 -> 0.87.0 -> 0.87.1`<br>
  `Application  0.86.0 -> 0.87.0 -> 0.87.1`


Either way the semantic release tool needs to change the version number.

Story points: 2.0
Directory in NLX management shows all services including your own

**As a** beheerder  
<br>**I want** to see all services in the directory in NLX management
<br>**so** I have a complete overview there and do not have to go to the public website

Possible iterations:  
1. one list containing all
1. one list with filtering or  
  two lists, one for all others and one for mine
1. later maybe also one list for all services I'm connected to via my outway?

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. 

**:link: Reference links**

1.


Story points: 2.0
Implement toaster in NLX

Implement our freshly made toaster component in our projects, on the following locations:

## Todo

1. After creating a new service, you'll be redirected to that newly created service (the drawer), with a toaster.
1. After editing a service, you'll be redirected to that service, with a toaster.
1. After removing a service, you'll see the service overview page and a toaster (currently a localised Alert).
1. Reuse the same message/content from the message.

Story points: 2.0