IAM Enhancements

Last updated November 23, 2022 by [email protected]

This product note aims to capture and describe various desired enhancements to Orb's Identity and Access Management (IAM) features.

Table of contents

1. Support for Multiple Users
2. RBAC User Permissions
3. API Credentials
4. Single Sign On

Support for Multiple Users

User Story

As an organization using Orb, I want my Orb users to work with the same Orb components (agents, agent groups, policies, sinks) using unique identities and credentials, so that my staff can collaborate effectively and so that I can comply with my corporate security guidelines, manage individual user permissions and audit who is making changes in the system.

Discussion

1. Currently, each Orb account has a single unique login access (username/email and password). For organizations where multiple users need to manage common Orb components (agents, agent groups, policies, sinks) this effectively forces them to share login credentials, which is often in violation of serurity rules.
2. Using a single identity for managing components in an Orb account prevents adherence to the principle of least privilege, since permissions cannot be managed on an individual user basis.
3. This could be implemented in many different ways:
   1. by providing Orb users with access to Orb components in another Orb user's account
   2. by linking multiple Orb user accounts as belonging to a common group (organization/tenant), and providing access to all components across all user accounts
   3. by allowing the creation of additional user logins within an Orb user account
4. The preferred approach is to elevate the current Orb account to essentially become a tenant, where multiple users can be defined. This is a common and intuitive model and avoids the potential entanglements of users having access to multiple other user components.

RBAC User Permissions

User Story

As an Orb account administrator, I want to be able to manage what actions users can take on Orb components in my account, so that I can provide only as much access as necessary to each user (principle of least privilege) and reduce my security risks.

Discussion

1. Coarse grained role based permissions (RBAC) are probably sufficient today, though the case might come for attribute based permissions (ABAC) to control access to specific component instances in the future.
2. A minimal implementation could be limited to providing the following roles:
   1. Read-Only User: can only Read Orb components
   2. Operator: can CRUD any/all Orb component (except users)
   3. Administrator: can CRUD Orb users and tenant attributes
3. A more extensive implementation could provide roles based on Orb component types and REST API verbs:
   1. agents, agent groups, policies, datasets and sinks (users?)
   2. GET, POST, PUT, DELETE
4. RBAC user permissions should extend and apply to API credentials as well.

API Credentials

User Story

As a user building API automations, I want to be able to use (and manage) credentials when using the Orb API that are distinct from my login credentials, so that I can provide only as much access as necessary to automations and be able to identify who (or what) made any changes.

Discussion

1. This already exists today in the form of PERMANENT_TOKENs, though with limited management capabilities:
   1. API credentials should be a unique identity, distinct for the Orb account user
   2. API credentials should be revocable
   3. API credentials should have associated permissions

Single Sign On

User Story

As an Orb user, I want to be able to access Orb without being prompted for my credentials, so that I can use an existing third-party identity and access Orb seamlessly.

Discussion

1. Though applicable to both Orb and Orb.live, this feature is currently of interest mainly for Orb.live to enable streamlined authentication with the NetBox Cloud platform.