タグ付けされた質問 「access-control」

私は、アクセス制御（認可）に関して、ロールとパーミッションの固有のトレードオフを理解しようとしています。 与えられたものから始めましょう：私たちのシステムでは、パーミッションはきめ細かいアクセス単位です（「リソースXの編集」、「ダッシュボードページへのアクセス」など）。役割は 1+権限のコレクションになります。ユーザーは 1+役割を持つことができます。これらの関係（ユーザー、ロール、権限）はすべてデータベースに保存され、必要に応じてその場で変更できます。 私の懸念： （1）アクセス制御のためにロールをチェックすることの「悪い」ところは何ですか？代わりにアクセス許可を確認することでどのような利点が得られますか？言い換えると、これらの2つのスニペットの違いは次のとおりです。 if(SecurityUtils.hasRole(user)) { // Grant them access to a feature } // vs. if(SecurityUtils.hasPermission(user)) { // Grant them access to a feature } そして： （2）このシナリオでは、ロールはどのような有用な価値を提供しますか？1つ以上のアクセス許可をユーザーに直接割り当てることはできませんか？ロールはどのような抽象化の具体的な価値を提供しますか（特定の例を挙げられますか）？

45 security  permissions  authorization  access-control  roles 

アプリケーション用にJavaで柔軟なACLフレームワークを作成しようとしています。 多くのACLフレームワークはルールのホワイトリストに基づいて構築されています。ルールはowner：action：resourceの形式です。例えば、 「ジョンはリソースFOOBAR-1を表示できます」 「MARYはリソースFOOBAR-1を表示できます」 「MARYはリソースFOOBAR-1を編集できます」 これは、ルールをデータベースに簡単にシリアル化/永続化できるため魅力的です。しかし、私のアプリケーションには複雑なビジネスロジックがあります。例えば、 「5年以上の年功歴を持つ部門1のすべてのユーザーは、リソースFOOBAR-1を表示できます。それ以外の場合は承認されません」 「部門2のすべてのユーザーは、日付が2016年3月15日以降であれば、リソースFOOBAR-2を表示できます。それ以外の場合は許可されません」 最初に考えたとき、このような無限に複雑なルールを処理できるデータベーススキーマを考案するのは悪夢です。したがって、コンパイルされたアプリケーションにそれらを「焼き付け」、ユーザーごとに評価し、評価の結果としてowner：action：resourceルールを生成する必要があるように思えます。 コンパイルされたアプリケーションにロジックを焼き付けないようにします。 そのため、私はルールを述語：action：resourceの形式で表現することを考えていました。ここで、述語はユーザーが許可されるかどうかを決定するブール式です。述語は、JavaのRhinoエンジンで評価できるJavaScript式の文字列になります。例えば、 return user.getDept() == 1 && user.seniority > 5; そうすることで、述部をデータベースに簡単に永続化できます。 これは賢いですか？これはずさんですか？これはギミックですか？これは過剰に設計されていますか？これは安全ですか（明らかに、JavaはRhinoエンジンをサンドボックス化できます）。

30 java  javascript  scripting  permissions  access-control 

私はAPI構造のWebアプリケーションを作成していますが、このアプリケーションには独自の仕事をしているさまざまなレイヤーがあります。 最初のレイヤーはユーザー入力を検証する検証レイヤーであり、検証に合格した場合は2番目のレイヤー（アクセス制御レイヤー）に移動します。そうでない場合はエラーメッセージを返します 2番目の層は、ユーザーが実行したいタスクを実行する許可を持っているかどうかを確認するアクセス制御です。ユーザーが許可を持っている場合、要求を次の層に移動します。 3番目のレイヤーは、アプリケーションのロジックがあるコントローラーレイヤーです。 私の質問は、アクセス制御の前に検証レイヤーを持つことはOKですか？ユーザーが許可されていないタスクを実行しようとしており、検証エラーメッセージを送信している場合はどうなりますか？ユーザーはリクエストをエンドポイントに送信し、検証レイヤーと話します。検証に合格すると、メッセージが表示されます。You can't access this! 私には奇妙に感じますが、このようにうまくいくのでしょうか、それともインフラストラクチャの他の選択肢は何でしょうか？

24 validation  web-api  access-control 

役割ベースのアクセス制御モデルに従って、システムでユーザーができることまたはできないことを制限しようとしています。 これまでのところ、次のエンティティがあります。 users-システムを使用する人。ここにユーザー名とパスワードがあります。 roles-ユーザーが持つことができる役割のコレクション。マネージャー、管理者などのリソースのような もの-ユーザーが操作できるもの。契約、ユーザー、契約草案などの 操作のように -ユーザーがリソースでできること。作成、読み取り、更新、削除など。 さて、このような関係があるダイアグラムでは、ここで疑問が浮上します。 操作（0 .. *）は リソース（0 .. *）に対して実行され、permissionsという名前のテーブルを生成し、操作とリソースを保存します。 許可テーブルは次のようになります（1行）： ID： 1、操作： create、リソース： contract。 どの意味許可する作成の契約を。 一部のリソースにはすべての種類の操作が含まれていない可能性があると感じているため、このようにしました。たとえば、契約を登録する場合、ユーザーはファイルをアップロードできますが、この操作はプロバイダーの登録には使用できません。 そのため、管理者がロールにアクセス許可を付与するときに、システムに登録されたすべての単一操作のリソースのリストはありません。 各リソースには、自分で実行できる独自の操作のコレクションがあると思います。 何かが理解できない場合は明確にすることができます。 これは、rbacを実装する正しい方法ですか？ 編集 つまり、操作とリソースを持つアクセス許可テーブルを使用することで、リソースを操作に関連付けるために2つの余分なテーブルがあります。また、私はちょうど行っている可能性のリソースが持っている権限の許可テーブルが権限を格納します。 しかし、その場合、管理者がリソースを割り当てたときに、一部のリソースには存在しないアクセス許可が表示されていた可能性があります。 だから私は、データベース設計の観点から、1つの列操作と別のリソースを持つこのテーブル権限が正しいかどうか知りたいですか？この状態が続くと問題が発生しますか？

15 database-design  authorization  permissions  access-control  roles 

ACLとRBACについて読んだとき、私はそれを簡単に理解しているようです-アセットへのアクセスが許可されているユーザー名またはロールがあります。また、それらを実装する方法も確認できます。 すなわち、この画像は、ACLとRBACの明確なビューを私に提供します（上に基づいてデータベーステーブルを設計し続けることができるように）：（ プレスブックの 画像提供） 私が苦労しているのはABACです。これまでに見つけたさまざまな画像は、手が波打ったり過度に複雑であったり、承認を行うサードパーティの外部エンティティの使用を提案したりしています。または、奇妙な属性の例を挙げてください。使用方法は完全にはわかりません。 開始例 それでは、実際の生活から始めましょう。たとえば、70〜200人の会社があるとします。そして、私が保護する資産は、さまざまなページがたくさんあるウェブサイトです。特定の人に特定の資産へのアクセスを許可したい。 たとえば、あるLeslieユーザーがと呼ばれるWebページにアクセスPrice ManagerできるようにしてTravel、そのページの価格グループの価格のみを管理できるようにしProduct、同じページのグループの価格は管理できないようにします。ABACを使用してこれをどのように実装しますか？ これまでのところ、私は、Leslieいくつかの属性（ただし、どの属性とこれらの属性は何か？）を割り当て、それらを格納するデータベーステーブルを作成できると思います。次に、これらの属性を調べ（LeslieRBACのように「役割」とは見なさない）エンジンを設計し、そこからページへのアクセスを許可するかどうかを決定します。そのエンジンはどのように見えますか？単純なif / elseブロックですか？他に何か？ レスリーが後で彼女の立場を変更し、誰かが彼女のアクセス権を変更する必要がある場合はどうなりますか？彼女がアクセス権を移動しProductて取り消す必要がある場合、どのように見えますTravelか？彼女はアクセスが取り消さにしている必要がある場合にどのようにコード化されませんPrice Manager完全にページとなり、もはやどちらへのアクセス権を持っているTravel、またはProduct？ 私の場合の資産は、言い換えれば、Price Managerであり、ユーザーはそのページのさまざまな価格グループ（Travel価格設定、Product価格設定など）にアクセスできます。 私が探しているのは、詳細を明確にするための、そして推測することなく立ち去って実装できる場所への実装に向けた、合理的に完全なロードマップです。つまり、概念的に完成したり、データベース構造などを視覚化できる具体的な例を示したりできます。 おまけ：ABACは、比較的小さな許可の必要性、つまり70〜200人を管理し、150〜450の資産にアクセスするための適切な方法ですか？代わりにACL / RBACを使用する方が良いでしょうか？

12 permissions  access-control  abac 

プライベートメソッドがプライベートデータにアクセスするためにパブリックルートを使用する必要があるのはいつですか？たとえば、この不変の「乗数」クラスがある場合（少し工夫されていると思います）。 class Multiplier { public: Multiplier(int a, int b) : a(a), b(b) { } int getA() const { return a; } int getB() const { return b; } int getProduct() const { /* ??? */ } private: int a, b; }; 実装できる方法は2つありますgetProduct。 int getProduct() const { return a * b; …

11 programming-practices  coding-style  access-control 

私は自分のインターフェース設計を見ていて、がアクセスしたいuserとを与えられた場合に、ロールベースのアクセス制御を実装するための最も「正しい」方法を決定するのに苦労しています。subjectuser 私が見る限り、3つのコアオプションがあります（4番目は最初の3つの粗野化、5番目は4番目の微調整です）。 がsubject持つ権限のリストを使用してをクエリしuserます-subject.allowAccess(user.getPermissionSet) に必要なuser権限のリストを使用してをクエリしsubjectます-user.hasPermissionTo(subject.getRequiredPermissions()) サードパーティにクエリを実行して、権限の共通部分を見つけます- accessController.doPermissionSetsIntersect(subject.permissionSet, user.getPermissionSet()) subject/のいずれかを照会しuser、「決定」をサードパーティのクラスに委任する 持ってuserアクセスしようとするとsubjectアクセスが許可されていない場合は、エラーをスローします 私はオプション4に傾いています- フィールドに操作を委託するための呼び出しをsubject含めるaccessControllerフィールドがありますsubject.userMayAccess(User user)。 class Subject { public function display(user) { if(!accessController.doPermissionSetsIntersect(this.permissionSet, user.getPermissionSet())) { display403(); //Or other.. eg, throw an error.. } } } ..しかし、これはさらに質問を引き起こします： accessControllerフィールド対静的クラスである必要があります。 必要がありますsubject 知っている必要とされるどのような権限は、それを表示することができますか？ 召喚に関して、知識の最小の原則はここでsubject.display()どこに作用しますか？呼び出し元はsubject.display()、アクセス制御が有効であることを知っている必要がありますか？（subject.display()最終的な「テンプレートメソッド」はどこにあるか） subject.display()アクセス制御を管理し、ユーザーが必要な権限を持っていない場合に例外をスローしますか？ この状況で何が「ベストプラクティス」と見なされますか？チェックを実行する責任は実際にどこで発生しますか？ これはどちらかと言えば実装に進む学術的な演習であるため、設計パターンへの参照をいただければ幸いです。

9 design  single-responsibility  access-control