Iteration 5 » Historie » Verze 7
Jan Pašek, 2021-04-22 15:41
| 1 | 1 | Jan Pašek | h1. Iteration 5 |
|---|---|---|---|
| 2 | 2 | Jan Pašek | |
| 3 | |||
| 4 | *Target:* User-provided private key, List filtering and pagination, Robots |
||
| 5 | |||
| 6 | h2. Tasks |
||
| 7 | |||
| 8 | h3. User-provided key |
||
| 9 | |||
| 10 | The application shall provide a possibility to provide his own private key or to let the application generate a key with a user-selected password. |
||
| 11 | |||
| 12 | 3 | Jan Pašek | Req: FR 1.1.2, 1.1.3, 1.1.4, 2.1.2, 2.1.3, 2.1.4 |
| 13 | |||
| 14 | 2 | Jan Pašek | h4. GUI |
| 15 | |||
| 16 | * Web GUI - The certificate creation page shall contain a new checkbox "Generate key pair". |
||
| 17 | * Web GUI - The certificate creation page shall contain a text field to specify a password for the private key. |
||
| 18 | |||
| 19 | h4. Core |
||
| 20 | |||
| 21 | * Rest API shall enable a PEM encoded PK to be specified within the request for creating a certificate. |
||
| 22 | * Rest API shall enable a password to be specified within the request for creating a certificate. |
||
| 23 | |||
| 24 | * If a password is present in the request and the private key is not present, the server generates a key protected by the given passphrase. |
||
| 25 | |||
| 26 | * If a password is not present in the request and the private key is present, the server uses the given key. However, the server must do a check if the private key is |
||
| 27 | 4 | Jan Pašek | not protected by a passphrase -> if yes, an error response is returned. |
| 28 | 2 | Jan Pašek | |
| 29 | * If both password and key are not present, the server generates a key without passphrase protection. |
||
| 30 | |||
| 31 | 1 | Jan Pašek | * If both password and key are present, the server uses the given key and checks whether the given passphrase decyphers the key-> if not an error response is returned. |
| 32 | 4 | Jan Pašek | |
| 33 | 6 | Jan Pašek | --- |
| 34 | |||
| 35 | 4 | Jan Pašek | h3. Validity check |
| 36 | |||
| 37 | The application shall provide an endpoint to verify the validity of the selected certificate. |
||
| 38 | |||
| 39 | 5 | Jan Pašek | Req: FR 1.3 |
| 40 | |||
| 41 | 4 | Jan Pašek | h4. GUI |
| 42 | |||
| 43 | * Web GUI - The certificate details page provides an indication of certificate validity. |
||
| 44 | |||
| 45 | h4. Core |
||
| 46 | |||
| 47 | * Rest API shall provide an endpoint /api/certificate/{id}/status to query certificate status |
||
| 48 | * The application shall distinguish three types of status: _valid_, _expired_, _revoked_ |
||
| 49 | 5 | Jan Pašek | |
| 50 | 6 | Jan Pašek | --- |
| 51 | |||
| 52 | 5 | Jan Pašek | h3. Templating |
| 53 | |||
| 54 | Req: FR 8.1 |
||
| 55 | |||
| 56 | h4. GUI |
||
| 57 | * Web GUI - The certificate creation page shall provide a text area, that enables the user to specify his own extensions that will be added into the certificate. |
||
| 58 | |||
| 59 | * Specified extensions must follow the OpenSSL format |
||
| 60 | |||
| 61 | h4. Core |
||
| 62 | |||
| 63 | * Rest API endpoint for creating a certificate shall accept extensions specification that will be passed to bottom layers and written into the certificate. |
||
| 64 | * If the user specifies wrong extensions (not in compliance with the OpenSSL), the CryptographyService throws a CryptographyException, that must be intercepted by the controller and the server shall not |
||
| 65 | return code 500 in that case. |
||
| 66 | |||
| 67 | 6 | Jan Pašek | --- |
| 68 | |||
| 69 | 5 | Jan Pašek | h3. Robots |
| 70 | |||
| 71 | * The Web GUI shall be tested using automatic tests. |
||
| 72 | * The tests shall utilize the Robots framework with the Selenium backend. |
||
| 73 | * The test cases shall follow the user stories (user stories may require to be updated). |
||
| 74 | * The tests must be integrated into the CI/CD pipeline. |
||
| 75 | 6 | Jan Pašek | |
| 76 | --- |
||
| 77 | |||
| 78 | h3. Filtering |
||
| 79 | |||
| 80 | The application shall enable certificate listing to be filtered and paginated. |
||
| 81 | |||
| 82 | Req: FR 4.2 |
||
| 83 | |||
| 84 | h4. GUI |
||
| 85 | |||
| 86 | * The GUI shall provide checkboxes to select the following types of certificates: (Root CA, Intermediate CA, End Certificate) |
||
| 87 | * The GUI shall provide checkboxes to select the following usages: (SSL/TLS, authentication, digital signature, CA) |
||
| 88 | * _The GUI shall enable the certificate to be searched using a Common name_ - to be discussed |
||
| 89 | * The GUI shall paginate the certificate list results |
||
| 90 | |||
| 91 | h4. Core |
||
| 92 | |||
| 93 | * Rest API (GET /api/certificates) must enable to filter the certificates using certificate type (Root CA, Intermediate CA, End Certificate) |
||
| 94 | * Rest API (GET /api/certificates) must enable to filter the certificates using certificate usage (SSL/TLS, authentication, digital signature, CA) |
||
| 95 | 1 | Jan Pašek | * Rest API (GET /api/certificates) must enable to filter the certificates based on the common name |
| 96 | * Rest API (GET /api/certificates) must enable to paginate the results (page + certificates per page) |
||
| 97 | 7 | Jan Pašek | |
| 98 | --- |
||
| 99 | |||
| 100 | h3. GUI improvement |
||
| 101 | |||
| 102 | The final touch on GUI design - background, place elements into boxes, etc... |