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

Merge pull request #142 from corda/dl-design-admin-ui

Browse Source 
Approved by Mike H
This commit is contained in:
David Lee 2018-01-17 17:56:08 +00:00 committed by GitHub
commit 6733e74fcd
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 161 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
docs/source/design/doorman-admin-ui/decisions/near-term.md Normal file
View File

@ -0,0 +1,70 @@
![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
2. Higher potential for bugs and security vulnerabilities
3. Replication of workflow logic that already exists
4. Harder for business-side employees to change workflow or logic vs. JIRA
## Recommendation and justification
Proceed with Option C - Private JIRA installation

91
docs/source/design/doorman-admin-ui/design.md Normal file
View File

@ -0,0 +1,91 @@
![Corda](https://www.corda.net/wp-content/uploads/2016/11/fg005_corda_b.png)
# Design: Doorman Administration UI
DOCUMENT MANAGEMENT
---
## Document Control
| Title | Doorman Administration UI |
| -------------------- | ------------------------- |
| Date | 29/11/2017 |
| Author | David Lee |
| Distribution | TBD |
| Corda target version | N/A - Doorman |
| JIRA reference | ENT-1130 |
## Approvals
#### Document Sign-off
| Author | |
| ----------------- | ---------- |
| Reviewer(s) | Mike Hearn |
| Final approver(s) | Mike Hearn |
#### Design Decisions
| Description | Recommendation | Approval* |
| ---------------------------------------- | ------------------------------------ | ----------------------- |
| [Near-term solution](decisions/near-term.md) | Option C - Private JIRA installation | (Design Approval Board) |
HIGH LEVEL DESIGN
---
## Overview
This document describes the application and deployment design for an administrator UI.
## Background
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.
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.
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
### 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 the pilot launch (April 26)
## Target Solution
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.)
Note that a private installation of JIRA for 10 users (perpetual license) costs USD 10; 25 users costs USD 2,500.
## Final recommendation
- Proceed to DevOps implementation
##