<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>RBAC on withdong02</title>
    <link>https://withdong02.top/tags/rbac/</link>
    <description>Recent content in RBAC on withdong02</description>
    <image>
      <title>withdong02</title>
      <url>https://withdong02.top/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</url>
      <link>https://withdong02.top/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</link>
    </image>
    <generator>Hugo</generator>
    <language>zh</language>
    <lastBuildDate>Mon, 16 Mar 2026 19:41:31 +0000</lastBuildDate>
    <atom:link href="https://withdong02.top/tags/rbac/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>权限模型</title>
      <link>https://withdong02.top/posts/%E6%9D%83%E9%99%90%E6%A8%A1%E5%9E%8B/</link>
      <pubDate>Mon, 16 Mar 2026 19:41:31 +0000</pubDate>
      <guid>https://withdong02.top/posts/%E6%9D%83%E9%99%90%E6%A8%A1%E5%9E%8B/</guid>
      <description>&lt;p&gt;常见的权限模型有两种：RBAC 和 ABAC。&lt;/p&gt;
&lt;h2 id=&#34;两种模型介绍&#34;&gt;两种模型介绍&lt;/h2&gt;
&lt;h3 id=&#34;rbac-模型&#34;&gt;RBAC 模型&lt;/h3&gt;
&lt;p&gt;Role-Based Access Control，翻译为基于角色的访问控制。角色拥有某些权限，通过赋予用户某种角色来达到给用户授予相关权限的目的，这就是基于角色。实现较简单。在一些大型组织中，角色可能爆炸式增长，导致管理复杂、权限冗余。&lt;/p&gt;
&lt;h3 id=&#34;abac-模型&#34;&gt;ABAC 模型&lt;/h3&gt;
&lt;p&gt;Attribute-Based Access Control，翻译为基于属性的访问控制，它比 RBAC 更加灵活，因为在 ABAC 模型中，一个操作是否被允许是基于&lt;strong&gt;对象、资源、操作和环境信息&lt;/strong&gt;共同动态计算决定的。它的控制更细粒度，比如它能实现“仅允许大学生在水课上睡觉”的控制。&lt;/p&gt;
&lt;h2 id=&#34;派聪明的权限控制&#34;&gt;派聪明的权限控制&lt;/h2&gt;
&lt;p&gt;派聪明的权限模型是改进版的 RBAC，或者说简化版的 ABAC。设计了 admin 和 user 两种角色，管理员拥有管理知识库，查看用户列表等权限，普通用户拥有查看私有知识库等权限。但单纯的 RBAC 有两种局限性：权限控制力度不够细和没办法基于数据属性做动态授权，所以添加了组织标签机制。&lt;/p&gt;
&lt;p&gt;在上传文件时，给每份文档标记上传者所属的标签，这样用户访问知识库，系统能够动态的基于当前用户的组织标签和文档的组织标签进行匹配过滤。从而实现更细粒度的数据隔离和动态授权。&lt;/p&gt;
&lt;p&gt;此外，派聪明还考虑到了多级组织，设计了组织标签树。比如有这样三个层级标签：总部、研发部、后端部。一个拥有后端部组织标签的员工可以访问研发部、总部这两个父组织的资料。我个人在这一部分绕了很久，总感觉设计反了，现在是这样理解的，抛弃父标签级别高，所以权力大的想法，这样想：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;父标签（如“总公司”）：它定义的是一个&lt;strong&gt;最基础、最通用&lt;/strong&gt;的权限范围。就像一张“员工卡”，让你能访问公司的基础公共资源。&lt;/li&gt;
&lt;li&gt;子标签（如“技术部”、“财务部”）：它在父标签的基础上，&lt;strong&gt;增加了更具体、更细分的权限&lt;/strong&gt;。就像一张“技术部员工卡”，它包含了“员工卡”的所有权限，还额外增加了进入技术部专属区域的权限。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;这就是派聪明中有关权限模块的设计。&lt;/p&gt;
&lt;h2 id=&#34;转转统一权限系统的设计与实现&#34;&gt;转转统一权限系统的设计与实现&lt;/h2&gt;
&lt;p&gt;经过分析，转转技术部门选择了基于 RBAC 模型来实现，但它也有所改动，在原有基础上，新增了给用户直接增加权限的能力，也就是说既可以给用户添加角色，也可以给用户直接添加权限。所以用户最终的权限为 所拥有角色带来的权限和用户独立配置的权限的并集。&lt;/p&gt;
&lt;p&gt;转转的技术文章里还从权限系统自身和具体业务系统两层设计了六种身份，这里不再多说。&lt;/p&gt;
&lt;p&gt;参考文章：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://paicoding.com/column/10/13&#34;&gt;✅派聪明 RAG用户管理模块设计方案 - 技术派 - Java技术社区 | RAG+Agent实战项目教程+AI助手&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://mp.weixin.qq.com/s/ONMuELjdHYa0yQceTj01Iw&#34;&gt;转转统一权限系统的设计与实现（设计篇）&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;</description>
    </item>
  </channel>
</rss>
