LightStep [đť‘Ą]PM Releases Role-based Access Control
April 10, 2018 | Daniela Miao & Katia Bazzi
We’re excited to release role-based access control for LightStep [x]PM, with support for three different levels of permissions.
Administrators have the highest level of access, with organization management privileges that include creating, editing, and deleting users, projects, and roles.
Members have full access to [x]PM’s core features, which include viewing end-to-end traces and customizing dashboards, alerts, and Streams, but they do not have organization management privileges.
Viewers have read-only access to [x]PM’s monitoring capabilities — perfect for onboarding new users to [x]PM without disrupting existing workflows.
For more detailed information, visit our documentation page and log in.
Role-based Access Control (RBAC) vs Attribute-based Access Control (ABAC)
When architecting access control for [x]PM, we evaluated existing industry-wide access control standards. The two frameworks we focused on were (1) Role-based Access Control (RBAC) and (2) Attribute-based Access Control (ABAC).
With RBAC, roles are created and sets of permissions for resources are assigned to each role, and users are granted one or more roles to receive access to these resources. For example, you can have a user that has the role “Member” which maps to a set of permissions like creating alerts, editing dashboards, etc. On the other hand, ABAC gives access to resources via attribute-based policies. ABAC policies are rules that evaluate access based on four sets of attributes including: subject attributes, resource attributes, action attributes, and environment attributes. For example, you could have a policy like “all users in engineering in San Francisco should have edit access to all dashboards.” Here, the subject attributes are {“group”: “engineering”, “region”: “San Francisco”}, the action attribute is {“action”: “edit”}, and the resource attribute is {“type”: “dashboard”}.
We decided RBAC was a better fit for [x]PM for the following reasons. First, the primary advantage of ABAC is the ability to support extremely fine-grained permissioning, which is overkill in our product as we have no need to control access based on specific user resources (e.g. Only employees in the HR Department who are located in New York can access this dashboard). In addition, ABAC makes it extremely difficult, if not impossible, to determine the permissions available for a particular user. Whereas with RBAC, it’s much easier to audit the set of users that have access to a given permission, and the list of permissions granted to a particular user. There is also less overall complexity with RBAC, because roles can be described by their names and are easier to visualize than policies. Lastly, the performance of authorization queries is better with RBAC, assuming the number of roles remains reasonable, because we don’t have to look up data required for a specified policy from multiple sources.
The major risk we found with RBAC was potential “role explosion”, which occurs when a huge number of roles are created to accomplish fine-grained authorization, resulting in slow lookup times and higher overall complexity. This risk is mitigated in our case, because currently our product only requires coarser-grained access control. In the end, the benefit of increased granularity provided by ABAC didn’t outweigh the cost of its increased complexity.
Mapping Roles to Permissions
Once we decided on using RBAC, the next question was how to map the list of available roles to authorization around our API access layer. One option was to assign API endpoints directly to each role, but this option was quickly ruled out because it would have left no room for us to extend our access control or API layer in the future. Tightly coupling the two means making changes to either would directly impact the other, a flexibility we did not want to lose.
We ended up going with a flexible permission model that introduces the concept of a “permission action”, which is an abstract, logical grouping of API endpoints. These permission actions are first-class citizens in our software architecture — all authorization systems communicate using them. Each API endpoint belongs to a permission action, and each role is assigned one or more permission actions.
The diagram above illustrates our RBAC data model where users have a many-to-many relationship with roles, and roles have a many-to-many relationship with permissions. Note that when performing an authorization check, we also confirm access to the API endpoint is permitted by checking the union of permission actions mapped to that user’s roles. This permissions model gives us the flexibility to support custom roles and extend our API layer in the future.
Try it out and share your feedback with us at support@lightstep.com.
Originally published at lightstep.com on April 10, 2018.
