RBAC Model

RBAC Model

The permission mechanism in snapblocs uses Role-based access control (RBAC) for restricting application features based on the roles of individual members within your account. 
For example, a power user role allows you to manage projects and stacks. But a general user role can manage stacks, but no projects. See here to set up RBAC.

Key RBAC Domain Objects
  • Groups: A group is a named collection of USERS and ROLES.
  • Roles: A role is a named collection of POLICIES
  • Policies: A set of PERMISSIONs that can be associated with a ROLE.
  • Permissions: A PERMISSION is a pair of attributes defined with a RESOURCE and an associated ACTION. This represents a UI function and the user's entitlement. Permissions form Policy statements through the combination of RESOURCES, EFFECTS, and ACTIONS:
  1. Permission Resources: A targeted feature, environment, or operation as expressed through the UI. i.e., user management
  2. Permission ACCESS: Two states, ALLOW of DENY. Permissions are additive; there are no deny permissions.
  3. Permission Actions: An entitlement associated with a RESOURCE. A resource can have many actions. Each RESOURCE has its own dedicated set of ACTIONS. These should have human-readable names that the user understands. i.e., delete, add, modify
Groups and Roles
  1. snapblocs comes with the default ROLES.
  2. In addition, USERS can define their own ROLES and assign them to a GROUP to control access for USERS.
Policy Rules
  1. By default, access for all ACTIONS on all RESOURCES is DENY.
  2. If permissions conflict within a policy, the most restrictive permission rule takes effect. This can be used to create exceptions.
  3. When two or more ROLES contain conflicting POLICIES are assigned to the same group, the least restrictive policy will apply.
Caution:
Adding a “Deny” policy for Access control to the Account admin role on the Access Control page of dpstudio could disable subsequent access. This is because a “Deny” policy supersedes all other “Allow” permissions for the Access Control.  All account members (including Root users, Admin users) would be prevented from reversing the deny policy for the Access control through the user interface. It would not prevent application login, and all other RBAC controls would be unaffected. To recover from this issue, please contact the snapblocs support team to remove the deny policy from the Account admin role and restore UI access to the RBAC admin control settings.



    • Related Articles

    • How to set up RBAC

      By setting RBAC properly, you can let your members have access rights only to the application features they need to do their jobs and prevents them from accessing other features that don't pertain to them. Note that you must be a member of the Role ...

    • Role Group Definition

      Pre-setup Roles & Policies by default for your account: Note that the actual roles and policies of your account may be different from this list. Check the Access Control page for the latest settings. Role Group Name Group Description Account admin ...

    • snapblocs vs. Other Integration Platform as a Service (iPaaS)

      Key benefits of snapblocs vs. other iPaaS solutions are: Decreases vendor lock-in Increases innovation and flexibility by swapping 3rd party components  Lowers TCO using open-source components Improves ROI using larger open community support (with ...

    • Add New User to snapblocs Account

      Anyone with an Account admin role (i.e., Account admin, Root admin) can manage users to a snapblocs account. See How to set up RBAC for Permissions and Roles of Root admin or Account admin. You can add as many users to a snapblocs account as you ...

    • Add Team User to Project

      Anyone with an Account admin role (i.e., Account admin, Root admin) can add team members to a project. See How to set up RBAC for setting permissions and roles. You can add as many team users to a project as you need to allow them to perform ...