Thiết kế mô-đun xác thực người dùng (Vai trò & Quyền)


15

Tôi đang cố gắng mô hình hóa mô-đun Xác thực người dùng cho cơ sở dữ liệu MS SQL Server sẽ là phần cuối của Ứng dụng UI Delphi. Về cơ bản, tôi muốn có tài khoản người dùng trong đó người dùng chỉ thuộc về một nhóm. Một nhóm có thể có số "n" quyền.

Tôi cũng muốn thêm lịch sử mật khẩu vào cơ sở dữ liệu, vì người dùng sẽ được yêu cầu thay đổi mật khẩu dựa trên cài đặt ứng dụng (ví dụ: cứ sau 90 ngày).

Tôi cũng muốn đăng nhập một sự kiện cho mỗi lần người dùng đăng nhập và đăng xuất. Tôi có thể mở rộng điều này đến các sự kiện bổ sung trong tương lai.

Dưới đây bạn sẽ tìm thấy vết nứt đầu tiên của tôi tại nó. Xin vui lòng cho tôi biết bất kỳ đề xuất để cải thiện nó, vì đây là lần đầu tiên tôi làm điều này.

Bạn có thấy bất kỳ nhu cầu nào về các thuộc tính bổ sung cho bảo mật và ràng buộc dựa trên vai trò cho các quy tắc mật khẩu / thời gian hết hạn không?

thiết kế db


Một blog chi tiết có tại đây: goo.gl/ATnj6j
Suresh Kamrushi

1
Tôi không hiểu điều gì đó. Trong bảng người dùng, bạn có group_id. Một người có thể là thành viên của nhiều nhóm không?
johnny

Câu trả lời:


11

Dựa trên các yêu cầu đã nêu của bạn, mô hình của bạn có hình dạng khá tốt.

Dưới đây là một số gợi ý để cải thiện:

  • Bạn không nói quá rõ ràng, vì vậy thật khó để nói - nhưng có vẻ như bạn có thể đang lưu trữ mật khẩu người dùng trực tiếp. Điều này sẽ rất tệ! Nếu bạn nhìn vào cơ sở dữ liệu xác thực phổ biến, mật khẩu được lưu trữ ở dạng mã hóa. Bạn thường thấy cả passwordcột và password_saltcột.

  • USER_LOGSBảng của bạn có một Eventcột. Bạn không rõ làm thế nào để được cư trú. Có nên có một EVENT_TYPEbảng USER_LOGStham chiếu? Điều này có thể làm cho báo cáo thân thiện hơn. Các sự kiện tiêu biểu sẽ bao gồm đăng nhập, đăng xuất, thất bại mật khẩu, thay đổi mật khẩu, đặt lại mật khẩu, khóa, mở khóa, ...

  • GROUP_RIGHTSBảng của bạn không cho biết ai đã cấp quyền. Đối với mục đích theo dõi kiểm toán, mọi người thường giữ một bản ghi của những người đã thay đổi bản ghi và khi nào. Đó có thể không phải là một vấn đề cho bạn.

Dưới đây là một số câu hỏi xung quanh các yêu cầu kinh doanh đã nêu của bạn, khác với mẫu bảo mật dựa trên vai trò của "sách giáo khoa" theo một số cách:

  • Bạn có chắc chắn muốn người dùng chỉ ở trong một nhóm không? Ưu điểm của bảo mật dựa trên vai trò là các vai trò có xu hướng khá tĩnh, trong khi những người hoàn thành vai trò đến và đi khá thường xuyên. Bao gồm trong điều này là một số người thường "đội hai chiếc mũ".

  • Thiết kế của bạn là chỉ cấp. Một số hệ thống bao gồm cấp thu hồi . Điều này cho phép bạn nói rằng một quyền có sẵn rộng rãi không có sẵn cho một nhóm cụ thể.

  • Bạn có người dùng và tài khoản xuất hiện như USERStrong thiết kế của bạn. Thường có sự phân biệt giữa ngườiID người dùng . Một số ID người dùng dành cho nhóm hoặc máy và một số người có nhiều ID người dùng cho các mục đích khác nhau. Đây có phải là một sự khác biệt sẽ hữu ích cho bạn?


3

Tôi nghĩ toán tử bitwise là cách tốt nhất để thực hiện sự cho phép của người dùng. Ở đây tôi chỉ ra cách chúng ta có thể thực hiện nó với Mysql.

Dưới đây là bảng mẫu với một số dữ liệu mẫu:

Bảng 1 : Bảng quyền để lưu trữ tên cho phép cùng với nó giống như 1,2,4,8..vv (bội số của 2)

CREATE TABLE IF NOT EXISTS `permission` (
  `bit` int(11) NOT NULL,
  `name` varchar(50) NOT NULL,
  PRIMARY KEY (`bit`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Chèn một số dữ liệu mẫu vào bảng.

INSERT INTO `permission` (`bit`, `name`) VALUES
(1, 'User-Add'),
(2, 'User-Edit'),
(4, 'User-Delete'),
(8, 'User-View'),
(16, 'Blog-Add'),
(32, 'Blog-Edit'),
(64, 'Blog-Delete'),
(128, 'Blog-View');

Bảng 2 : Bảng người dùng để lưu trữ id người dùng, tên và vai trò. Vai trò sẽ được tính là tổng số quyền.
Ví dụ:
Nếu người dùng 'Ketan' có quyền 'Thêm người dùng' (bit = 1) và 'Blog-Xóa' (bit-64) thì vai trò sẽ là 65 (1 + 64).
Nếu người dùng 'Mehata' có sự cho phép của 'Blog-View' (bit = 128) và 'Xóa người dùng' (bit-4) thì vai trò sẽ là 132 (128 + 4).

CREATE TABLE IF NOT EXISTS `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL,
  `role` int(11) NOT NULL,
  `created_date` datetime NOT NULL
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1;

Dữ liệu mẫu-

INSERT INTO `user` (`id`, `name`, `role`, `created_date`)
   VALUES (NULL, 'Ketan', '65', '2013-01-09 00:00:00'),
   (NULL, 'Mehata', '132', '2013-01-09 00:00:00');

Quyền mã hóa của người dùng Sau khi đăng nhập nếu chúng tôi muốn tải quyền của người dùng hơn chúng tôi có thể truy vấn bên dưới để có được quyền:

SELECT permission.bit,permission.name  
   FROM user LEFT JOIN permission ON user.role & permission.bit
 WHERE user.id = 1

Ở đây user.role "&" allow.bit là toán tử Bitwise sẽ cho đầu ra là -

User-Add - 1
Blog-Delete - 64

Nếu chúng tôi muốn kiểm tra thời tiết, một người dùng cụ thể có cho phép người dùng chỉnh sửa hay không-

  SELECT * FROM `user` 
     WHERE role & (select bit from permission where name='user-edit')

Đầu ra = Không có hàng.

Bạn cũng có thể xem: http://goo.gl/ATnj6j


Và chúng ta sẽ làm gì nếu các quyền có nhiều, như 100?
ypercubeᵀᴹ

2
Bạn đã đăng 3 câu trả lời giống hệt nhau - cho các câu hỏi khác nhau! -, tất cả được đăng ngày hôm nay với một vài phút cách nhau. Đây không phải là thực hành tốt. Nếu bạn nghĩ rằng các câu hỏi giống hệt nhau hoặc tương tự nhau, bạn có thể bỏ phiếu để đóng chúng dưới dạng trùng lặp (hoặc gắn cờ nếu bạn không có tiếng để bỏ phiếu đóng).
ypercubeᵀᴹ

Ngoài ra, vui lòng chỉnh sửa liên kết của bạn và giải thích những gì nó có (chi tiết hơn, đó là blog của bạn hoặc của người khác, v.v.)
ypercubeᵀᴹ

Xin đừng sao chép và dán cùng một câu trả lời, phun nó lên một loạt các câu hỏi cũ. Nếu những câu hỏi đó giống nhau, đánh dấu chúng là trùng lặp.
Aaron Bertrand
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.