doc updates (#33)
This commit is contained in:
Martin Regen
GitHub
Родитель
f176f7ebb7
Коммит
5987f95c4d
|
|
@ -48,6 +48,7 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "docs", "docs", "{E9C6A792-1
|
|||
DEVELOPMENT.md = DEVELOPMENT.md
|
||||
docs\howto-deploy-services.md = docs\howto-deploy-services.md
|
||||
docs\howto-run-services-locally.md = docs\howto-run-services-locally.md
|
||||
docs\howto-secureca-services.md = docs\howto-secureca-services.md
|
||||
docs\howto-use-cert-services.md = docs\howto-use-cert-services.md
|
||||
README.md = README.md
|
||||
EndProjectSection
|
||||
|
|
@ -75,6 +76,10 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "docker", "docker", "{1724C5
|
|||
Dockerfile.Windows-Server2016 = Dockerfile.Windows-Server2016
|
||||
EndProjectSection
|
||||
EndProject
|
||||
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "GlobalDiscoveryClientLibrary", "..\UA-.NETStandard\SampleApplications\Samples\GDS\ClientCommon\GlobalDiscoveryClientLibrary.csproj", "{A443FE76-D848-45AE-9F96-86B71622A461}"
|
||||
EndProject
|
||||
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Opc.Ua.Client", "..\UA-.NETStandard\SampleApplications\SDK\Opc.Ua.Client\Opc.Ua.Client.csproj", "{E26CB7C4-8B8D-4A19-AD98-0A37D5545CD1}"
|
||||
EndProject
|
||||
Global
|
||||
GlobalSection(SolutionConfigurationPlatforms) = preSolution
|
||||
Debug|Any CPU = Debug|Any CPU
|
||||
|
|
@ -160,6 +165,18 @@ Global
|
|||
{5343FE2C-2177-4643-B2AA-924DA10C25F9}.Develop|Any CPU.Build.0 = Debug|Any CPU
|
||||
{5343FE2C-2177-4643-B2AA-924DA10C25F9}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
||||
{5343FE2C-2177-4643-B2AA-924DA10C25F9}.Release|Any CPU.Build.0 = Release|Any CPU
|
||||
{A443FE76-D848-45AE-9F96-86B71622A461}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
||||
{A443FE76-D848-45AE-9F96-86B71622A461}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
||||
{A443FE76-D848-45AE-9F96-86B71622A461}.Develop|Any CPU.ActiveCfg = Debug|Any CPU
|
||||
{A443FE76-D848-45AE-9F96-86B71622A461}.Develop|Any CPU.Build.0 = Debug|Any CPU
|
||||
{A443FE76-D848-45AE-9F96-86B71622A461}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
||||
{A443FE76-D848-45AE-9F96-86B71622A461}.Release|Any CPU.Build.0 = Release|Any CPU
|
||||
{E26CB7C4-8B8D-4A19-AD98-0A37D5545CD1}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
||||
{E26CB7C4-8B8D-4A19-AD98-0A37D5545CD1}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
||||
{E26CB7C4-8B8D-4A19-AD98-0A37D5545CD1}.Develop|Any CPU.ActiveCfg = Debug|Any CPU
|
||||
{E26CB7C4-8B8D-4A19-AD98-0A37D5545CD1}.Develop|Any CPU.Build.0 = Debug|Any CPU
|
||||
{E26CB7C4-8B8D-4A19-AD98-0A37D5545CD1}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
||||
{E26CB7C4-8B8D-4A19-AD98-0A37D5545CD1}.Release|Any CPU.Build.0 = Release|Any CPU
|
||||
EndGlobalSection
|
||||
GlobalSection(SolutionProperties) = preSolution
|
||||
HideSolutionNode = FALSE
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
"Id": "Default",
|
||||
"CertificateType": "RsaSha256ApplicationCertificateType",
|
||||
"SubjectName": "CN=Azure Industrial IoT CA, O=Microsoft Corp.",
|
||||
"DefaultCertificateLifetime": 12,
|
||||
"DefaultCertificateLifetime": 24,
|
||||
"DefaultCertificateKeySize": 2048,
|
||||
"DefaultCertificateHashSize": 256,
|
||||
"IssuerCACertificateLifetime": 60,
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ This article explains how to manage the OPC UA Certificate Management Service se
|
|||
|
||||
## Roles
|
||||
|
||||
### Trusted and authorized roles must be defined
|
||||
### Trusted and authorized roles
|
||||
|
||||
The Service is configured to allow for distinct roles to access various parts of the service.
|
||||
|
||||
|
|
@ -23,11 +23,11 @@ The service defines the following roles:
|
|||
- **Approver**: The approver role is assigned to a user to approve or reject certificate requests. The role does not include any other role.
|
||||
- In addition to the Approver role to access the microservice the user must also have signing rights in Key Vault to be able to sign the certificates.
|
||||
- The Writer and Approver role should be assigned to different users.
|
||||
- Ideally, Writer, Approver and Administrator role are assigned to different users. For additional security, a user with Approver role needs also Signing rights in KeyVault to issue certificates or to renew an Issuer CA certificate.
|
||||
- The main role of the Approver is the Approval of the generation and rejection of certificate requests.
|
||||
- **Administrator**: The administrator role is assigned to a user to manage the certificate groups. The role does not support the Approver role, but includes the Writer role.
|
||||
- The administrator can manage the certificate groups, change the configuration and revoke application certificates by issueing a new CRL.
|
||||
- In addition to the service role, his role includes but is not limited to:
|
||||
- Ideally, Writer, Approver and Administrator role are assigned to different users. For additional security, a user with Approver or Administrator role needs also Key Signing rights in KeyVault to issue certificates or to renew an Issuer CA certificate.
|
||||
- In addition to the service role, his role includes also but is not limited to:
|
||||
1. Responsible for administering the implementation of the CA’s security practices.
|
||||
2. Management of the generation, revocation, and suspension of certificates.
|
||||
3. Cryptographic key life cycle management (e.g. the renewal of the Issuer CA keys).
|
||||
|
|
@ -98,7 +98,7 @@ that security events are transmitted to the monitoring solution.
|
|||
|
||||
All open source components used within a product or service must be free of moderate or greater security vulnerabilities.
|
||||
|
||||
**Important note:** The github repository of the OPC Vault service is scanning all components during continously integration
|
||||
**Important note:** The github repository of the OPC Vault service is scanning all components during continous integration
|
||||
builds for vulnerabilities. The updates on github should be monitored and the updates be applied to the service at regular intervals.
|
||||
|
||||
### Maintain an inventory
|
||||
|
|
@ -113,31 +113,126 @@ In **Azure**:
|
|||
- **App Service Plan**: App service plan for service hosts. Default S1.
|
||||
- **App Service** for microservice: The OPC Vault service host.
|
||||
- **App Service** for sample application: The OPC Vault sample application host.
|
||||
- **KeyVault Standard**: To store secrets and Cosmos DB keys for web service.
|
||||
- **KeyVault Standard**: To store secrets and Cosmos DB keys for the web services.
|
||||
- **KeyVault Premium**: To host the Issuer CA keys, for signing service, for vault configuration and storage of application private keys.
|
||||
- **Cosmos DB**: Database for application-
|
||||
- **Cosmos DB**: Database for application and certificate requests.
|
||||
- **Application Insights**: (optional) Monitoring solution for web service and application.
|
||||
- **AzureAD Application Registration**: A registration for the sample application, the service and the edge module.
|
||||
|
||||
For the cloud services all hostnames, Resource Groups, Resource Names, Subscription Id, TenantId used to deploy the service should be documented.
|
||||
|
||||
In **IoT Edge** or local a **Server**:
|
||||
- **Global Discovery Server**: To support a factory network Global Discovery Server.
|
||||
-
|
||||
|
||||
For the edge devices the hostnames and IP addresses and should be documented.
|
||||
|
||||
### Document the Certification Authorities (CAs)
|
||||
|
||||
The CA hierarchy documentation must contain all operated CAs including all related
|
||||
subordinate CAs, parent CAs, and root CAs, even when they are not managed by the service.
|
||||
An exhaustive set of all non-expired CA certificates may be provided instead of formal documentation.
|
||||
|
||||
**Important note:** The OPC Vault sample application supports for download of all certificates used and prodcued in the service for documentation.
|
||||
**Important note:** The OPC Vault sample application supports for download of all certificates used and produced in the service for documentation.
|
||||
|
||||
### Document the issued certificates by all Certification Authorities (CAs)
|
||||
|
||||
An exhaustive set of all certificates issued in the past 12 months should be provided for documentation.
|
||||
|
||||
**Important note:** The OPC Vault sample application supports for download of all certificates used and produced in the service for documentation.
|
||||
|
||||
### Document the SOP for securely deleting cryptographic keys
|
||||
|
||||
Key deletion may only rarely happen during the lifetime of a CA, this is why no user has KeyVault Certificate Delete
|
||||
rights assigned and why there are no APIs exposed to delete an Issuer CA certificate.
|
||||
right assigned and why there are no APIs exposed to delete an Issuer CA certificate.
|
||||
The manual standard operating procedure for securely deleting certification authority cryptographic keys is only available by directly
|
||||
accessing the KeyVault in the Azure portal and by deleting the certificate group in KeyVault. For ensure immediate deletion
|
||||
accessing the KeyVault in the Azure portal and by deleting the certificate group in KeyVault. To ensure immediate deletion
|
||||
[KeyVault soft delete](https://docs.microsoft.com/en-us/azure/key-vault/key-vault-ovw-soft-delete) should be disabled.
|
||||
|
||||
## Certificates
|
||||
|
||||
### Certificates must comply with minimum certificate profile
|
||||
|
||||
The OPC Vault service is an online Certification Authorities (CAs) that issues end entity certificates to subscribers.
|
||||
The Microservice follows these guidelines in the default implementation.
|
||||
|
||||
- All certificates must include the following X.509 fields as specified below:
|
||||
- The content of the version field must be v3.
|
||||
- The contents of the serialNumber field must include at least 8 bytes of entropy obtained from a FIPS 140 approved random number generator.
|
||||
**Important Note:** The OPC Vault serial number is by default 20 byte and obtained from OS cryptographic random number generator. The random number generator is FIPS 140 approved o Windows devices, however not on Linux flavors. This fact needs to be considered when choosing a service deployment which uses Linux VMs or Linux docker containers, on which the underlying technology OpenSSL is usually not FIPS 140 approved.
|
||||
- The issuerUniqueID and subjectUniqueID fields must not be present.
|
||||
**Important Note:** The CRL Distribution Point (CDP) is not present in OPC OPC Vault CA Certificates, because there are custom methods used in OPC UA to distribute CRLs.
|
||||
- End-entity certificates must be identified with the Basic Constraints extension in accordance with IETF RFC 5280.
|
||||
- The pathLenConstraint field must be set to 0 for the Issuing CA certificate.
|
||||
- The Extended Key Usage extension must be present and contain the minimum set of Extended Key Usage object identifiers (OIDs). The anyExtendedKeyUsage OID (2.5.29.37.0) must not be specified.
|
||||
- Approved asymmetric algorithms, key lengths, hash functions and padding modes must be used.
|
||||
- **RSA** and **SHA-2** are the only supported algorithms (*).
|
||||
- RSA may be used for encryption, key exchange and signature.
|
||||
- RSA encryption must use only the OAEP, RSA-KEM, or RSA-PSS padding modes.
|
||||
- Key lengths >= 2048 bits are required.
|
||||
- Use the SHA-2 family of hash algorithms (SHA256, SHA384, and SHA512).
|
||||
- RSA Root CA keys with a typical lifetime >= 20 years must be 4096 bits or greater.
|
||||
- RSA Issuer CA keys must be at least 2048 bits; if the CA certificate expiration date is after 2030, the CA key must be 4096 bits or greater.
|
||||
- Certificate Lifetime
|
||||
- Root CA certificates: The maximum certificate validity period for root CAs must not exceed 25 years.
|
||||
- Sub CA or online Issuer CA certificates: The maximum certificate validity period for CAs that are online and issue only subscriber
|
||||
certificates must not exceed 6 years. For these CAs the related private signature key must not be used longer than 3 years to issue new certificates.
|
||||
**Important Note:** The Issuer certificate as it is generated in the default OPC Vault service without external Root CA is treated like a online Sub CA with respective requirements and lifetimes. The default lifetime is set to 5 years with a key length >= 2048.
|
||||
- All asymmetric keys must have a maximum five-year lifetime, recommended one-year lifetime.
|
||||
**Important Note:** By default the lifetimes of application certificates issued with OpcVault have a lifetime of 2 years and should be replaced every year.
|
||||
- Whenever a certificate is renewed, it is renewed with a new key.
|
||||
- OPC UA specific extensions in application instance certificates
|
||||
- The subjectAltName extension includes the application Uri and hostnames, which may also include FQDN, IPv4 and IPv6 addresses.
|
||||
- The keyUsage includes digitalSignature, nonRepudiation, keyEncipherment and dataEncipherment.
|
||||
- The extendedKeyUsage includes serverAuth and/or clientAuth.
|
||||
- The authorityKeyIdentifier is specified in signed certificates.
|
||||
|
||||
### Certificate Authority (CA) keys and certificates must meet minimum requirements
|
||||
|
||||
- **Private keys**: **RSA** keys must be at least 2048 bits; if the CA certificate expiration date is after 2030, the CA key must be 4096 bits or greater.
|
||||
- **Lifetime**: The maximum certificate validity period for CAs that are online and issue only subscriber certificates must not exceed 6 years. For these CAs the related private signature key must not be used longer than 3 years to issue new certificates.
|
||||
|
||||
### CA keys are protected using Hardware Security Modules (HSM)
|
||||
|
||||
- OpcVault uses Azure KeyVault Premium and keys are protected by FIPS 140-2 Level 2 Hardware Security Modules (HSM).
|
||||
|
||||
The cryptographic modules that Key Vault uses, whether HSM or software, are FIPS (Federal Information Processing Standards) validated.
|
||||
Keys created or imported as HSM-protected are processed inside an HSM, validated to FIPS 140-2 Level 2.
|
||||
Keys created or imported as software-protected, are processed inside cryptographic modules validated to FIPS 140-2 Level 1.
|
||||
|
||||
## Operational Practices
|
||||
|
||||
### Document and maintain standard operational PKI practices for certificate enrollment
|
||||
|
||||
Document and maintain standard operational procedures (SOPs) for how CAs issue certificates, including:
|
||||
- How the subscriber is identified and authenticated
|
||||
- How the certificate request is processed and validated (if applicable, include also how certificate renewal and rekey requests are processed)
|
||||
- How issued certificates are distributed to the subscribers
|
||||
|
||||
The OPCVault SOP is described in the [Overview](opcvault-services-overview.md) and the [How to use](howto-use-cert-services.md) documents.
|
||||
|
||||
|
||||
### Document and maintain standard operational PKI practices for certificate revocation
|
||||
|
||||
The certificate revokation process is described in the [Overview](opcvault-services-overview.md) and the [How to use](howto-use-cert-services.md) documents.
|
||||
|
||||
### Document Certification Authority key generation ceremony
|
||||
|
||||
The Issuer CA key generation in OPCVault is simplified due to the secure storage in Azure KeyVault and described in the [How to use](howto-use-cert-services.md) documentation.
|
||||
|
||||
However, when an external Root certification authority is being used,
|
||||
a Certificate Authority (CA) key generation ceremony must adhere to the following requirements:
|
||||
|
||||
The CA key generation ceremony must be performed against a documented script that includes at least the following items:
|
||||
1. Definition of roles and participant responsibilities
|
||||
2. Approval for conduct of the CA key generation ceremony
|
||||
3. Cryptographic hardware and activation materials required for the ceremony
|
||||
4. Hardware preparation (including asset/configuration information update and sign off)
|
||||
5. Operating system installation
|
||||
6. Specific steps performed during the CA key generation ceremony, such as:
|
||||
7. CA application installation and configuration
|
||||
8. CA key generation
|
||||
9. CA key backup
|
||||
10. CA certificate signing
|
||||
9. Import of signed keys in the protected HSM of the service.
|
||||
11. CA system shutdown
|
||||
12. Preparation of materials for storage
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
### Azure Industrial IoT OPC Unified Architecture (OPC UA) Certificate Management Service
|
||||
|
||||
This article gives an overview about the OPC UA Certificate Management Service in Azure and the core microservice called OPCVault.
|
||||
This article gives an overview about the OPC UA Certificate Management Service and the core microservice called OPCVault.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
@ -48,8 +48,8 @@ supports a micro service backed edge module which implements the
|
|||
OPC UA Global Discovery Server interface to distribute certificates
|
||||
and trust lists according to the Part 12 specification.
|
||||
However, as of our knowledge, this GDS server interface is not widely
|
||||
used yet and has yet limited functionality (Reader role). On demand, we will
|
||||
improve the experience on customer request.
|
||||
used yet and has yet limited functionality (Reader role). [On demand, we will
|
||||
improve the experience on customer request (*)](/docs/Yet-Unsupported-features).
|
||||
|
||||
## Architecture
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ for applications with search expressions.
|
|||
a valid application in order to process a request and to issue a signed certificate
|
||||
with all OPC UA specific extensions.
|
||||
- The application service is either backed by a CosmosDB
|
||||
database or the OpcTwin device registry, depending on the customer configuration.
|
||||
database or the [OpcTwin device registry (*)](/docs/Yet-Unsupported-features), depending on the customer configuration.
|
||||
|
||||
### CertificateGroup
|
||||
- A certificate group is an entity which stores a root CA or a sub CA certificate
|
||||
|
|
@ -82,29 +82,32 @@ including the private key to sign certificates.
|
|||
- The RSA key length, the SHA-2 hash length
|
||||
and the lifetimes are configurable for both Issuer CA and signed application certificates.
|
||||
- Multiple groups can be hosted in a single service to allow for future extensions with https,
|
||||
user or ECC algorithm certificate groups (*).
|
||||
user or ECC algorithm certificate groups [(*)](/docs/Yet-Unsupported-features).
|
||||
- The CA certificates are stored in Azure Key Vault backed with FIPS 140-2 Level 2 Hardware Security Modules (HSM).
|
||||
The private key never leaves the secure storage because signing is done
|
||||
by an AzureAD secured Key Vault operation.
|
||||
- The CA certificates can be renewed over time and
|
||||
remain still in safe storage due to Key Vault history.
|
||||
- The revocation list for each CA certificate is also stored in Key Vault as a secret.
|
||||
Once an application is unregistered, the application certificate is also revoked in the CRL.
|
||||
Once an application is unregistered, the application certificate is also revoked in the CRL by an administrator.
|
||||
- Batched and single certificate revocation is supported.
|
||||
|
||||
### CertificateRequest
|
||||
A certificate request implements the workflow to generate a new key pair or a signed certificate using a CSR for an OPC UA Application.
|
||||
- The request is stored in a database with accompanying information like the Subject or a “Certificate Signing Request” (CSR) and a reference to the OPC UA Application.
|
||||
- The business logic in the service validates the request against the information stored in the application database. E.g. the Application Uri must match.
|
||||
- A security administrator with signing rights (Approver role) approves or rejects the request. If the request is approved, a new key pair and/or a signed certificate are generated. The new private key is securely stored in KeyVault until downloaded and accepted by the requester.
|
||||
- The business logic in the service validates the request against the information stored in the application database.
|
||||
For example the application Uri in the database must match the application Uri in the CSR.
|
||||
- A security administrator with signing rights (Approver role) approves or rejects the request. If the request is approved, a new key pair and/or a signed certificate are generated. The new private key is securely stored in KeyVault while the new signed public certificate is stored in the Certificate Request database.
|
||||
- The requester can poll the request status until it is approved or revoked. If the request was approved, the private key and the certificate can be downloaded and installed in the certificate store of the OPC UA application.
|
||||
- The requestor can now Accept the request to delete unnecessary information from the request database.
|
||||
- The requestor can now Accept the request to delete unnecessary information from the request database.
|
||||
|
||||
Over the lifetime of a signed certificate an application might be deleted or a certificate might be compromised. In such a case, a CA manager can:
|
||||
- Delete an application, which in turn deleted also all pending and approved certificate requests. Or delete a single certificate request if only a key is renewed or compromised.
|
||||
- Approved and Accepted certificate requests are marked as deleted.
|
||||
- A manager may regularly execute a renewal of the Issuer CA CRL. During such an event, all the deleted Certificate Requests are revoked and the certificate serial numbers are added to the CRL revocation list. Revoked certificate requests are marked as revoked.
|
||||
- In urgent events, single certificate requests can be revoked.
|
||||
- The updated CRLs are available for distribution to the participating OPC UA clients and servers.
|
||||
Over the lifetime of a signed certificate an application might be deleted or a key might become compromised. In such a case, a CA manager can:
|
||||
- Delete an application, which at the same time deletes also all pending and approved certificate requests of the app.
|
||||
- Another option is to delete just the single certificate request if only a key is renewed or compromised.
|
||||
- Now compromised Approved and Accepted certificate requests are marked as deleted.
|
||||
- A manager may regularly execute a renewal of the Issuer CA CRL. At the renewal time all the deleted Certificate Requests are revoked and the certificate serial numbers are added to the CRL revocation list. Revoked certificate requests are marked as revoked.
|
||||
- In urgent events, single certificate requests can be revoked, too.
|
||||
- Finally the updated CRLs are available for distribution to the participating OPC UA clients and servers.
|
||||
|
||||
See swagger documentation of the OPC Vault Microservice for more information on the API.
|
||||
|
||||
|
|
@ -112,8 +115,10 @@ See swagger documentation of the OPC Vault Microservice for more information on
|
|||
To support a factory network Global Discovery Server the OPC Vault module can be deployed on the edge,
|
||||
execute as a local .Net Core application or can be started in a docker image.
|
||||
Due to a lack of Auth2 authentication support in the current OPC UA .Net Standard stack,
|
||||
the functionality of OPC Vault edge module is limited to a Reader role, because a user cannot be
|
||||
the functionality of the OPC Vault edge module is limited to a Reader role, because a user cannot be
|
||||
impersonated from the edge module to the micro service using the OPC UA GDS standard interface.
|
||||
Only operations which do not require the Write, Manage or Sign role are permitted at this point(*).
|
||||
Only operations which do not require the Write, Manage or Sign role are permitted at this point[(*)](/docs/Yet-Unsupported-features).
|
||||
|
||||
(*) not supported yet, please open issues to request new features.
|
||||
## Yet Unsupported features
|
||||
|
||||
**(*)** not supported yet, please open issues to request support for new features.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
"Id": "Default",
|
||||
"CertificateType": "RsaSha256ApplicationCertificateType",
|
||||
"SubjectName": "CN=Azure Industrial IoT CA, O=Microsoft Corp.",
|
||||
"DefaultCertificateLifetime": 12,
|
||||
"DefaultCertificateLifetime": 24,
|
||||
"DefaultCertificateKeySize": 2048,
|
||||
"DefaultCertificateHashSize": 256,
|
||||
"IssuerCACertificateLifetime": 60,
|
||||
|
|
|
|||
|
|
@ -16,7 +16,9 @@ using Microsoft.Azure.IIoT.OpcUa.Services.Vault.v1.Models;
|
|||
|
||||
namespace Microsoft.Azure.IIoT.OpcUa.Services.Vault.v1.Controllers
|
||||
{
|
||||
/// <inheritdoc/>
|
||||
/// <summary>
|
||||
/// Application services.
|
||||
/// </summary>
|
||||
[ApiController]
|
||||
[Route(VersionInfo.PATH + "/app"), TypeFilter(typeof(ExceptionsFilterAttribute))]
|
||||
[Produces("application/json")]
|
||||
|
|
@ -57,6 +59,9 @@ namespace Microsoft.Azure.IIoT.OpcUa.Services.Vault.v1.Controllers
|
|||
/// <summary>
|
||||
/// Get application.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// Returns the record of any application.
|
||||
/// </remarks>
|
||||
/// <param name="applicationId">The application id</param>
|
||||
/// <returns>The application record</returns>
|
||||
[HttpGet("{applicationId}")]
|
||||
|
|
@ -109,11 +114,13 @@ namespace Microsoft.Azure.IIoT.OpcUa.Services.Vault.v1.Controllers
|
|||
/// <summary>
|
||||
/// Unregister application.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// Unregisters the application record and all associated information.
|
||||
/// The application record remains in the database in 'Unregistered' state.
|
||||
/// Certificate Requests associated with the application id are set to the 'Deleted' state,
|
||||
/// and will be revoked with the next CRL update.
|
||||
/// Requires Writer role.
|
||||
///</remarks>
|
||||
/// <param name="applicationId">The application id</param>
|
||||
[HttpDelete("{applicationId}/unregister")]
|
||||
[Authorize(Policy = Policies.CanWrite)]
|
||||
|
|
@ -125,10 +132,12 @@ namespace Microsoft.Azure.IIoT.OpcUa.Services.Vault.v1.Controllers
|
|||
/// <summary>
|
||||
/// Delete application.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// Deletes the application record.
|
||||
/// Certificate Requests associated with the application id are set in the deleted state,
|
||||
/// and will be revoked with the next CRL update.
|
||||
/// Requires Manager role.
|
||||
/// </remarks>
|
||||
/// <param name="applicationId">The application id</param>
|
||||
/// <param name="force">optional, skip sanity checks and force to delete application</param>
|
||||
[HttpDelete("{applicationId}")]
|
||||
|
|
@ -169,9 +178,9 @@ namespace Microsoft.Azure.IIoT.OpcUa.Services.Vault.v1.Controllers
|
|||
/// <summary>
|
||||
/// Query applications by id.
|
||||
/// </summary>
|
||||
/// <remark>
|
||||
/// <remarks>
|
||||
/// A query model which supports the OPC UA Global Discovery Server query.
|
||||
/// </remark>
|
||||
/// </remarks>
|
||||
/// <param name="query"></param>
|
||||
/// <returns></returns>
|
||||
[HttpPost("querybyid")]
|
||||
|
|
@ -199,11 +208,11 @@ namespace Microsoft.Azure.IIoT.OpcUa.Services.Vault.v1.Controllers
|
|||
/// <summary>
|
||||
/// Query applications.
|
||||
/// </summary>
|
||||
/// <remark>
|
||||
/// <remarks>
|
||||
/// List applications that match the query model.
|
||||
/// The returned model can contain a next page link if more results are
|
||||
/// available.
|
||||
/// </remark>
|
||||
/// </remarks>
|
||||
/// <param name="query">The Application query parameters</param>
|
||||
/// <param name="nextPageLink">optional, link to next page </param>
|
||||
/// <param name="pageSize">optional, the maximum number of result per page</param>
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче