Unable to update the group of a certificate when the owner of the certificate is not empty.

Update the design of bulk delete and force delete operation.

• refactor the delete methods to return force delete message dto instead of direct exception raise
• refactor force delete method to use the delete methods
• Refactor bulk force delete to include list of not deleted objects and send them back to FE

There are hardcoded values in the DiscoveryServiceImpl.java class: https://github.com/3KeyCompany/CZERTAINLY-Core/blob/develop/src/main/java/com/czertainly/core/service/impl/DiscoveryServiceImpl.java

Hardcoded number of maximum certificates per page, and once the constant will change, the log and exception is wrong:

               if (response.getCertificateData().size() > MAXIMUM_CERTIFICATES_PER_PAGE) {
                    response.setStatus(DiscoveryStatus.FAILED);
                    updateDiscovery(modal, response);
                    logger.error("Too many content in response. Maximum processable is 100");
                    throw new InterruptedException(
                            "Too many content in response to process. Maximum processable is 100");
                }

Maximum waiting time for unresponsive discovery process is hardcoded in the message and once the constant is changed, it is not reflected:

                if ((modal.getStartTime().getTime() - new Date().getTime()) / 1000 > MAXIMUM_WAIT_TIME
                        && !isReachedMaxTime && oldCertificateCount == response.getTotalCertificatesDiscovered()) {
                    isReachedMaxTime = true;
                    modal.setStatus(DiscoveryStatus.WARNING);
                    modal.setMessage(
                            "Discovery exceeded maximum time of 6 hours. There are no changes in number of certificates discovered. Please abort the discovery if the provider is stuck in IN_PROGRESS");
                }

When a new Account is added using a Key that is not yet supported by the server, the server sends malformed as the response. But according to the RFC, the

1. Server checks the Signature Algorithm, if it is not supported, then it should send badSignatureAlgorithm
2. Server checks the key length. If the length is not supported, then it should send badPublicKey

Reason for the decline should be clearly sent in the response

When one discovery process is in the state of IN_PROGRESS, other discoveries are not running and also in the state of IN_PROCESS waiting for the previous discovery to finish.

This is blocking behaviour and the expected is that the discoveries can run in parallel. One discovery should not block the other. In current situation, when there is an issue with the discovery provider, we are waiting until the process is finished, which can take up to 6 hours according to the current implementation in the source code:

private static final Long MAXIMUM_WAIT_TIME = (long) (6 * 60 * 60); // Hours * Minutes * Seconds *

When adding/uploading certificate, serial number is checked for uniqueness (for example when adding/editing user and uploading certificate).

Since serial number is not unique information about certificate across the board, it needs to be changed to fingerprint.

During the certificate upload, when the CRL access is not available, there is an unhandled timeout exception that will be raised and error will be logged. When this happens, the certificate is not stored in the inventory.

The correct behaviour should be that the certificate will be stored in the inventory with the notes that we were not able to validate CRL because of some reason.

[root@STCCAYATCZERT ~]# [2022-05-25 13:06:37.007] ERROR [http-nio-8080-exec-5] [com.czertainly.core.service.impl.CertValidationServiceImpl - 644]: Connection timed out (Connection timed out)
[2022-05-25 13:06:37.040] INFO  [http-nio-8080-exec-5] [audit-log - 82]: {"id":447,"uuid":"0775228f-63ad-4883-bf37-c9d6e67be307","author":"adminadmin","created":"2022-05-25T13:06:37.038547","operationStatus":"SUCCESS","origination":"FE","affected":"CERTIFICATE","operation":"VALIDATE","additionalData":{"certificate":{"uuid":"58c2b9aa-aa5b-451e-a803-c307e139df41","author":"adminadmin","created":"2022-05-24T09:17:31.094148","updated":"2022-05-24T09:21:51.968163","id":13,"commonName":"www.dgc.gov.it","serialNumber":"453852a3c98d14aa9414bc0beae701a4","issuerCommonName":"Actalis Organization Validated Server CA G3","certificateContent":{"id":13,"fingerprint":"7c941e4975a7f4b7c5102bf06c5efa1e8516fc56b3c3b82631690e568348a080","content":"MIIHuDCCBaCgAwIBAgIQRThSo8mNFKqUFLwL6ucBpDANBgkqhkiG9w0BAQsFADCBiTELMAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xFzAVBgNVBAoMDkFjdGFsaXMgUy5wLkEuMTQwMgYDVQQDDCtBY3RhbGlzIE9yZ2FuaXphdGlvbiBWYWxpZGF0ZWQgU2VydmVyIENBIEczMB4XDTIyMDUyMzE0MjAxOVoXDTIzMDUyMzE0MjAwOFowWzELMAkGA1UEBhMCSVQxDTALBgNVBAgMBFJvbWExDTALBgNVBAcMBFJvbWExFTATBgNVBAoMDFNvZ2VpIFMucC5BLjEXMBUGA1UEAwwOd3d3LmRnYy5nb3YuaXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCheYSHrMue7n+IZE9njsK+AMl6/sIe2c0vAbMpZ5ISKO+fxE9cUrXjSAPpY16JQrUlIS//FdAENZ4tptFSbHfZI0dHYMNMWdovqSGl0TKXFADozu3iM5261OQoDvevO5c+aUIGpUdOwBzI+VJW93ddjqwwpwMU/Rh7cqh/5X9AJUJA9+BGm1VkUmyINaDIYJ8btFtns40HaiOA3DUs3uEGkzZHj6/sSienSixnlXA9VE4MNAzJtOT1cuQ8yYuvetFHr5TYCSpC1uXFdC/XERF4RdoFM8q7VAeTNI+pFh//KBa+nn7dRrdEuvfFzi7WSZ+ZetMFIWvnvmmUGL8k/md1AgMBAAGjggNHMIIDQzAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFJ+KsbXxsd6C9Cd8vojN3qlDgaNLMH4GCCsGAQUFBwEBBHIwcDA7BggrBgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0aG92ZzMwMQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIT1YtRzMwJQYDVR0RBB4wHIIOd3d3LmRnYy5nb3YuaXSCCmRnYy5nb3YuaXQwUQYDVR0gBEowSDA8BgYrgR8BFAEwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMAgGBmeBDAECAjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybDA5LmFjdGFsaXMuaXQvUmVwb3NpdG9yeS9BVVRIT1YtRzMvZ2V0TGFzdENSTDAdBgNVHQ4EFgQUhF9G1iGhy5VQfRJBPUs8n128WL0wDgYDVR0PAQH/BAQDAgWgMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdgCt9776fP8QyIudPZwePhhqtGcpXc+xDCTKhYY069yCigAAAYDxU38SAAAEAwBHMEUCIQDhTkKiWvePxHBf2tpeSW2O9c6Va+RP+o5O+OFFiCkdxAIgf86LC8wOLIq4D6vHySzDPU9PcqYA+wAALuzLgwNza/sAdwB6MoxU2LcttiDqOOBSHumEFnAyE4VNO9IrwTpXo1LrUgAAAYDxU39gAAAEAwBIMEYCIQC/ED7RRV/XH3P9uHwxQtlSmB5h+3CsYXN7YMuUxeXI/gIhAMas95QSh+rnwdgX7uRtKnM2ysN6LNnL3LNA9HTAvMoGAHUAb1N2rDHwMRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RMAAAGA8VN/AwAABAMARjBEAiBWdAtcQO5EPkdscJT0AXAgn74nLKwkGqVv1tzrsV5M+gIgAK6X6ZER6D1tjhfqfw/u8BWSGjqAD6gEYJ/AkIqXuxMwDQYJKoZIhvcNAQELBQADggIBAFt78UJGO5y0IEEdmKW+s4/KxMtFnh5x0FyIYuz2cBw7s2vZiLSgcmJ/GJ1JH6yfXcpCsiwp6zu/KVRbmYEvFQD0BcHl+eiZ+McwNA7hc25F7hMymHO7dd12QvfTO8N8mkLDJBji65ML4SKv9V1yptKI1pZKk+bg0xTTSC+zm0h2DUoc5GQqjBtNNOdWAvguFDk+LxBeR/Vd2Zjz4RZ9tQGLfPxDSkJCwP4UNqQb9ATafX2mYyu6D8FNWDtmv+fezSB/iWb+TX6kizuADF+Vkv8Erw4tZPp5ic1TnkPWpUcG5vvYMXttmRzw2HqzKPstPvki+VmBOq4WZt2c148YjPNksCV1vAbamtmA+Re+LXx8zmPUCoDcFLI54V/sAnjgj9XB/NoHQv9ssHIf/zxJZfzAAgW7M1vmJ2YX8GlLOvFO7CmslTWei0haf+qgbspAWKRXm79jCno5rHSzTFiqfhZPCstHnLlJmYP2Yw6m3HSys7/zumxjQdPqkj/CfOYryqbjeBJg5a4a9LeAdtD8aCIFgPzsBgElID3v/JKx2m69SVbN8gnYPlztY6uDKe0cxnlNDpV1hkZtIqRbv/+yP24Yw7K6eaWlu2quEEKQ112VZoBB/6e+P0kghxj3yviegdC8VgClCM08fJPV4+QfC4w2tMb0I2t0wagoVZjTgXVi"},"issuerDn":"CN=Actalis Organization Validated Server CA G3, O=Actalis S.p.A., L=Ponte San Pietro, ST=Bergamo, C=IT","subjectDn":"CN=www.dgc.gov.it, O=Sogei S.p.A., L=Roma, ST=Roma, C=IT","notBefore":"2022-05-23T14:20:19.000+00:00","notAfter":"2023-05-23T14:20:08.000+00:00","publicKeyAlgorithm":"RSA","signatureAlgorithm":"SHA256withRSA","extendedKeyUsage":"[\"1.3.6.1.5.5.7.3.2\",\"1.3.6.1.5.5.7.3.1\"]","keyUsage":"[\"digitalSignature\",\"keyEncipherment\"]","basicConstraints":"Subject Type=End Entity","status":"valid","fingerprint":"7c941e4975a7f4b7c5102bf06c5efa1e8516fc56b3c3b82631690e568348a080","subjectAlternativeNames":"{\"registeredID\":[],\"ediPartyName\":[],\"iPAddress\":[],\"x400Address\":[],\"rfc822Name\":[],\"otherName\":[],\"dNSName\":[\"www.dgc.gov.it\",\"dgc.gov.it\"],\"directoryName\":[],\"uniformResourceIdentifier\":[]}","keySize":2048,"certificateType":"X509","certificateValidationResult":"{\"Signature Verification\":{\"status\":\"not_checked\",\"message\":\"Issuer information unavailable\"},\"Certificate Validity\":{\"status\":\"success\",\"message\":\"Certificate expiry status check successful\"},\"OCSP Verification\":{\"status\":\"not_checked\",\"message\":\"Issuer information unavailable\"},\"CRL Verification\":{\"status\":\"success\",\"message\":\"CRL verification completed successfully.\\nCRL URL(s): http://crl09.actalis.it/Repository/AUTHOV-G3/getLastCRL\"},\"Certificate Chain\":{\"status\":\"warning\",\"message\":\"Issuer certificate cannot be found. It is unavailable in the inventory and in the AIA extension\"}}"},"method":"validate"}}
[2022-05-25 13:06:37.055] INFO  [http-nio-8080-exec-5] [audit-log - 82]: {"id":448,"uuid":"19f3e7f2-6f00-4267-bbdc-7d7c13bd8e39","author":"adminadmin","created":"2022-05-25T13:06:37.054521","operationStatus":"SUCCESS","origination":"FE","affected":"CERTIFICATE","objectIdentifier":"58c2b9aa-aa5b-451e-a803-c307e139df41","operation":"REQUEST","additionalData":{"uuid":"58c2b9aa-aa5b-451e-a803-c307e139df41","method":"getCertificate"}}
[2022-05-25 13:07:19.545] INFO  [http-nio-8080-exec-7] [audit-log - 82]: {"id":449,"uuid":"0efea5e7-3e0a-4933-929c-45b013dc62f0","author":"adminadmin","created":"2022-05-25T13:07:19.544344","operationStatus":"SUCCESS","origination":"FE","affected":"RA_PROFILE","operation":"REQUEST","additionalData":{"isEnabled":true,"method":"listRaProfiles"}}
[2022-05-25 13:07:26.733] INFO  [http-nio-8080-exec-10] [audit-log - 82]: {"id":450,"uuid":"3dd9e31e-2021-4be8-a680-f2bb1ad55e3d","author":"adminadmin","created":"2022-05-25T13:07:26.733285","operationStatus":"SUCCESS","origination":"FE","affected":"CERTIFICATE","operation":"REQUEST","additionalData":{"request":{"filters":[],"itemsPerPage":10,"pageNumber":1},"method":"listCertificates"}}
[2022-05-25 13:07:44.145] INFO  [http-nio-8080-exec-1] [com.czertainly.core.util.OcspUtil - 62]: Chain for the certificate is http://cacert.actalis.it/certs/actalis-authovg3

Secure listing methods of resources with parent resource check.
For listing of certificates use SecurityFilter criteria combined with dynamic search query executor criteria.

When the connector of type Authority Provider is forced to delete that has some dependent authorities, Connector deletion is successful.

But when viewing the details of the Authority or trying to delete it, NullPointerException is thrown in the backend. This is because the details of the Authority are retrieved from the connector and since the connector is not available, the core is not able to communicate with the connector.

In this case, the core should not try to communicate with the Connector, Instead, it should return the only available data and allow the users to delete it

When SecurityFilter needs to be applied in annotated service method, and parent resource and action is specified, evaluate permissions for parent resource-action and fill filter for parent resource.

For example, list RA profiles that have list action permission but also that has allowed specified action for authorities

When the certificate is renewed, the old one contains in the history record that it was renewed and using which RA Profile, for example:

Such record should contain reference using the UUID of the renewed certificate, user can use this reference to identify the renewed certificate, otherwise it is impossible.

Listing certificates endpoint is returning inconsistent response about pagination.

When filter is not applied, API returns only totalPages and totalItems properties.

When filter is applied, API returns all properties but wrong number of items. There is bug when certificates are filter based on selected filter and also filtered with SecurityFilter.

Describe the bug
Using the API for uploading the certificate (https://docs.czertainly.com/api/core-certificate/#operation/upload) returns 201 without the JSON body with the certificate UUID.

Expected behavior
UUID should be returned in a JSON body according to the documentation.

Implement new version of attributes based on proposed design:

• attribute types with attribute definition hierarchy
• base attribute definition extended for each type of attribute
• 3 types of attributes - Data, Group, Info
• individual attribute content type class for each content type
• definition of constraints for attribute value - generic and extensible system

Other implementation that is necessary to resolve:

• update merge and validate algorithm in attribute utils
• migrate currently existing attributes to Data attributes

When the entity provider migration script is executed, it deletes the endpoint_id_sequence instead of entity_id_sequence. Because of this, new end points cannot be created in the database

drop sequence if exists endpoint_id_seq;

should be replaced by drop sequence if exists entity_id_seq;

The Core should be upgraded to Spring Boot 2.6.6 due to RCE vulnerability according to the recommendation:
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

Based on agreement on new attribute definition and its functionality regarding validation and attribute value content schema, it is neccesary to implement those changes in Core. Validation and handling of attributes should be implemented correctly and in full scope since new attribute definition provides accurate and concise information regarding attribute type and structure of its content value.

Requirements:

• add new migration transforming stored attributes information to new attributes definition
• change serialized attributes stored in DB for certificate_location entity of Entity Provider to contain full attribute definition

Authorize individual statistics of dashboard with corresponding resource and action with use of SecurityFilter.

When the certificate is 24 hours before the expiration, it is shown as expired, which is obviously wrong state.

This can be easily simulated by issuing certificate with short validity of 12 hours.

There are some changes that are necessary to do, that will provide more concise User management API.

• user profile endpoint should return UserDetailDTO. There are necessary changes in Auth service response.
• fix update user DTO to contain certificate content instead of fingerprint property
• rename ResourceDetailDTO property listingEndPoint to listObjectsEndpoint

With new user management, certificate has reference to user when it is linked to some user as authentication mechanism. Implement following when user certificate is modified:

• when user is updated with some certificate or removed certificate, change this information in corresponding certificate entities
• when certificate is deleted, check if there is no user linked

When ACME client endpoints are called, Core service should use internal authentication and authenticate request in sake of ACME client. Instead of anonymous user, permissions will be evaluated against permissions of ACME system user. In this way, authorization of ACME client operations will be consistent with other users of platform.

Credentials attribute of type SECRET is not masked when returned as part of response of GET detail of authority or entity.

In CertificateServiceImp, the certificate content is being deleted before the certificate, which cause an issue because the content is referenced from the certificate:

        if (discoveryCertificateRepository.findByCertificateContent(certificate.getCertificateContent()).isEmpty()) {
            CertificateContent content = certificateContentRepository
                    .findById(certificate.getCertificateContent().getId()).orElse(null);
            if (content != null) {
                certificateContentRepository.delete(content);
            }
        }

        certificateRepository.delete(certificate);

At the start of Core service, synchronization of endpoints with Auth service should be realized.
That way we can keep Auth service up-to-date with current set of endpoints with its authorization-related information.

Core service should collect information about all endpoints to list objects for resource.

In addition, ExternalAuthorization annotations also contain additional resource - action couples to retrieve and include in sync mechanism.

Requirements:

• collect resource list object endpoints info from controllers methods annotations
• collect resource/action info from services methods ExternalAuthorization annotations

Access control on level of specific objects is responsibility of Core and OPA evaluation of permissions of authenticated user. Core should implement endpoints to retrieve permissions for specific resource/action/object.

Requirements:

• endpoint to retrieve allowed actions for specified resources
• endpoint to retrieve resources with allowed specified action
• include also object filter

Compliance Profiles will be implemented as part of Core. The core logic will contain the following

• Perform CRUD operations on the Compliance Profiles
• Stores references of the rules provided by the Compliance Provider
• Initiates compliance check and stores the result per certificate in core database tables

Tasks:

• Implement Controller and End Points for Compliance Profile
• Based on the interfaces from Interface repository, implement the controller logic for all the end points to required. These end points should include Compliance Profiles, Tagging to RA Profile and Compliance Check items
• Addition of new Function Group across Core
• Add the new Function Group "complianceProvider" across the Core implementation to allow it in the methods
• Implement DAO Object classes and Database design for Compliance Profiles
• Implement the Database Script needed to create the compliance profile, update Certificate table with the compliance data etc...
• Implement Compliance Provider service and respositories
• Add JPA Repositories for the newly created tables for Compliance Profiles and related items
• Implement Core logic to handle Compliance Provider redirection service
• Implementation of logic, Services and Service Implementation for the Compliance related Objects.
• Implement Certificate Compliance Check logic
• Implement the compliance check logic including calling Connectors, updating validation information, Triggering validations based on dicovery and other related items

Actually, metadata that are sent between core and connectors are represented as JSON object with key-pair values. Updating metadata to attributes definition structure and possibly include it in attributes hierarchy as new type will allow to work with metadata values easier.

Metadata with defined content type can be easier processed and their value correctly displayed, used as filtering value or included in statistics.

Currently stored metadata should be migrated to have InfoAttribute definition structure, with type META. Since, there is no type indication in current values, use String content type for existing metadata.

Elliptic Curve support should be added for ACME. Currently, only RSA-based keys will be accepted for the ACME operations. But according to RFC, EC Keys can also be used. Hence this functionality should be added

Add specific information what permissions were missing for user to perform action that resulted in 403. For example, Forbidden to perform action. Missing 'create' permission on resource 'authority'.

Describe the bug
When one discovery is still IN PROGRESS, other discoveries are waiting and are not performing. While one discovery failed (did not finish for some reason), it is not possible to perform any other discovery.

Expected behavior
Independent discovery performing.

When you want to renew/issue certificate in location and its RA Profile is disabled, renew fails but certificate will be deleted, created but not issued by authority. Also there is no message in cert event history about failed renewal.

detail certificate - list of location certificates is always in different order when reloaded. Need to add some order by to SQL.

Implement new Core API for managing Entities:

• entity CRUD operations interface
• certificate locations interface
• certificate management interface

When uploading CSR to issue or renew certificate from the Operator UI, it is always Base64 encoded. This cause issues when requesting for certificate, when the format of the CSR is not binary.

For example, when the CSR is PEM encoded, the resulting PKCS10 will be Base64 encoded PEM file, which is already Base64 encoded. Therefore, there is inconsistency in the CSR format coming to the connector and the connector is not able to handle it properly. There is non-deterministic behaviour and for the connector it means to handle all types of possible options, which does not make sense.

The formatting of the CSR must be guaranteed by the CZERTAINLY (UI or the CORE). For example, it can be the Base64 encoded binary CSR data.

In the documentation we have the following for example:
Certificate sign request (PKCS#10) encoded as Base64 string, but that is clearly not true and there is no check in the Core or in the UI for not properly encoded data.
(https://docs.czertainly.com/api/core-client-operations/#operation/issueCertificate)

• create migration script to register new entity provider to Core
• store its endpoints in database for future validation of connector
• modify current DB model and implementation to allow adding certificate to multiple entities and locations

When attempting to delete the client, if the client has an authorized RA Profile, it returns a 500 internal server error.

But the expected behavior is that the Core returns 422 Validation Exception with relevant data with it.

The same is applicable for bulk delete client operations. If the client has authorized RA Profiles, then it should return 422 with relevant validation messages.

To secure individual endpoints of Core service, it is ideal to use existing spring framework security functionality. Custom PermissionEvaluator needs to be implemented to evaluate if user/role is authorized to access endpoint by requesting Authorization service evaluation. And if applicable, microservice specific access control is evaluated, too.

Reference: [https://www.baeldung.com/spring-security-create-new-custom-security-expression]

Requirements:

• secure endpoints with spring security annotations
• custom PermissionEvaluator
• object-level access control evaluation

Global metadata attributes represents Info attributes that can be registered by users of Czertainly instead of connectors.

Global metadata attributes allows to reuse same definition of metadata during implementation of connectors. That way metadata with same semantic meaning can be collected consistently across individual objects. Since content that can be stored in metadata attribute is specified by its content type, values stored in them are represented consistently. This makes searching and filtering objects based on selected global metadata value easier.

Requirements:

• implement routes for management/registration of global metadata and storing its definitions and values in DB.
• create mechanism that groups already created connector metadata of same name and type under registered global metadata definition.

Describe the bug
When there are multiple metadata for the same Certificate, values are overwritten for the same key instead of being merged.

Expected behavior
Metadata is updated with additional values, they are merged, not overwritten with the last value.

attribute mapping target should match the name in the callback data.

Currently, from the attribute definition it is "pathVariable" | "requestParameter" | "body" while in the callback data it is "pathVariables" | "queryParameters" | "requestBody".

Including the "s". It would allow to use single enum / type instead of remapping one type to another.

There are following issues with running asynchronous discovery:

• running discovery process keeps DB connection open and when running more in parallel leads to empty connection pool. Issue could be caused by @transactional annotation which opens DB connection.
• fix delete of discovery (Request method 'DELETE' not supported)
• validation of attributes for discovery - example port for IP discovery has default value but if no value is provided by user, default value is not used -> NullPointerException

Migrate existing clients and admins to Auth service with its corresponding users and their roles. Create Java migration to transfer users data and clients authorization to RA profiles

Requirements:

• add system roles with its permissions (superadmin, admin and ACME client role)
• map admins to user with admin role
• for each RA profile existing in client authorizations create role with permissions to all operations on that specific RA profile
• add RA profile authorization role to clients that are authorized to that specific RA profile
• implement changes in creation of local superadmin
• drop admins, clients and client authorizations

Use ExternalAuthorization annotation to annotate methods of Core services to evaluate permissions of authenticated user for individual actions.

Check and if necessary annotate following services methods:

• ClientOperationService
• ClientOperationService v2
• AcmeAccountService
• AcmeProfileService
• AuditLogService
• AuthorityInstanceService
• CallbackService
• CertificateService
• CertValidationService
• ComplianceProfileService
• ComplianceService
• ConnectorAuthService
• ConnectorRegistrationService
• ConnectorService
• CoreCallbackService
• CredentialService
• DiscoveryService
• EntityInstanceService
• GroupService
• LocalAdminService
• LocationService
• RaProfileService
• RoleManagementService
• SearchService
• UserManagementService

Compliance profile's rules are now stored as RequestAttributeDtos and also returned as one in response DTO. That is inconsistent with other objects in Core.

Compliance profile rule response DTO should contain ResponseAttributeDtos. That way the detail of set attributes of rule are represented same. It could be achieved by storing full attribute for rule and return list of ResponseAttributeDto or fill the missing properties of ResponseAttributeDto from attribute definition stored in DB.

Based on Auth service API specification, implement permissions routes and its DTOs.

Add handling of 4xx and 5xx error responses from Auth service consistently.

Custom attributes represents Data attributes that can be registered by users of Czertainly instead of connectors.

Custom attributes allows users to add additional properties to various objects with specified value. Since content that can be stored in attribute is specified by its content type, values stored in them are represented consistently. This makes searching and filtering objects based on selected custom attribute value easier.

Requirements:

• implement routes for management/registration of custom attributes and storing its definitions and values in DB.