ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-28 16:58:55 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Paired back to just recommendation for private instance

Browse Source
This commit is contained in:
David Lee 2017-12-01 14:06:58 +00:00
parent 0d6a880996
commit 57634bd9df
2 changed files with 36 additions and 82 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
docs/source/design/doorman-admin-ui/decisions/near-term.md
View File

@ -1,67 +0,0 @@
![Corda](https://www.corda.net/wp-content/uploads/2016/11/fg005_corda_b.png)
--------------------------------------------
Design Decision: Near-term solution for Doorman Administration UI
============================================
## Background / Context
A decision is required specifically on the doorman UI to be used for the near-term Pilot network, to be launched on Feb 1, 2018. See [main design doc](../design.md) for more context.
## Options Analysis
### A. Existing R3 Atlassian-Hosted JIRA
#### Advantages
1. Incumbent option - no change required
#### Disadvantages
1. Risk to R3 corporate operations exposed by JIRA integration of Doorman
2. Potential security challenges (See [main design doc](../design.md))
### B. Separate Atlassian-Hosted JIRA
#### Advantages
1. Minimal infrastructure deployment requirement - just buy a new account
2. HA and DR provided by Atlassian (in principle - no easily enforceable SLAs etc.)
#### Disadvantages
1. Scalability and performance under large loads unclear
2. Flexibility to support long term requirements unclear - may be just a 'stop-gap'
### C. Private JIRA installation
#### Advantages
1. Low/no development effort to change
2. A single installation with no HA etc. may be relatively cheap - [$10 for 10 users ](https://www.atlassian.com/software/jira/pricing?tab=self-hosted)
3. Self-ownership of HA/DR issues may provide greater certainty
4. Easier to secure (can put behind a firewall with extra authentication etc.)
#### Disadvantages
1. Scalability and performance under large loads unclear - may end up spending c. £12k for a data centre license.
2. Flexibility to support long term requirements unclear - may be just a 'stop-gap'
### D. Bespoke application
Code a bespoke client UI (e.g. in AngularJS) that administers the doorman via direct calls to the API.
#### Advantages
1. Starting point for eventual strategic solution that meets precise onboarding process requirements
2. No flexibility issues
3. No performance issues (driven off doorman database)
4. Easier to secure (can put behind a firewall with extra authentication etc.)
#### Disadvantages
1. Extra development effort​
## Recommendation and justification
Proceed with Option <A or B or ... >

51
docs/source/design/doorman-admin-ui/design.md
View File

@ -37,34 +37,55 @@ HIGH LEVEL DESIGN
## Overview
General overall of design proposal (goal, objectives, simple outline)
This document describes the application and deployment design for an administrator UI.
## Background
Existing Doorman code provides for optional integration with a JIRA project, in which issues mirror CSRs and movement of an issue to an Approved status is used to trigger approval of the underlying CSR (and subsequent release of a signed certificate to the client node)
Issuance of a certificate by the Doorman in a production context requires human approval. A business process to support this, including performing relevant checks to validate the identity of the requester of a certificate, is being designed in parallel.
Whilst expedient as a near-term solution, the long-term practicality of JIRA (specifically, the JIRA instance provided by R3's corporate Atlassian account) for managing workflow has been questioned on grounds of:
Existing Doorman code provides for optional integration with a JIRA project, in which issues mirror CSRs and movement of an issue to an Approved status is used to trigger approval of the underlying CSR (and subsequent release of a signed certificate to the client node). Testnet and other non-production deployments to date have used a cloud-based JIRA deployment provided by R3's general-purpose company Atlassian account.
- **Scalability**: Unproven that a system in which every request raises a JIRA issue would prove resistant to volume-based attacks
- **Extensibility**: Current work to develop an ID verification process is surfacing various requirements to track meta-data around a CSR - specifically, evidence captured on the requester's identity, checks performed etc. with reference to a policy, and evidence of controls (e.g. 4-eyes checks and approvals) applied. Whilst it is potentially feasible to implement these features through JIRA customisation, the required flexibility has not been demonstrated.
- **Security**: Threat model around JIRA as a third-party, cloud-hosted application cannot be easily qualified. At a minimum, it may be assumed that Atlassian administrators would have both visibility and permissions to change statuses of JIRA stories, thus compromising the integrity of the certificate issuance process.
The suitability of using the R3 general Atlassian account, specifically, is questioned on security grounds:
- Every HTTPS request raises a JIRA issue. Significant volumes of HTTP requests may be trivially posted by a malicious attacker with knowledge of the doorman URL, generating a very large volume of JIRA issues. This would disrupt the CSR approvals process. More significantly, if the R3 cloud JIRA is used, it could significantly disrupt normal business operations for R3, which uses JIRA for team planning and organisation across both Platform and other teams.
A working assumption has been that the URL for the doorman will be kept secret and only shared with trusted parties (R3 partners and their customers who run Corda nodes). However, no controls (legal or otherwise) are proposed to prevent this URL from being leaked into the public domain.
For the same reason, automated load testing of the doorman's CSR submission endpoint is not currently possible.
Note: Evidence from the Atlassian website suggests that a single cloud JIRA instance is stable up to c. 200,000 issues, but they recommend splitting instances above this point, suggesting performance implications at that scale.
- The threat model around the Atlassian Cloud JIRA cannot be easily qualified. At a minimum, it may be assumed that Atlassian administrators would have both visibility and permissions to change statuses of JIRA stories, thus compromising the integrity of the certificate issuance process. Note that the final signing stage via HSM remains a control point protected by multi-factor
The suitability of JIRA is further questioned in relation to future requirements to support ID verification workflows. These workflows will be conceptually similar to (but significantly less complex than) Know-Your-Client (KYC) processes used by large financial institutions, in which a series of checks need to be performed on each onboarding request. Such KYC/AML applications generally model each of these checks as a discrete work item which needs to be tracked to completion and recorded; the set of checks required by each case is determined by conditional policy logic. The set of checks then sum to an approval Yes/No outcome for the overall case. It is not clear, at present, whether such logic and management of checks/issues could be effectively managed in JIRA, using plugins or otherwise.
Beyond this, requirements are anticipated to expose the progress of a given CSR to the requester who raised it, and to allow the requester to submit additional documentary evidence where needed to support ID verification checks. It is not clear how these requirements could also be met solely using JIRA.
## Scope
* To provide a mechanism for doorman operators to manage the approvals of CSRs in way which is fit for near-term purposes. This may involve third-party open-source or commercial components (e.g. JIRA) where appropriate.
* **Non-goal**: Develop a full bespoke end-to-end workflow solution equivalent to that used in financial institutions' KYC processes
### Goals
Provide an admin solution for the near-term pilot and production phases which:
- Does not expose R3 business operations to risk of significant disruption from a volume-based attack.
- Can be meaningfully load tested
### Non-Goals
Design a strategic end-to-end solution incorporating specialist ID verification workflows, progress reporting to external clients etc.
## Timeline
* Solution required before Feb 1
* Solution required before the pilot launch (April 26)
## Requirements
## Target Solution
* To be elaborated.
A private installation of JIRA will be deployed to R3's Azure cloud. This will be a dedicated JIRA instance solely for use by permissioned R3 doorman operators and DevOps administrators.
Access to the JIRA instance will be over a VPN to the R3 (Ldn/NY) office network. Outside an R3 office, doorman operators will require their own VPN connection in order to access the doorman JIRA. (Note that under the proposed scheme where smart card-authentication is used to control the final signing stage, the user needs to be physically present in either the London or New York office anyway, so remote working is not assumed as a key requirement for this process.)
## Design Decisions
## Final recommendation
| Heading | Recommendation |
| ---------------------------------------- | -------------- |
| [Near-term solution](decisions/near-term.md) | TBD |
- Proceed to Technical Design stage
## TECHNICAL DESIGN