2012-01-31 18 views
5

Xin chào các bạn, chúng tôi đang xây dựng một ứng dụng ASP.NET MCV 3 từ đầu chạy trên Windows Azure. Về lớp xác thực và ủy quyền, chúng tôi đang nghĩ đến việc sử dụng dịch vụ kiểm soát truy cập. Tôi đã đi qua một số bài viết về ACS, nơi tôi có ý tưởng cơ bản nhưng tôi vẫn còn một số nghi ngờ về nó.Azure ACS - Thực hiện tốt nhất Thực hiện

Hiểu biết của tôi là sử dụng ACS, chúng tôi thuê ngoài một hoặc nhiều Nhà cung cấp nhận dạng (IP), về cơ bản chúng tôi tin tưởng một hệ thống khác (tức là Microsoft Live ID) để xác thực người dùng của mình. Quy trình cơ bản rất đơn giản: ở giai đoạn xác thực, chúng tôi chuyển hướng (ACS thực hiện) người dùng đến một trong các IP "đáng tin cậy" của chúng tôi, sẽ chuyển hướng người dùng (với mã thông báo hợp lệ) tới ACS và cuối cùng đến ứng dụng của chúng tôi. Ở đây có một số câu hỏi…

Vì chúng tôi không muốn tất cả người dùng có tài khoản Live ID có thể truy cập vào ứng dụng của chúng tôi, tôi cho rằng có một quy trình khác để xác thực người dùng đó và kiểm tra xem anh ấy có được đăng ký không trong ứng dụng của chúng tôi. Câu hỏi là ở đâu? Trong ACS hoặc trong ứng dụng của chúng tôi.?

Tôi có ý tưởng về điều này nhưng tôi không biết đó có phải là cách thích hợp để làm điều đó không: Ở giai đoạn đăng ký, hệ thống (ứng dụng web của chúng tôi.) Yêu cầu người dùng IP (tức là Live ID, Google, Facebook và ứng dụng của chúng tôi.) Anh ấy muốn sử dụng để xác thực mình trong ứng dụng. Sau đó, người dùng thực hiện quá trình xác thực trên hệ thống IP và khi quay lại, chúng tôi lưu trữ tên người dùng (tên người dùng IP) trong DB của chúng tôi. Vì vậy, vào lần tiếp theo, ở giai đoạn xác thực, chúng tôi có thể kiểm tra xem người dùng đó có được đăng ký trong hệ thống của chúng tôi hay không.

Nếu lý thuyết trên là chính xác, điều đó có nghĩa là trong ứng dụng của chúng tôi. chúng tôi cần xây dựng nhà cung cấp tư cách thành viên để lưu trữ tên người dùng đến từ các IP và người dùng đã chọn ứng dụng của chúng tôi. một ngụm. Tôi có đúng không? Thực tiễn tốt nhất để thiết kế quy trình trên là gì?

Bây giờ, hãy nói về Ủy quyền và “Vai trò”. Làm thế nào nó hoạt động với ACS? ACS có quản lý nhiều vai trò cho mỗi người dùng không?

Một lần nữa hiểu biết của tôi là với ACS bạn có thể tạo một số "nhóm quy tắc" có liên quan đến IP chứ không phải cho một người dùng. Nếu điều này là chính xác, làm thế nào để chúng tôi quản lý người dùng trong vai trò trong ứng dụng của chúng tôi? Ví dụ: Ví dụ: chúng tôi có nhiều vai trò và người dùng của chúng tôi có thể được liên kết với các vai trò đó, chúng tôi có thể sử dụng ASC để quản lý nó không?

Vì vậy, các câu hỏi cuối cùng là: Bản thân ACS có bao gồm toàn bộ quá trình Xác thực và Cấp phép không? Chúng tôi vẫn cần sử dụng Nhà cung cấp thành viên .net? Phương pháp hay nhất để đáp ứng các yêu cầu của chúng tôi là gì?

Rất cảm ơn sự đóng góp của bạn.

Trả lời

1

Quá trình xác thực người dùng được thực hiện với xác nhận quyền sở hữu.

Sau khi bạn thiết lập IP với ACS, khi người dùng xác thực, ACS sẽ nhận được xác nhận quyền sở hữu đối với người dùng được xác thực từ IP. Bạn cần định cấu hình các quy tắc trong ACS để nói những xác nhận quyền sở hữu nào bạn muốn được chuyển tiếp đến ứng dụng của mình. Bạn cũng có thể chuyển nhượng xác nhận quyền sở hữu thành các loại khác nhau, để bình thường hóa xác nhận quyền sở hữu được đặt thành đơn đăng ký của bạn mong đợi

Nếu bạn muốn thực hiện quyền truy cập dựa trên vai trò của mình với ACS, bạn có thể.Trong trường hợp này, vai trò chỉ là một yêu cầu khác mà ACS sẽ phát hành và bạn sẽ triển khai ứng dụng của mình để cấp đặc quyền người dùng dựa trên xác nhận quyền sở hữu vai trò mà ACS nhận được từ ACS.

Bạn có thể định cấu hình quy tắc ACS ánh xạ các xác nhận quyền sở hữu đầu vào IP nhất định cho xác nhận quyền sở hữu đầu ra vai trò. ACS cũng có một dịch vụ quản lý có thể thay đổi các quy tắc này để bạn có thể thực hiện quy trình đăng ký người dùng.

Quy tắc xác nhận quyền sở hữu cá nhân trong ACS liên quan đến nhà cung cấp danh tính đưa ra khiếu nại nhưng nhóm quy tắc thì không. Nhóm quy tắc liên kết với RP (ứng dụng của bạn). Nhóm quy tắc chỉ đơn giản là một nhóm quy tắc chuyển đổi xác nhận quyền sở hữu cho ACS: "đối với ứng dụng này, hãy áp dụng chính sách nhóm quy tắc này khi bạn phát hành mã thông báo".

Các tài liệu ACS có rất nhiều điều để nói về ACS cấu hình quy tắc khiếu nại, cả hai thông qua các cổng thông tin web và thông qua các dịch vụ quản lý ::

https://msdn.microsoft.com/library/azure/hh147631.aspx

phản ứng mở rộng:

Hãy nói rằng bạn đang sử dụng ACS để xác thực với một ứng dụng ASP.NET đang sử dụng WIF. Bạn sẽ định cấu hình ACS để đưa ra khiếu nại Vai trò của "Người quản lý" cho người dùng google bằng email "[email protected]".

Bây giờ trong ứng dụng ASP.NET của bạn, WIF sẽ thấy xác nhận quyền sở hữu vai trò này và nó sẽ cho phép bạn kiểm soát quyền truy cập bằng HttpContext.Current.User.IsInRole ("Manager") hoặc tương đương web.config.

Bạn có thể quản lý các quy tắc ACS này theo cách thủ công bằng giao diện người dùng web hoặc bạn có thể triển khai quy trình đăng ký để thêm các quy tắc như vậy vào ACS theo chương trình sử dụng dịch vụ quản lý ACS. Có một số mẫu dịch vụ quản lý ACS có sẵn tại acs.codeplex.com.

Ngoài ra, các bộ đào tạo phát triển bản sắc có một số ví dụ về WIF vai trò truy cập dựa trên:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14347

+0

Andrew cảm ơn rất nhiều vì câu trả lời của bạn. Vì vậy, về vai trò trong ACS tôi đã chính xác, về cơ bản chúng tôi không thể liên kết người dùng với vai trò, như chúng tôi có thể làm trong nhà cung cấp thành viên .net (UsersInRoles), nhưng chúng tôi có thể liên kết vai trò dựa trên IP. Còn ở giai đoạn đăng ký thì sao? Những gì chúng ta nên lưu trữ trong cơ sở dữ liệu của chúng tôi để nhận ra một người dùng (như là một phần của khách hàng của chúng tôi) ở giai đoạn xác thực? – Francesco

+0

Không, những gì tôi nói là bạn ** có thể ** liên kết người dùng với vai trò sử dụng ACS. Tôi đã mở rộng câu trả lời của tôi ở trên để đề cập đến điều này. –

9

Đối với một phần của câu hỏi về giai đoạn đăng ký, điều tốt nhất để sử dụng để xác định người dùng là NameIdentifier loại xác nhận quyền sở hữu

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier.

Điều này phải là duy nhất cho mỗi nhà cung cấp danh tính và cũng được khắc phục. Nếu bạn sử dụng xác nhận địa chỉ email, nó có thể thay đổi cho cùng một người dùng. Về mặt kỹ thuật nó có thể là có thể cho hai nhà cung cấp nhận dạng để sử dụng cùng một NameIdentifier (không ai trong số các out-of-the-box cái với ACS làm), do đó bạn có thể kết hợp yêu cầu bồi thường NameIdentifier với kiểu IdentityProvider tuyên bố

http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider

để đảm bảo tính duy nhất.

Về phần vai trò, tôi cho rằng việc sử dụng ACS để đưa ra xác nhận quyền sở hữu vai trò từ danh tính chung như Google sẽ rất khó quản lý bằng quy tắc chuyển đổi xác nhận quyền sở hữu trong ACS trên cơ sở người dùng. Bạn sẽ phải thêm quy tắc cho mỗi người dùng đã đăng ký - có thể không khả thi. Tôi nghĩ rằng các nhóm quy tắc ACS phù hợp hơn với việc chuyển đổi xác nhận quyền sở hữu vai trò (ví dụ: do ADFS liên kết cấp). Ý tưởng của bạn để làm điều đó trong ứng dụng của bạn là một IMHO tốt hơn. Trong mã, nơi để làm điều này bằng cách sử dụng WIF là trong một tùy chỉnh ClaimsAuthenticationManager.Bạn ghi đè phương thức Authenticate và dựa trên yêu cầu NameIdentifier từ nguyên tắc đến, bạn tra cứu trong kho dữ liệu thành viên của mình và tạo IClaimsPrinciple mới dựa trên vai trò trong DB thành viên của bạn (nghĩa là bạn thêm xác nhận quyền sở hữu vai trò cho từng vai trò người dùng trong).

Sau đó, bạn đưa ra quyết định ủy quyền của mình theo tùy chỉnh ClaimsAuthorizationManager. Có một số mẫu và thông tin tốt về điều này xung quanh trên web. Bạn có thể bắt đầu tại

http://msdn.microsoft.com/en-us/library/ee748497.aspx

Các vấn đề liên quan