大企業は、一元化され、ユーザーが実行できること (特定の Web サービスの呼び出し、注文の送信など) や UI (ボタン、メニュー オプション、個別の無効化など) を推進するために使用されるセキュリティ要件をどのように実装していますか?フォーム フィールド)?
RBAC アーキテクチャを検討しています: ユーザー -> 役割、役割 -> 特権。
多くの個々の field-account-user-role-amountThreshhold に基づく権限を持つ複雑なアプリケーションには、非常に多くの「役割」があり、役割の数が増えるにつれて、これの管理が複雑になります。
これらの考えられるすべてのオプションを管理するのは大変なことのように思えます。私の以前の経験では、そのようなロジックをアプリケーションにハードコーディングしていました。
元：If (User.Roles("IsAccounting"))
{
btnEditOrder.enabled = false;
}
私は、あらゆる/すべてのアプリケーション (すべて.NET、一部の GUI および一部のプロセス指向) の共通の認証/承認ポイントとして使用されるセキュリティ サービス/アーキテクチャの設計/実装を任されています。
これは、クライアント アカウントに関するビジネス組織と、金額に基づく権限階層のため、すぐに使用できるものではありません。
例: John はユーザーであり、アカウント "Microsoft" および "Google" の要求を表示および送信できます。Mike は "Microsoft" と "Google" の要求を表示できますが、"Google" の要求しか送信できません。
アカウント/ユーザーの数は多く、可変です。
RBAC に従うと、必要なすべての権利 (特権) に対応するために何百もの「役割」が存在することになります。管理者が直属の部下を適切な役割に割り当てることができるように、管理しやすい GUI ツールを提供することが最終目標であるため、これは役に立ちません。
私は、次の API を使用してこのセキュリティ ピースを実装することを考えていました (疑似コードのラフ ドラフト)。
UserContext securityContext = Security.GetContext(userID, userPwd);
アプリケーションでの使用法は次のようになります。
if (securityContext.RequestManager.CanSubmitRequest("Google")) {...}
このようにすると、パーミッションをチェックするための「Can(params)」メソッドが何千も存在することになり、このパターンの管理や使用が容易になりません。
リンク/アイデア/ポインタは大歓迎です。
これは .NET ショップですが、.NET (Membership / AzMan) からは、必要な粒度と委任の要件を提供してくれるものは何もありません。ActiveDirectory と Oracle LDAP の統合は便利ですが、必須ではありません。
古い (現在の) システムは LDAP を使用してユーザーを認証しますが、すべての承認は社内で行われ、従来の「ユーザー、ロール、権利」テーブルに保存されます。