Managing Roles and Permissions

By default, when a cluster A complete set of worker processes. Clusters require a fully functioning virtual node infrastructure. starts, the “super admin” REST user identity A login to the REST endpoint. Each login is associated with customizable permissions on the cluster and virtual nodes. is created, which has unrestricted access permissions. While this account can be used to perform any action, there is room for error if not used carefully. RBAC Role-based access control. Also known as role-based security. A permission system to restrict system access based on assigned permissions. permission templates enable you to create fine-grained roles for specific actions such as:

• A dedicated role which can create users, roles, and permissions and drive all the associations between them.
• A dedicated role with a set of all the necessary permissions to create a virtual node The combination of the context of a user and the ephemeral compute instances created to progress a transaction on that identity's behalf. (including CPI Corda Package Installer. A signed ZIP/JAR combination of a CPB and a Group Policy File that defines not only the application code that a virtual node will run, but also the details of the MGM with which to register, and the details of network PKI requirements. upload).
• A dedicated role which allows flows to run on this virtual node.

For information about creating these roles manually, see the Manual Bootstrapping section.

Querying Permissions via REST

To retrieve permissions matching certain query criteria, use the get_permission API call.

Checking Permissions When Starting Flows

Currently, Corda checks if a user can execute startFlow REST operations. No checks are made to whether the user can start a particular flow Communication between participants in an application network is peer-to-peer using flows. . These checks should be performed against the RBAC sub-system before passing the start request to a FlowWorker.