タグ付けされた質問 「permissions」

質問で使用されている例では、最小限のデータを関数に渡し、ユーザーが管理者であるかどうかを判断するための最良の方法に触れています。一般的な答えは次のとおりです。 user.isAdmin() これにより、コメントが何度か繰り返され、何度も投票されました。 ユーザーは、管理者であるかどうかを決定するべきではありません。特権またはセキュリティシステムが必要です。クラスに密接に結合されているからといって、それをそのクラスの一部にすることは良い考えではありません。 私は答えた、 ユーザーは何も決定していません。ユーザーオブジェクト/テーブルには、各ユーザーに関するデータが格納されます。実際のユーザーは、自分に関するすべてを変更することはできません。 しかし、これは生産的ではありませんでした。明らかに、遠近法には根本的な違いがあり、それがコミュニケーションを難しくしています。誰かがuser.isAdmin（）が悪い理由を説明し、それが「正しく」行われたように見えるものの簡単なスケッチを描くことができますか？ 本当に、私はそれが保護するシステムからセキュリティを分離することの利点を見ることはできません。セキュリティに関するテキストには、セキュリティを最初からシステムに組み込む必要があり、開発、展開、保守、さらには寿命のあらゆる段階で考慮する必要があると書かれています。側面にボルトで固定できるものではありません。しかし、このコメントに対するこれまでの17の賛成票は、私が重要な何かを見逃していると言っています。

55 design  object-oriented-design  separation-of-concerns  permissions 

私は、アクセス制御（認可）に関して、ロールとパーミッションの固有のトレードオフを理解しようとしています。 与えられたものから始めましょう：私たちのシステムでは、パーミッションはきめ細かいアクセス単位です（「リソース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 

私は単語を思い出そうとしています。それは計算理論またはデータベース理論に関連していると思います。最も近い同義語はですatomicが、それは正確ではありません。基本的に、それは、連続して複数回実行された場合でも同じ結果を生成する一種の計算です。つまり、それ自体に副作用は発生しません。 具体的には、chmodコマンド（またはその他の権限に関連する操作）に関するStack Overflowの回答でこの言葉に出くわしました。 うまくいけば、それで十分です。ウィキペディアを突っ込んでも大した助けにはなりません。

38 terminology  permissions 

アプリケーション用に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 

モデルまたはコントローラーでユーザー許可チェックを行う必要がありますか？そして、誰が許可チェック、Userオブジェクト、またはUserManagementヘルパーを処理する必要がありますか？ それはどこで起こるべきですか？ コントローラーのチェックイン： class MyController { void performSomeAction() { if (user.hasRightPermissions()) { model.someAction(); } } ... コントローラーにチェックがあると、モデルをシンプルなアクションにするのに役立ち、すべてのロジックをコントローラーに保持できます。 モデルのチェックイン： class MyModel { void someAction() { if (user.hasRightPermissions()) { ... } } ... モデルにチェックを入れることにより、モデルを複雑にしますが、コントローラーで想定されていない操作をユーザーが誤って許可しないようにします。 そして誰によって？ 場所に落ち着いたら、誰がチェックするべきですか？ユーザー？ Class User { bool hasPermissions(int permissionMask) { ... } ... しかし、ユーザーがアクセスできる内容を知ることは、実際にはユーザーの責任ではないので、おそらくヘルパークラスでしょうか？ Class UserManagement { bool hasPermissions(User …

26 mvc  permissions 

私は、ドメイン駆動設計の原則を把握しようとする小さなアプリケーションに取り組んでいます。成功した場合、これは大規模プロジェクトのパイロットになる可能性があります。「Implementing Domain-Driven Design」（Vaughn Vernon著）を読み、同様のシンプルなディスカッションフォーラムを実装しようとしています。また、githubでIDDDサンプルをチェックアウトしました。私は自分のケースにアイデンティティとアクセスを採用するのに苦労しています。背景情報をいくつかご紹介します。 私は（願わくば）ユーザーとアクセス許可のロジックを分離する背後にある理由を理解しています。それはサポートドメインであり、異なる境界コンテキストです。 コアドメインには、ユーザーはなく、作成者、モデレーターのみが存在します。これらは、サービスを使用してIDおよびアクセスコンテキストにアクセスし、受信したユーザーオブジェクトをモデレーターに変換することによって作成されます。 ドメイン操作は、関連する役割をパラメーターとして呼び出します。例： ModeratePost( ..., moderator); ドメインオブジェクトのメソッドは、指定されたモデレーターインスタンスがnullでないかどうかを確認します（IDおよびアクセスコンテキストから要求されたユーザーがモデレーターロールを持っていない場合、モデレーターインスタンスはnullになります）。 ある場合には、投稿を変更する前に追加のチェックを行います： if (forum.IsModeratedby(moderator)) 私の質問は： 後者の場合、セキュリティの懸念がコアドメインに再び溶け込んでいないのですか？以前は、本は「誰が主題を投稿できるか、またはどのような条件で許可されていますか。フォーラムは著者が今それをしていることを知る必要があります」と述べていました。 本のロールベースの実装は非常に簡単です。モデレーターがコアドメインである場合、必要なときに現在のユーザーIDをモデレーターインスタンスまたはオーサーに変換しようとします。サービスは適切なインスタンスで応答するか、ユーザーに必要なロールがない場合はnullで応答します。ただし、これをより複雑なセキュリティモデルにどのように適合させることができるかわかりません。私がパイロットをしている現在のプロジェクトには、グループ、ACLなどのかなり複雑なモデルがあります。 「投稿はその所有者または編集者のみが編集する必要があります」のようにあまり複雑ではないルールでさえ、このアプローチは破綻しているように見えます。 IdentityOrAccessコンテキストにOwnerOrEditorインスタンスを要求することは適切ではないと感じ、コアドメインではますますセキュリティ関連のクラスになります。さらに、userIdだけでなく、保護されたリソースの識別子（投稿、フォーラムなどのID）をセキュリティコンテキストに渡す必要があります。 ） コアドメインへのアクセス許可を引き出し、ドメインオブジェクトのメソッドまたはサービスでそれらをチェックすることで、最終的には、セキュリティに関する懸念をドメインに混在させることになります。 セキュリティとアクセス許可がコアドメイン自体でない限り、これらのアクセス許可関連のものはコアドメインの一部であってはならないことをどこかで読みました（そしてそれに同意する傾向があります）。上記のような単純なルールは、セキュリティをコアドメインの一部にすることを正当化しますか？

16 domain-driven-design  authorization  permissions  implementations 

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

15 database-design  authorization  permissions  access-control  roles 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 安全でないパスワードを選択するユーザーの権利を制限することを考えています（長さによって決定されるパスワードの安全性、使用される文字の種類（大文字/小文字、数字、記号など）、および使用できるかどうか）レインボーテーブルにあります）、侵害された場合にアカウントが受ける損害を制限します。 このアイデアのアプリケーションはまだありませんが、フォーラムなどを書いています：1234をパスワードとして使用するユーザーは、投稿する前にキャプチャを入力するか、厳格なスパム対策の対象となる場合がありますコンテンツを拒否するタイムアウトまたはベイジアンフィルターとして。このフォーラムが非常に階層的であり、モデレーターまたは何らかの手段による「昇格」を許可する場合、これは、それらが特権を獲得するのを阻止するか、特権を持っていることを伝えますが、より安全なものに変更せずにそれらを行使させませんパスワード。 もちろん、これはセキュリティの唯一の尺度となることはできませんが、それ以外の場合は適切なセキュリティプラクティスの次にうまくいくかもしれません。 どう思いますか？これは無理をして、より重要なセキュリティ慣行からフォーカスを奪い取っているのでしょうか、それともリスクを制限し、ユーザーに安全なパスワードの使用を促す良い方法ですか？

13 security  passwords  authorization  risk  permissions 

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