Bạn đang sử dụng lược đồ xác thực và ủy quyền nào - và tại sao?

Question

Chúng tôi bắt đầu thiết kế toàn bộ các dịch vụ mới để tạo (WCF, ADO.NET Data Services, có thể trong đám mây tại một số điểm) và một câu hỏi bật lên là lược đồ xác thực và ủy quyền sử dụng - có khá một vài! Về cơ bản, chúng tôi cần có khả năng xác định người dùng (người thực và người dùng ứng dụng/dịch vụ "ảo) trên nhiều giao thức khác nhau - HTTP, HTTPS, TCP - và chúng tôi cần chỉ định cho họ ít nhất một loạt vai trò/quyền để xem dữ liệu nhất định và/hoặc thực hiện các hoạt động nhất định. Chúng tôi chắc chắn không thể sử dụng tư cách thành viên nhóm Windows - chúng tôi có nhiều người tiêu dùng bên ngoài dịch vụ của mình và chúng tôi không muốn thiết lập tài khoản miền trong miền nội bộ của mình cho tất cả mọi người trong số họ.

Vì vậy, có chủ yếu là ba lựa chọn, tôi nghĩ rằng:

1. Sử dụng hệ thống thành viên ASP.NET - tạo người dùng và gán vai trò có
2. Sử dụng AzMan (Authorization Manager) mà có vẻ là một chi tiết hơn, trưởng thành hơn, hệ thống phức tạp hơn (với người dùng, nhiệm vụ, nhóm - ba cấp độ, không chỉ sử dụng + vai trò)
3. cuộn của chúng tôi riêng

Trước hết - mà trong ba sẽ được khuyến cáo bạn mend? Tại sao?

Thứ hai - có nhiều tùy chọn hơn mà tôi bị thiếu không?

Cảm ơn mọi gợi ý, con trỏ, ý kiến!

Marc

PS: nhìn thấy những câu trả lời cho đến nay, tôi ngạc nhiên trước số lượng của folks bỏ phiếu cho lựa chọn # 3. Tôi đã nghĩ rằng MS sẽ có thể thiết kế một cái gì đó có thể tái sử dụng có thể xử lý tất cả các yêu cầu này ....

Answer 1

Trên thực tế, câu trả lời có lẽ là một sự kết hợp của 1 và 3.

Bạn có thể tận dụng lợi thế của rất nhiều các công cụ và tính năng mà khuôn khổ cung cấp cho bạn bằng cách viết một nhà cung cấp membership, role hoặc profile nếu các tùy chọn mặc định không hoàn toàn đi xa như bạn muốn.

Chúng tôi đã thực hiện điều đó trên một số trang web khách hàng - ví dụ: một trong số các khách hàng của chúng tôi có phần lớn người dùng được lưu trữ là người dùng Máy chủ thương mại và sử dụng hệ thống hồ sơ Máy chủ thương mại. để nói chuyện với những kho dữ liệu đó - một bài tập khá đơn giản.

---

Hầu hết mọi người có lẽ sẽ cho 3 vì sự cần thiết phải xác thực qua TCP thô - đây giới thiệu một lớp ngoài của tiêu chuẩn ASP.NET các nhà cung cấp thành viên.

Hầu hết những gì MS sản xuất là "ok" hoặc "đủ tốt", nhưng sẽ luôn có các trường hợp cạnh mà bạn muốn làm điều gì đó "không hoàn toàn chuẩn" nghĩa là bạn sẽ tự làm. Tôi đoán có một cái gì đó vượt ra ngoài "Cơ bản Auth" hoặc "Windows Auth" đó là đơn giản cho các nhà phát triển trung bình của bạn để hiểu, họ đã lựa chọn hợp lý của "cho phép chỉ cần xây dựng này cho web".

Nếu bạn xem xét nhiều cách bạn có thể xác thực đối với dịch vụ WCF, bạn sẽ thấy ý tôi là - là được thiết kế để xử lý các cơ chế truyền tải khác nhau và do đó phức tạp hơn nhiều.

Điều đó nói rằng, vai trò mặc định và nhà cung cấp hồ sơ khá hạn chế (vai trò: không có phân cấp, vì vậy bạn cần phải kiểm tra từng vai trò có thể hoặc chỉ định rõ ràng từng vai trò cho người dùng; giá trị tách biệt - không dễ dàng để tìm tất cả người dùng đã có bộ giá trị).

Answer 2

Ldap bất kỳ ai? Nó hoàn toàn miễn phí, cross-plaftorm, dễ sử dụng và quản lý từ xa, có các cầu nối với các lược đồ xác thực khác và các ràng buộc bằng nhiều ngôn ngữ mà bạn đã biết ...

Answer 3

Chúng tôi sử dụng (3). Trên thực tế đã giúp chúng ta trong một khung cảnh hội nhập để có các tài khoản đồng bộ với

1. quy trình kinh doanh
2. Các hệ thống khác (không phải tất cả trên stack cùng công nghệ (ASP.NET))

Answer 4

Không phải là AZMan từ năm 2003?

Tôi muốn giới thiệu 1 hoặc 3. Cá nhân tôi luôn đi cho 3. Có rất nhiều chức năng mà 1 mà tôi không sử dụng hoặc không quan tâm để sử dụng.

Answer 5

Tôi sẽ tránh xa AzMan. Chúng tôi đã đi xuống con đường đó một lần và không thích phần thị trấn mà chúng tôi chia tay. Chúng tôi luôn thực hiện đăng nhập dựa trên AD sử dụng SID của người dùng hiện tại để liên kết với người dùng trong cơ sở dữ liệu, sau đó lấy quyền từ đó. Với thiết lập của bạn, điều này có thể không thực hiện được (hoặc thực tế), nhưng tôi sẽ tránh xa AzMan trong mọi trường hợp.

Answer 6

Tôi không phải là nhà phát triển ASP hoặc .NET, nhưng ruột của tôi nói (3).Bạn thực sự không muốn một ứng dụng web công khai sử dụng bất kỳ loại quyền truy cập nào vào mạng công ty của bạn, ít có khả năng đặt thông tin đăng nhập auth ở bất kỳ đâu gần AD.

Answer 7

Bạn dường như cung cấp quá nhiều và quá mở rộng để dính vào một giải pháp công nghệ

Giải pháp 3.

tôi sẽ căn cứ toàn bộ ứng dụng xung quanh một lớp người dùng Bạn sẽ chỉ đơn giản là có để mô hình nó để rằng nó sẽ cung cấp cho bạn sự linh hoạt cần thiết và khả năng mở rộng

Cái gì như:

[ClassAttribute ("Yordan Georgiev", "1.0.2", "20090302", "20090415" , false)] 
public class User 
{ 
    #region DomainName 
    private string _DomainName; 
    public string DomainName 
    { 
     get { return _DomainName; } 
     set { _DomainName = value; } 
    } //eof property DomainName 


    #endregion DomainName 

    #region Status 
    private int _Status; 
    public int Status 
    { 
     get { return _Status; } 
     set { _Status = value; } 
    } //eof property Status 


    #endregion Status 

#region Password 
    private string _Password = Resources.GV.Pass; 
    public string Password 
    { 
     get { return _Password; } 
     set { 
      _Password = GenApp.Utils.Security.Encryptor.Encrypt (value, 
       GenApp.Conf.GenAppSettings.Instance.EncryptionAlgorithm); 
      //debug_Password = value; //unencrypted 
     } 
    } //eof property Password 


    #endregion Password 

#region ListUserRoles 
     private List<UserRole> _ListUserRoles; 
     public List<UserRole> ListUserRoles { get { return _ListUserRoles; } set  { _ListUserRoles = value; } } 
     #endregion ListUserRoles 


    #region UserSettings 
    private GenApp.Conf.UserSettings _UserSettings; 
    public GenApp.Conf.UserSettings UserSettings 
    { 
     get { 
      if (_UserSettings == null) 
       _UserSettings = (GenApp.Conf.UserSettings)GenApp.Conf.GenAppSettings.Instance; 

      return _UserSettings; 
     } 
     set { _UserSettings = value; } 
    } //eof property UserSettings 

}

Answer 8

Trong một dự án gần đây, chúng tôi đã mở rộng nhà cung cấp thành viên ASP.NET (đã viết nhà cung cấp tùy chỉnh) với mục đích sử dụng một số điều khiển dựa trên vai trò để quản lý quyền. Bây giờ dự án đã trưởng thành đầy đủ, chúng tôi thấy rằng các điều khiển không đủ linh hoạt cho các yêu cầu của chúng tôi, và ở một mức độ nào đó, chúng tôi đang hối hận khi đi xuống con đường thành viên MS. Lăn xác thực của riêng bạn nếu bạn có thời gian để kiến ​​trúc sư nó một cách chính xác sẽ là lựa chọn tốt nhất. Có vẻ như ứng dụng của bạn hơi giống một ứng dụng lai mà bạn đang phục vụ khách hàng nội bộ và bên ngoài, nhưng có lẽ cũng cân nhắc đến việc tích hợp OpenID cho khách hàng bên ngoài của bạn. Có một số điều khiển ASP.NET OpenID tuyệt vời mà thực sự làm cho việc xử lý các tài khoản mới cho các khách hàng bên ngoài không có trí tuệ.Điều này tất nhiên phụ thuộc vào cách 'công khai' ứng dụng của bạn.