Organization and Role-based access control

Organization and Role-based access control

https://blog.logto.io/organization-and-role-based-access-control

What is organization#

Organization definition#

The organization is a group of users(identities) and can represent the teams, business customers, and partner companies who can access your application.

Organization is particularly effective in business-to-business (B2B) settings. In contrast to individual consumers, business clients often consist of teams, organizations, or entire companies, rather than just one person. The introduction of an organization as an entity is important, as it not only groups users but also provides a context for tenant isolation in multi-tenant apps.

Organization use cases#

With this fundamental element, you can now build the must-have features for your B2B products:

• Build a multi-tenant architecture to isolate clients’ data and resources.
• Application access levels are defined by roles assigned to organization members.
• Provisioning members on an invitation and just-in-time basis.
• Organizations can each have a single sign-on (SSO) authentication experience.

 

 

ROBAC: Scalable Role and Organization Based Access Control

https://profsandhu.com/zhang/pub/roac.pdf

 

权限设计OBAC模型

https://github.com/aitec-cn/obac/

• 模型

  • 组织（organization）多层次组织。每个用户属于一个组织，每一个资源属于一个组织，一个用户可以访问同一个组织内的资源，并根据角色确定访问范围等级
  • 资源(resource) resource为数据资源， 如：订单信息、客户信息等，通过组织ID实现在不同组织层级的数据隔离。
  • 动作(action) action为对resource的操作权限,通过web路径来区分resource+action，如：创建、查看、修改、删除等。
  • 角色(role) role为组织下的角色，不同的user属于不同的role，role又是不同层级下的role，一个role可以覆盖多个resource，role可以对应多个action。
  • 作用域(scope) tenant、group、company、individual(user)等均为不同层级的组织作用域，组织的关系为树形结构。

• 实现

  • 创建一个action、resource、role、scope 四元组表，用于存储和判别某动作所需的组织角色和作用域（组织层级）。（对于简单的应用，把role加入到url path里，实现通过路径提取该action对应的四元组）
  • 默认所有action，在数据库操作层面都加入对应层级的org_id，以实现数据隔离。
  • 同一组织下，管理员可以忽略低层级的orgID,以实现对其他普通成员的数据操作。
  • 每一个请求的token里都需要携带多层级的org id（如tenantId GroupID companyId UsrId 等），role，userid 等，以确认是否满足权限判别。

 

 

常见的访问控制模型

https://blog.csdn.net/www_tlj/article/details/138140098

 本文介绍了五种常见的访问控制模型，包括自主访问控制（DAC）、强制访问控制（MAC）、基于角色的访问控制（RBAC）、基于属性的访问控制（ABAC）以及组织基于访问控制（OrBAC）。这些模型在不同场景下应用，是信息安全和合规性管理的关键组成部分。 

https://zhuanlan.zhihu.com/p/1897600877277202401

四种访问控制模型的比较

1. 关注点比较

2. 灵活性与复杂度比较

3. 典型应用场景对比

4. 优缺点总结

OBAC:

• 优点：对象中心化设计，支持细粒度控制，适合对象频繁变化的环境
• 缺点：不易扩展到大量用户，对象数量增加时管理复杂

RBAC:

• 优点：简单易理解，管理成本低，与组织结构契合度高
• 缺点：缺乏灵活性，难以处理特例，不支持上下文敏感的决策

TBAC:

• 优点：支持动态权限管理，上下文感知，适合工作流系统
• 缺点：实现复杂，仅适用于有明确任务流程的系统

ABAC:

• 优点：极高的灵活性和精细度，适应动态环境，支持复杂的访问策略
• 缺点：策略管理复杂，性能开销大，实现和维护成本高

七、混合模式与演进趋势

在实际应用中，很少有系统仅采用单一的访问控制模型。更常见的是将多种模型组合使用，以平衡安全性、灵活性和可管理性。

1. 常见混合模式

• RBAC+ABAC混合模式：使用RBAC作为基础框架，再通过ABAC提供细粒度的上下文控制
• RBAC+TBAC混合模式：角色定义基本权限集，任务状态决定权限的动态变化
• 多层次访问控制：不同安全级别的资源采用不同的访问控制模型

 

Implementing Organization-Based Access Control with Keycloak

https://dev.to/devaaai/implementing-organization-based-access-control-with-keycloak-42km

Summary of Recommended Approach

Component	Recommended Practice	Advantage
Realm	Single-realm	Simplified administration
Organizations	Groups (/orgs/{org_name})	Clear hierarchical organization
Roles	Scoped with org-prefix (acme_user)	Avoid role conflicts
Token Mappers	Group Membership & Script Mapper	Clear organization claims in tokens
Application Logic	JWT-based organization checks	Secure, clear authorization logic
Automation	Keycloak Admin API	Efficient onboarding and maintenance

---

 

 

Groups vs. Roles

https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/groups.html

In the IT world the concepts of Group and Role are often blurred and interchangeable. In Keycloak, Groups are just a collection of users that you can apply roles and attributes to in one place. Roles define a type of user and applications assign permission and access control to roles

Aren’t Composite Roles also similar to Groups? Logically they provide the same exact functionality, but the difference is conceptual. Composite roles should be used to apply the permission model to your set of services and applications. Groups should focus on collections of users and their roles in your organization. Use groups to manage users. Use composite roles to manage applications and services.

 

https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/roles/composite.html

Composite Roles

Any realm or client level role can be turned into a composite role. A composite role is a role that has one or more additional roles associated with it. When a composite role is mapped to the user, the user also gains the roles associated with that composite. This inheritance is recursive so any composite of composites also gets inherited.

To turn a regular role into a composite role, go to the role detail page and flip the Composite Role switch on.

Composite Role

Once you flip this switch the role selection UI will be displayed lower on the page and you’ll be able to associate realm level and client level roles to the composite you are creating. In this example, the employee realm-level role was associated with the developer composite role. Any user with the developer role will now also inherit the employee role too.

 

What is Azure role-based access control (Azure RBAC)?

https://learn.microsoft.com/en-us/azure/role-based-access-control/overview

Here are some examples of what you can do with Azure RBAC:

• Allow one user to manage virtual machines in a subscription and another user to manage virtual networks
• Allow a DBA group to manage SQL databases in a subscription
• Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets
• Allow an application to access all resources in a resource group