group 2.0.0-alpha1リリースノートにFlexible permissionsモジュールへの依存、Groupモジュールの分割について書かれている。Flexible permissionsモジュールページの書き出しには以下のようにある。
The Flexible permissions module allows you to gather, calculate and cache permissions from a myriad of sources. By virtue of a centralized permission checker service, it enables you to turn your website's access control layer into a Policy Based Access Control (PBAC).
Flexible permissionsモジュールは、無数のソースからパーミッションを収集、アクセス可否を判定し、判定結果をキャッシュすることを可能にする。このモジュールを利用することで、一元化されたパーミッション判定サービスにより、ウェブサイトのアクセスコントロールレイヤーをポリシーベースアクセスコントロール（PBAC）にできる。
PBACは何かということで調べてみると、諸般の定義はあるがNISTのABAC( "Guide to Attribute Based Access Control (ABAC) Definition and Considerations")とほぼ同義と考えて良さそうだ。その文書のP4に2. Understanding ABACという章があり、IBAC(Identity)→RBAC(Role)→ABACという進化の過程が説明されている。DrupalはRBACでユーザー(Identity)に管理者、認証ユーザー、未認証ユーザーといった役割(Role)を与え、コンテンツタイプ単位でアクセス制御を定義するモデルになっている。
このRBACモデルだと同じコンテンツタイプのコンテンツ(Instance)には同じアクセス権が設定されることになって、コンテンツごとのアクセス制御ができない。
Groupモジュールは、コンテンツをグループに登録させることで、そのグループに属するメンバー（ユーザー）のみがアクセスできるようにする。group 2.0.0-alpha1リリースノートには「The "finally doing things right" release - いよいよ正しくやるぞ版」と大げさなメッセージが書かれているが、Groupモジュールが本来実装すべきなのはコンテンツに対するABAC/PBACを実現することだと宣言していると読んでよいだろう。
"Guide to Attribute Based Access Control (ABAC) Definition and Considerations"のABACの基本シナリオの図説は以下のようになっている。
素のDrupalだと、Objectはコンテンツ、Subjectはユーザーとなる。Objectの属性は、コンテンツタイプと、オーナーと、公開属性で、Subjectの属性はRoleで、Access Control Policyは閲覧権、作成権、編集権、削除権、公開属性変更権でRole単位で、定義する。Groupモジュールを入れると、このObjectの属性、Subjectの属性双方にGroupを複数追加することができ、Group Type単位で、Access Control Policyを定義する形でアクセス権を制御する。個別のGroupはGroup Typeのインスタンスとなる。これにより、例えばある講座（Group）に登録済みの人（Group User）だけがアクセスできるコンテンツ（Group Content）を定義できるようになる。講座（Group Type）単位でAccess Control Policyを定義する。学部という別のGroup Typeが併存してもよい。
Groupモジュールは、Group Type毎にRBACを適用できる優れたモジュールだ。特定講座のコンテンツを特定学部のユーザーなら参照可能にするというような設定も可能だ。
ABACの例で良く出るのは、環境の話で、社内ネットからならアクセスできる、とか、営業時間帯だけアクセス可能にする、といったAccess Control Policyを実現したいというケースだ。Objectの属性に許可時間属性とか、許可ネットワーク属性などを設定でき、Access Control Policyの判断時にAndやOrの論理計算がルールとして定義できるのが望ましいということになる。
このABACのルールを記述できる言語XACML(eXtensible Access Control Markup Language)は既に存在していて、これに基づいたセキュリティソリューション製品も存在している。
Flexible permissionsモジュールをうまく育て、既存のRBACベースのパーミッションを切り出すことができれば、既存のアクセス制御の互換性は維持でき、新たなAccess Control Policyの導入がやりやすくなる。モジュールの説明でスポンサーを募っているが、難しいが意味のある成長だと思う。D11かD12のイニシアティブに入れてもよいのではないかと思う。
アクセス権制御は本当に難しいが、基盤がしっかりしていればビジネス要件を実現するのが容易になる。DrupalにはABAC/PBACはふさわしいと思う。