RBAC（役割ベースのアクセス制御、役割ベースのアクセス制御）、すなわち、ユーザの役割と権限を関連付けることによって、です。簡単に言えば、ユーザーはいくつかの役割を持って、それぞれの役割は特権の数を持っています。ライセンスモデルこのように、それは「 - - 役割許可ユーザー」に設定されています。多くの関係に多くのある一般的な、役割と権限の間でユーザーとロールの間に、このモデルでは。（下記参照）
どのような役割？それは権利、特権キャリアの数の集合体として理解することができます。たとえば：フォーラムシステム、「スーパー管理者」、「司会者」の役割があります。モデレータは、バージョン管理で管理バージョン内でこれらの権限を投稿し、他のユーザーことができます。直接付与ユーザー権限なしに、「司会者が」この役割は、ユーザーに与えることができる、これらの権限を付与するユーザーを与えます。
ユーザーの非常に大きな数は、各ユーザーは、1つの（補助金の役割）によるシステム1を提供することを許可された場合、それは非常に面倒なことです。この場合、各ユーザは、グループ内の複数のユーザを有し、ユーザパケットに対して必要です。ユーザを認証することに加えて、ユーザは、さらに、グループを許可することができます。その結果、ユーザのすべての権利と特権を所有している、ユーザー自身のユーザー・グループの個々のユーザーの権限によって所有されます。（以下の図は、三のユーザグループ、ユーザの関連付けおよびロールを示します）
アプリケーションシステムでは、どのようにパフォーマンスの権利？機能モジュールの動作を、アップロードされたファイルの削除、メニューにアクセスし、ページ上でもボタン、視認性のコントロールの絵は、カテゴリの能力の範囲内に落ちることができます。「 - 役割 - 権限 - リソースユーザー」ライセンスモデルいくつかの権利のデザインは、操作が別のクラスとしてクラス、およびドキュメント、メニュー、およびその他のページ要素として、これが構成する機能します。モデリングデータテーブルを行うことで、機能動作と資源の統合管理が、それは、直接実施されることができ、テーブル上の権限に関連した、これはより便利で簡単なスケーラビリティかもしれません。（下記参照）
その許可テーブルが表すように「MENU」メニューへのアクセスを表現する、「OPERATION」は操作権限の機能モジュールを表し、「FILE」として、私たちの価値観に基づいて権限の種類を区別するためである、「右のタイプ」がありますのでご注意くださいファイルのパーミッションを変更し、「要素」ページなどの制御要素の可視性を表します。
这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。
这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。
到这里，RBAC权限模型的扩展模型的完整设计图如下：
随着系统的日益庞大，为了方便管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。
以上，是从基本的RBAC模型进行了扩展，具体的设计要根据项目业务的需要作调整。欢迎大家提出批评意见！