メッセンジャーのバックエンドはGoで記述されているため、例はこの言語で作成されます。 車輪を再発明したくないので、XACMLを基礎として（ABAC（属性ベースのアクセス制御）の標準）を採用し、タスクに適したように可能な限り単純化することにしました。 私たちは、XACMLの独自の実装を作成するという目標を設定していないことに注意してください。 これは、必要なエクスペリエンスを抽出できる作業システムの例として採用されました。
XACMLとABACを探索するための素晴らしい記事がいくつかあります。
→ XACMLの紹介-属性ベースのアクセス制御の標準
→ アクセス制御アプローチ：RBAC vs. アバク
基本システムオブジェクトとAttributeCalculaterインターフェイス
AttributeCalculaterインターフェースについては、後でわかりますので、すぐに伝えてください。 実際、他の3つのインターフェイスで構成されていますが、簡潔にするために、すべてのメソッドを単に記述するように制限しています。 アクセスシステムと対話するアプリケーションモデルのすべてのオブジェクトによって実装する必要があります。
type AttributeCalculater interface { Counter() (AttributeCalculater, error) Equally(Getter) bool Belong(Getter) bool GetType() string GetValue() (AttributeCalculater, error) GetValueField(string) (AttributeCalculater, error) GetInt() (int, error) GetBool() (bool, error) GetString() (string, error) }
システムは、ルールとポリシーという2つの主なタイプのオブジェクトを使用します。 これで十分です。したがって、ポリシーのグループを不必要に使用しませんでした。
ルール
ルールは、ビジネスルールを記述するために使用されるシステム内で最も単純なオブジェクトです。 その構造は次のとおりです。
type rule struct { Name string Condition condition Effect ruleEffect } func (r *rule) calculate(cntx *Context) calculateResult {}
Calculateメソッドは、ルールを計算します。つまり、要求を実行できるかどうかを示す値を返すか、エラーを報告します。 これを行うには、コンテキストがメソッドに渡されます。このメソッドには、計算に必要なすべての情報が含まれています。
type Context struct { Object AttributeCalculater Subject AttributeCalculater Target Action }
コンテキストは、オブジェクト-AttributeCalculaterインターフェイスを実装し、アクセスシステムがいくつかのアクションを実行するエンティティ、サブジェクト-AttributeCalculaterインターフェイスもサポートし、通常はアプリケーションで特定のアクションを実行するユーザーであるエンティティで構成されます。 ターゲットは、アクセスシステムでサポートされるすべての可能なアクションをリストする列挙型です。 例：ユーザーを通信に追加する、メッセージを書く、通信管理者を指定するなど。
ルールの名前は、主にそれを操作する人のために必要です-計算プロセス自体には影響しません。
効果は、条件の計算結果がどのように処理されるかを示します。 効果は、許可（ permitEffect ）または拒否（ denyEffect ）です。 たとえば 、条件の評価結果がtrueで、効果がpermitEffectに設定されている場合 、ルールの評価結果もtrueになります 。 効果がdenyEffectとして登録されている場合、ルールの結果はfalseになります 。
条件 -ルールの最も重要な部分であり、実際には、その条件を説明および計算します。
type condition struct { FirstOperand Attribute SecondOperand Attribute Operator conditionOperator } func (c *condition) calculate(cntx *Context) (bool, error) {}
Calculateメソッドは、条件を計算します。 ルールに似たメソッドのように見えますが、戻り値のみが異なります。 条件は、真、不正確、またはエラーを報告する場合があります。
演算子は、2つのオペランドの比較方法を担当します。 以下の値を取ります。
- 均等 -オペランドが等しいかどうかをチェックします。
- notEqually-オペランドが等しいかどうかを確認します。
- 所属 -オペランド間に関係があるかどうかをチェックします。 特定のロジックは、AttributeCalculaterインターフェイスの実装に依存します。これは、アクセスシステムで動作するオブジェクトが実装する必要があります。 これについては、以下で詳しく説明します。
- notBelongは、 belongの反対です。
構造からわかるように、条件は2つのオペランドについてのみ計算できます。つまり、1つのルールでは、アクセスシステムを操作するときに発生する複雑なユースケースを考慮することは想定されていません。 このために、ルールの組み合わせが使用されます。
オペランドのデータ型は属性 （属性）です。 条件を計算するための情報が含まれています。
type Attribute struct { NameObject string Field string Type TypeAttribute Object AttributeCalculater } func (a *Attribute) getValue(c *Context) (AttributeCalculater, error) {}
getValueメソッドは、属性の値を返します。 AttributeCalculaterインターフェイスが実装されたオブジェクトとして返されます。
NameObject （オブジェクトの名前）。属性を計算するときに、Fieldフィールドから値を取得します。 オブジェクト自体は「 オブジェクト」フィールドにあります。
政治学
ポリシーは、1つ以上のルールでビジネスルールを記述するために使用されます。
type politic struct { Name string Target Action Rules []rule CombineAlgorithm combineAlgorithm } func (p *politic) calculate(cntx *Context) calculateResult {}
ポリシーの名前は、ルールと同様に、それを操作する人にのみ必要です。
Targer （ターゲット）は、ポリシーの検索に使用されます。 簡単にするために、このシステムでは、各目標に独自のポリシーがあります。
ルール -互いに補完する一連の単純なルールは、複雑なビジネスルールを記述することができます。
ルールのCombineAlgorithmは、ポリシールールの計算結果を処理する方法を示します。 XACMLでは、これらのアルゴリズムは非常に複雑になる可能性がありますが、この場合、これらのすべての喜びは必要ありません。 したがって、 permitIfAllPermitted （全員が許可する場合に許可する）とpermitIfOnePermitted （1つが許可する場合に許可する）の2つの単純なアルゴリズムしかありません。 たとえば、 permitIfAllPermittedアルゴリズムがインストールされている場合、ポリシーの計算結果は、このポリシー内のすべてのルールにも肯定的な結果がある場合にのみ肯定的です。
これらは、アクセスシステムを構成する主要な部分です。 次の記事では、これがどのように機能するかを詳しく見ていきます。