19

私は、開発中のWebフレームワークの一部としてアクセス制御システムを構築しているところです。私はそれを超柔軟で素晴らしいものにしたいと思っています。私のデザインに関する意見や洞察を提供することで私を助けてくれませんか?これが私のこれまでの仕事です(私の特定の質問は一番下にあります):

ユーザー

  • ユーザーにはユーザー名(32文字、スペースなし)とパスワードがあります
  • ユーザーには、確認が必要な1つ以上の電子メールアドレスがあります
  • ユーザーは、ユーザー名または任意の電子メールアドレスを使用してログインできます
  • ユーザーはゼロまたは多数のアカウントに関連付けられている可能性があります

アカウント

  • アカウントは1人以上のユーザーを表します
  • 各ユーザーは、アカウントに対して特定の権限または役割を持っている場合があります(たとえば、アカウント所有者または「新しいユーザーを追加できます」)
  • すべてのアカウントはアカウントタイプに関連付けられています

アカウントの種類

  • アカウントタイプには、ゼロまたは多数のアカウントタイプの役割があります
  • アカウントタイプには、ゼロまたは多くのアカウントタイプ機能があります

アカウントタイプの役割

  • 例:「所有者」、「管理者」、「パワーユーザー」、「ゲスト」など。
  • アカウントタイプの役割は、アカウントタイプの権限のコレクションです

アカウントタイプのアクセス許可

  • アカウントタイプのアクセス許可は、アプリケーションロジックが検証するシステム内の特定のアクションです。
  • それらは親を参照する可能性があるため、階層的にグループ化できます
  • 例えば:
    • 「ユーザー管理」
      • "ユーザーを追加する"
      • 「ユーザーの削除」
  • これらの権限は、アカウントタイプ機能専用の場合があります

アカウントタイプの機能

  • アカウントタイプの機能をアカウントでアクティブ化して、より多くの権限を付与することができます
  • 例:「スタンダードアカウント」または「プレミアムアカウント」
  • これらの機能をアカウントで有効にすると、アカウント所有者はシステムにアクセスしやすくなります
  • それらは、アクティブ化または非アクティブ化されたときに追跡され、定期的またはオンデマンドで請求できます

質問

アプリケーションロジックでユーザーアクションをチェックするための最良の方法は何ですか?私はユーザーのすべてのアクセス許可をセッションのオブジェクトに保存することを考えていました(アクセス許可を更新するにはログアウト/ログインが必要ですが、私はファンではありません-リアルタイムのアクセス許可管理に関するアイデアはありますか?):

{
  "All Permissions": {
    "User Management": {
        "Add User",
        "Delete User"
    },
    "Premium Account": {
        "Download Files",
        "Upload Files"
    },
  }
}

次に、システム内の特定のアクションに必要なアクセス許可を宣言します。多分次のようなものです:

Permission::require('Add User');

宣言されたアクセス許可がユーザーのアクセス許可オブジェクトにない場合、要求は失敗します。ただし、これはユーザーのアクションごとにやや強烈に思えます。また、権限の別のサブセットに「ユーザーの追加」という文字列がある場合はどうなりますか?

これについて助けてくれてありがとう!

4

9 に答える 9

12

アカウントの種類のアクセス許可を見ると、アクセス制御リスト (ACL) スタイルのシステム設計を念頭に置いているようです。

非常に柔軟で素晴らしいものにしたい場合は、これは良いデザインではないことをお勧めします. 単純なアクセス許可に対する ACL システムの作業 - そしておそらくそれはあなたのシナリオでは実際には問題ありません - しかし、アクセス許可を付与するためのルールが少しでも動的になるとすぐに - つまり、ユーザーの ID やロールを超えたコンテキスト データに依存するようになります - ACL の崩壊フラットファスト。

このビデオでは、ACL の失敗について詳しく説明し、実際の状況を考慮したアクセス制御を実装する別の方法について説明します。

また、これは以前にも行われています (ただし、私たちが確認できる実装は驚くほど少ないです)。おそらくRhino Securityを見てください。元のリンクhttp://ayende.com/Blog/category/548.aspxが壊れているため、参照用にインターネット アーカイブ リンクを保持します。

于 2010-08-13T21:57:30.183 に答える
4

私が気に入っている 1 つの方法は、一種の「カスケード」権限です。アクセス許可のコア セット (たとえば、読み取り、書き込み、削除) があり、それらをグループまたはユーザーに割り当てることができます。

READ    USER1
READ    USER2
WRITE   USER2
READ    USER3
WRITE   USER3
DELETE  USER3

または、ユーザー名の代わりに「グループ」を指定することもできます。

READ    SUBSCRIBER
READ    EDITOR
READ    ADMIN
WRITE   EDITOR
WRITE   ADMIN
DELETE  ADMIN
USER1   SUBSCRIBER
USER2   EDITOR
USER3   ADMIN

次に、テーブル内の値を使用して、レコードを並べ替えて検索するだけです。これにより、相互に排他的な権限を持つ複数のグループのメンバーになる柔軟性が得られます。

于 2010-08-13T21:25:11.673 に答える
3

これが私の2つの感覚です。

まず、この設計を開始するときは、OOP と、それがシステム内のエンティティにどのように適用されるかについて考えてください。ユーザー、User_Role、Roles、Role_Permissions、Accounts、Account_Types、Account_Type_Features など。

ユーザー: - 注目を集めている OpenID の使用を許可する必要があります - データベースの移植性のために ID または UUID を選択するオプション

ユーザーの役割: (アカウントの種類の役割ではありません) ここでは具体的に説明することをお勧めします。たとえば、パワー ユーザーと管理者の間の線引きはどこですか? 管理者と所有者の違いは何ですか? これらが明確に定義されている (ぼやけていない) 限り、機能します。ユーザーベースに疑問がある場合、すぐに役割と権限のセットが複雑になります。物事をきれいに保つために、これを最小限に抑えます。ユーザーは、与えられたものをどのように扱うかを理解します。さらに、これを USER TYPE ROLES に変更します。ロールは、アカウントではなくユーザーに適用する必要があります。

ROLE PERMISSIONS: (アカウントタイプのPERMISSIONSではありません) これはROLE PERMISSIONSに変更する必要があります。アクセス許可は、アカウントやユーザーではなく、ユーザー ロールに拡張されます。私の経験では、デザインが明確であればあるほど、後で混乱する余地が少なくなります。また、疫病のようにACLを避けてください。単純な 1 対 1 の関係にします。Web ベースのシステムに ACL を実装する理由をまだ見つけていません。他の許可ベースのシステムは、理解、保守、および使用がはるかに簡単です。問題を複雑にすることに意味はありません。

アカウントの種類の機能: アカウントの種類のアクセス許可とアカウントの種類の機能がわかりにくくならないように注意してください。最初の箇条書きでは、許可という言葉を使用しています。機能に変更します。アカウントの種類によって、より高度な/プレミアム機能が有効になります (アクセス許可ではありません)。

アクセス許可の管理: Web 上で実行されるステートレス アプリケーションの場合、セッションが最適です。利点は、ユーザーが許可されているかどうかを常に確認するために DB へのラウンドトリップがないことです。

Permission::require()ただし、セッションと同じパラメーター定義に従う必要があります。これにより、権限の他のサブセットの重複が防止されます。したがって、呼び出しは次のようPermission::require('User Management', 'Add User'); になります$_SESSION['All Permissions']['User Management']['Add User']

SIMPLE は BETTER であることを忘れないでください。

于 2010-08-18T03:54:53.923 に答える
3

アクセス許可については、Java システムを調べます。

http://download.oracle.com/javase/6/docs/api/java/security/Permission.html

「含意ロジック」を使用します。つまり、許可オブジェクトは、指定されたアクションが許可されるかどうか (つまり、許可がリソースへのアクセスを「意味する」かどうか) を決定するものです。BasicPermission には、パーミッション用の非常に単純な名前空間仕様があるため、チェックアウトすることもできます。あなたの例では、(CRUD命名法に従って)

  • user.create
  • user.delete
  • file.read
  • file.create

私たちの webapp では、要求できる各リソースまたは手順にアクセス許可を割り当て、各ユーザーに一連のアクセス許可を割り当てます。次に、

boolean isAuthorized = user.permissions.implies(requestedResource.permission); (標準カプセル化の暗示)

ユーザーがアクセスを許可されているかどうかを判断します。

于 2010-08-14T04:13:34.610 に答える
2

Zend Framework の Zend_Acl を調べることをお勧めします。ほとんどの Zend パッケージと同様に、学習曲線は急勾配です。しかし、リソース、アクション、役割の関係を完全に把握すると、独自の ACL 実装の非常に用途が広く強力な基盤になります。

既存の ACL パッケージとパターンを調査します。

于 2010-08-19T22:01:20.747 に答える
2

Zed Shaw は、ACL とその制限について興味深いことを述べています。このルートをさらに進む前に、必ず見る価値があります。

http://vimeo.com/2723800

于 2010-08-14T23:27:30.977 に答える
1

具体的なアドバイスはありませんが、非常に優れた柔軟なアクセス/許可システムを備えた私がよく知っている 2 つのシステムは、Drupal と Plone です。どちらかがどのように機能するかをコピーするよりも、はるかに悪いことをする可能性があります。彼らの背後には、何年にもわたる実世界でのテストがありました。

于 2010-08-13T22:09:24.950 に答える
0

ここを見て ください http://www.sqlrecipes.com/database_design/fine_grained_role_based_access_control_rbac_system-3/

概念は基本的に同じで、使いやすく、非常にきめ細かいアクセス制御がかなり高速です。

于 2011-05-27T10:50:11.513 に答える