Contour support both built-in authentication and single sign-on (SSO) with SAML2.0.
- Built-in authentication: the default authentication method, all authentication details are stored on Contour server instance. Multi-factor authentication (MFA) is recommended to be enabled for built-in authentication to add extra layer of security.
- Single sign-on with SAML2.0: SAML is an XML-based standard for authentication and authorization. Contour Server can act as a service provider (SP) with your internal SAML identity provider (IdP).
Contour use Cookie-Based Authentication to keep track of active sessions after a user has been successfully authenticated at the login stage.
- The user's corporate email address is the username
- Minimum Length: 8 characters
- Complexity requirements: Must contain
- upper case letter, AND
- lower case letter, AND
- at least one number OR symbol
- Initial Admin Password setting: default password set in bootstrap configuration file, and mandatory activation
- New user password setting: new user activation token/link via email (1 week expiry period)
- Password Reset (Forgot Password):
- requires username validation
- requires MFA authentication
- password reset token/link via email (48 hour expiry)
- Account Lockout Threshold: 5 consecutive invalid login attempts
- Account Lockout Duration: N/A
- Account Unlock: use forgot password option
Contour uses soft token with Time-based One-Time Password (TOTP), as specified in RFC6238, for the MFA login authentication.
- Using TOTP instead of SMS or email, because there were incidents that SMS 2FA had been exploited. NIST states that SMS 2FA isn’t secure due to the fact that the phone may not always be in possession of the phone number, and because SMS messages can be intercepted and not delivered to the phone
- Algorithm: as specified in RFC6238
- Secret Key length: Strong with 160 bits (i.e. 32 characters).
- Time-step size: 30 seconds (i.e. OTP changes every 30 seconds)
All the below authenticators use the same algorithm for TOTP generation, which is specified in RFC6238. So they are inter compatible. Contour recommend Microsoft Authenticator for the security reason.
Single Sign-on (SSO)
Contour support single sign-on (SSO) with SAML2.0.
- Contour SP metadata can be configured and downloaded by superadmin
- Supported SAML bindings: HTTP redirect & HTTP post
- Web browser SSO profile: SP redirect request; IdP POST response
- Authentication: Contour redirects to IdP, fully delegated to IdP, on every login
- Authorisation: Contour authorises based on user’s IdP_Group_Membership (i.e. AD group), by mapping Contour_User_Role (admin, viewer, maker, checker, approver) to IdP_Group_Membership => requires “group_membership” claim in SAML assertion
- Upon successful authentication and authorisation, Contour constructs application-level session/cookie, with default timeout as 30mins (configurable) and absolute time-out 12 hour as per NIST recommendation.
- User deactivation/termination in IdP
- If in the middle of the user having active session on Contour, the existing active session will remain valid until session timeout as defined in Contour.
- User attributes that will be stored in Contour user_db
- Synchronised from IdP => required claims in SAML assertion
- username => unique user id
- display_name => for display on UI, and email greetings
- email_address => for email notifications
- Synchronised from IdP => required claims in SAML assertion
- Name identifier format: emailAddress
- User record creation/update in Contour user_db: upon every successful login
- Logout: Non-single logout, i.e. only the app-level session on Contour is terminated, not propagated (to other apps authenticated with the IdP)
Role Based Access Control (RBAC) is adopted in Contour for authorisation, with reference to Role-based Access Control.
- Session Timeout: 30 minutes
- Absolute Timeout: 12 hours
- Session Termination
- User logout, OR
- Session idle timeout, OR
- Absolute session timeout
- Concurrent Login: Disabled (i.e. a single account cannot be concurrently logged in from multiple IPs or multiple browsers under same IP)
On the Corda level, data is distributed on a need-to-know basis.
- Data is only sent to the participants involved in the transaction, on a transaction level, i.e not share to any other parties not part of the transaction.
- Non-validating Notary ensure it doesn't see the transaction data.
- BNO not involved in any business transaction, thus no access to the transaction data either.
Data in-transit are encrypted. All connections are protected by TLS, so no network level sniffing should be possible if deployed properly.
Data at-rest are encrypted. Database for Corda, and web server should be configured with transparent data at rest encryption or full disk encryption
Incorrect use of cryptography or using outdated algorithms can lead to hard to detect vulnerabilities.
Contour application is built on the TLS standard, encryption provided by the database and signing implemented in Corda.
Corda uses SHA256 as content-identifier of transactions and attachments so Contour does as well. The web server hashes user passwords using scrypt.
Corda enforces modern configuration of TLS on its P2P connections (version 1.2, only the modern ciphersuites). Establishing connection requires having a client certificate issued by the network's CA. Corda enables only the following two cipher suites for its P2P connections:
TLS should be enabled on all communications which are:
- (internal/external) User browser - Web server: HTTPS/TLS1.2
- (internal) Web server - Corda: RPC/SSL
- (external) Corda - peer Corda/Contour nodes: AMQP/TLS1.2
Corda uses the Ed25519 signature scheme by default for all transactions as well as network metadata (information registered and distributed by the network map service is signed). Public keys are managed using standard X509 certificates, issued by the network's CA.
Together with signatures, data updates are validated against contract requirements and the network's notary service enforces ordering of transactions to ensure ledger integrity across all participants.
Every official release of the CordApp is signed. We keep the private key on a physical token (YubiKey 4) protected by PIN.
In several scenarios, customers are able to upload attachments as supporting documents to transactions, for example, while creating a DC application, or submitting a presentation. Only PDF files are allowed to be uploaded.