ウェブサイトの基本的な「許可」を設定したい。これは、ユーザーが特定のグループの一部であり、そのグループに許可されているすべての権限を取得する基本的な「役割」システムを備えています。ただし、特定の例外を許可したいので、基本的なRole
、Permission
、および_Role_Permission
_の設定だけでなく、特定のユーザーが追加の権限にアクセスできる場合があります(たとえ「ロール」のいずれにも付与されていません)。特定のユーザーは、「ロール」がアクセス権を持っていても、特定の権限を拒否される場合があります。基本的に、私は完全に柔軟でカスタマイズ可能でありながら、抽象化され、再利用可能であることを望みます。
これはテーブルの基本的なデザインです:
許可
PermissionID
PermissionName
役割
RoleID
RoleName
Role_Permission
PermissionID
RoleID
User_Role
ユーザーID
RoleID
特定のユーザーが特定の権限を許可/拒否できるように、「上書き」を許可する方法が必要です。 2つの個別のテーブルを作成する必要があります。1つは拒否された権限用で、もう1つは許可されたもの用ですか。または、単一のUser_Permissionテーブルを作成する必要がありますか?もしそうなら、それは許可/拒否または単一のフィールドのための2つの別々のフラグを持つべきですか?私はこのようなことを考えています:
User_Permission
(またはそれを呼び出す必要がありますPermissionException?PermissionOverride?)
ユーザーID
PermissionID
許可(ビットフラグ)
拒否(ビットフラグ)
(次に、このユーザーがアクションを実行する権限を持っているかどうかを判断するために呼び出されるSQLストアドプロシージャhasPermission(UserID, PermissionID)
を記述する予定です。)
これは良いデザインですか?それを改善できる方法はありますか?この一般的なデザインパターンの実装に使用される一般的な標準は何ですか?
セキュリティは、機能セキュリティとデータセキュリティの2つの観点から考えることができます。
機能的セキュリティ:これにより、Webサイトのさまざまな機能に対するアクセス制御が提供されます。これの最も単純な形式は、前述のとおり、ユーザー管理や製品管理などの単一の機能にマップされ、製品マネージャーやHRマネージャーなどのアプリケーションロールを作成するために集約された特権です。
データセキュリティ:
これにより、各機能付与で使用できるデータ(基本的に論理行)が制御されます。たとえば、部門ごとにユーザーの管理機能を制限する場合は、dept-data-securityロールを設定できます。このロールは、manage-userロールとともに、部門内のユーザー管理機能へのアクセス権をユーザーに提供します。
ユーザーに特権を直接付与したい場合、それは間違いなく厄介であり、集約の可能性を無効にします。ただし、ロールは実行時に常に特権に変換されるため、これを実装できます。不必要に別のレイヤーを作成するだけでなく、ユーザビリティの観点からも、管理がより複雑になります。