Các giải pháp lập trình CSharp- P65

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:10

Thêm vào BST

Báo xấu

72
lượt xem 11
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Các giải pháp lập trình CSharp- P65: Các giải pháp lập trình C# khảo sát chiều rộng của thư viện lớp .NET Framework và cung cấp giải pháp cụ thể cho các vấn đề thường gặp. Mỗi giải pháp được trình bày theo dạng “vấn đề/giải pháp” một cách ngắn gọn và kèm theo là các ví dụ mẫu.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Các giải pháp lập trình CSharp- P65

531 Chương 13: Bảo mật // Phương thức này tạo một miền ứng dụng mới để nạp và chạy mã lệnh // trong đó từ một publisher cụ thể. Đối số name chỉ định tên của // miền ứng dụng. Đối số certFile chỉ định tên của file chứa // một chứng chỉ X.509v3 cho publisher mà mã lệnh của nó sẽ // được chạy trong miền ứng dụng mới. private static AppDomain CreateAppDomain(string name, string certFile){ // Tạo một đối tượng X509Certificate mới từ chứng chỉ X.509v3 // nằm trong file được chỉ định. X509Certificate cert = X509Certificate.CreateFromCertFile(certFile); // Tạo chứng cứ Publisher mới từ đối tượng X509Certificate. Publisher publisherEvidence = new Publisher(cert); // Tạo một tập hợp Evidence mới. Evidence evidence = new Evidence(); // Thêm chứng cứ Publisher vào tập hợp Evidence. evidence.AddHost(publisherEvidence); // Tao môt miên ưng dung mơi vơi tâp hơp Evidence // chưa chưng cư Publisher va tra vê miên ưng dung // vưa đươc tao ra. return AppDomain.CreateDomain(name, evidence); } } 12. Xử lý bảo mật bộ thực thi bằng chính sách bảo mật của miền ứng dụng  Bạn cần kiểm soát (bằng mã lệnh) các quyền được cấp cho các assembly.  Cấu hình (bằng mã lệnh) chính sách bảo mật của miền ứng dụng mà bạn đã nạp các assembly vào đó.
532 Chương 13: Bảo mật Chính sách bảo mật (security policy) bao gồm bốn mức chính sách: công ty (enterprise), máy (machine), người dùng (user), và miền ứng dụng (application domain). Bộ thực thi quyết định những quyền nào để cấp cho một assembly bằng cách xác định tập quyền được cấp bởi mỗi mức chính sách rồi tính phép giao (phép AND luận lý) của bốn tập quyền. Các quyền nằm trong tập giao là grant-set cuối cùng của assembly.  Ngay cả khi các mức chính sách công ty, máy, hay người dùng chỉ định code group LevelFinal (chỉ thị bộ thực thi không đánh giá các mức chính sách thấp hơn), bộ thực thi luôn sử dụng mức chính sách của miền ứng dụng để tính grant- set của một assembly. Chỉ các mức chinh sách công ty, máy, và người dùng là được cấu hình tĩnh bằng Administrative Tools. Vì miền ứng dụng không tồn tại bên ngoài ngữ cảnh của bộ thực thi nên không thể cấu hình tĩnh chính sách miền ứng dụng được. Để cấu hình chính sách bảo mật của một miền ứng dụng, bạn phải tạo một mức chính sách (bằng mã lệnh) rồi gán nó cho miền ứng dụng. Xây dựng một mức chính sách bằng mã lệnh có thể là một công việc lâu dài, tùy thuộc vào độ phức tạp của chính sách bảo mật mà bạn cần diễn tả. Lớp System.Security.Policy.PolicyLevel mô tả một mức chính sách bảo mật. Bên trong mỗi đối tượng PolicyLevel, bạn phải tạo dựng một cấu trúc phân cấp các code group, định nghĩa các điều kiện thành viên, các tập quyền, và các đặc tính của mỗi code group. Có rất nhiều kiểu được sử dụng để tạo dựng mức chính sách, và thảo luận về các kiểu này là vượt quá phạm vi quyển sách này. Lập trình bảo mật .NET, như đã đề cập trước đây, cung cấp thông tin chi tiết về mỗi lớp này và trình bày cách xây dựng một mức chính sách bằng mã lệnh.  Thông thường, bạn sẽ phát triển một công cụ trợ giúp việc tạo một mức chính sách và ghi định nghĩa mức chính sách ra file; sau đó, bạn có thể nạp định nghĩa này từ đĩa khi cần. Lớp PolicyLevel có hai phương thức nhằm đơn giản hóa quá trình này: ToXml đưa một đối tượng PolicyLevel về dạng dễ lưu trữ, và FromXml xây dựng lại một đối tượng PolicyLevel từ dạng đã được lưu trữ. Một khi đã có đối tượng PolicyLevel mô tả chính sách bảo mật như mong muốn, bạn có thể gán nó cho một miền ứng dụng. Thu lấy tham chiếu System.AppDomain đến miền ứng dụng mà bạn muốn cấu hình, và truyền đối tượng PolicyLevel cho phương thức AppDomain.SetAppDomainPolicy. Mã lệnh của bạn phải có phần tử ControlDomainPolicy của SecurityPermission thì mới có thể gọi SetAppDomainPolicy. Bạn chỉ có thể gọi SetAppDomainPolicy một lần trên mỗi miền ứng dụng; nếu bạn gọi SetAppDomainPolicy lần thứ hai, nó sẽ ném ngoại lệ System.Security.Policy.PolicyException. Bạn không phải gán đối tượng PolicyLevel cho một miền ứng dụng trước khi nạp các assembly vào miền ứng dụng này. Các assembly được nạp trước khi bạn thiết lập chính sách bảo mật miền ứng dụng có các grant-set chỉ dựa trên các mức chính sách: công ty, máy, và người dùng. Chính sách miền ứng dụng chỉ áp dụng cho các assembly được nạp sau khi nó được cấu hình. Thông thường, bạn sử dụng khả năng này để nạp các assembly chia sẻ đáng- tin-cậy vào miền ứng dụng mà không bị ràng buộc bởi chính sách miền ứng dụng.
533 Chương 13: Bảo mật Ứng dụng dưới đây trình bày quá trình tạo một mức chính sách và gán nó cho một miền ứng dụng. Mức chính sách này cấp các quyền dựa trên publisher của một assembly—được thể hiện trong các khoản của chứng cứ System.Security.Policy.Publisher. using System; using System.Security; using System.Security.Policy; using System.Security.Cryptography.X509Certificates; public class AppDomainPolicyExample { public static void Main() { // Tạo một miền ứng dụng mới (để nạp các assembly vào đó). AppDomain domain = AppDomain.CreateDomain("modules"); // Nạp các assembly vào miền ứng dụng mà bạn không muốn // bị ràng buộc bởi chính sách bảo mật miền ứng dụng. § // Cấu hình chính sách bảo mật cho đối tượng AppDomain. SetDomainPolicy(domain); // Nạp các assembly vào miền ứng dụng được bảo vệ. § } // Phương thức này cấu hình chính sách bảo mật của đối tượng // AppDomain được truyền cho nó. Chính sách bảo mật sẽ gán các // quyền khác nhau cho mỗi assembly dựa trên publisher của // assembly. Những assembly từ các publisher vô danh không được // cấp quyền nào cả. private static void SetDomainPolicy(AppDomain domain) { // Tạo một PolicyLevel mới cho miền ứng dụng. PolicyLevel policy = PolicyLevel.CreateAppDomainLevel(); // Tạo một FirstMatchCodeGroup mới dùng làm nút gốc của hệ // thống phân cấp code group. Cấu hình group này sao cho
534 Chương 13: Bảo mật // nó trùng khớp với tất cả code. Điều này nghĩa là tất cả // các assembly đều khởi đầu với một grant-set rỗng cho // mức chính sách miền ứng dụng. policy.RootCodeGroup = new FirstMatchCodeGroup( new AllMembershipCondition(), new PolicyStatement(policy.GetNamedPermissionSet("Nothing")) ); // Tạo tập các code group để xác định các quyền nào sẽ được cấp // cho một assembly do một publisher tạo ra. Vì code group gốc // là một FirstMatchCodeGroup, nên quá trình phân giải chính sách // chỉ so trùng assembly trên các group con cho đến khi tìm thấy // trùng khớp đầu tiên. Mỗi code group được tạo với đặc tính // Exclusive để bảo đảm rằng assembly không lấy thêm quyền // nào từ các code group khác. // Tạo code group cấp tập quyền FullTrust cho các // assembly được phát hành bởi Microsoft. X509Certificate microsoftCert = X509Certificate.CreateFromCertFile("microsoft.cer"); policy.RootCodeGroup.AddChild(new UnionCodeGroup( new PublisherMembershipCondition(microsoftCert), new PolicyStatement(policy.GetNamedPermissionSet("FullTrust"), PolicyStatementAttribute.Exclusive) )); // Tạo code group cấp tập quyền Internet cho các // assembly được phát hành bởi Litware, Inc. X509Certificate litwareCert = X509Certificate.CreateFromCertFile("litware.cer"); policy.RootCodeGroup.AddChild(new UnionCodeGroup( new PublisherMembershipCondition(litwareCert), new PolicyStatement(policy.GetNamedPermissionSet("Internet"), PolicyStatementAttribute.Exclusive)
535 Chương 13: Bảo mật )); // Tạo code group cấp tập quyền Execution cho các // assembly được phát hành bởi Fabrikam, Inc. X509Certificate fabrikamCert = X509Certificate.CreateFromCertFile("fabrikam.cer"); policy.RootCodeGroup.AddChild(new UnionCodeGroup( new PublisherMembershipCondition(fabrikamCert), new PolicyStatement(policy.GetNamedPermissionSet("Execution"), PolicyStatementAttribute.Exclusive) )); // Thêm một code group sau cùng để bắt tất cả các assembly // không khớp với publisher nào. Gán group này với tập quyền // Nothing. Vì group này là Exclusive nên assembly sẽ không // nhận quyền nào từ các group khác, ngay cả từ các // mức chính sách cao hơn (công ty, máy, và người dùng). policy.RootCodeGroup.AddChild(new UnionCodeGroup( new AllMembershipCondition(), new PolicyStatement(policy.GetNamedPermissionSet("Nothing"), PolicyStatementAttribute.Exclusive) )); // Gán chính sách cho miền ứng dụng. domain.SetAppDomainPolicy(policy); } } 13. Xác định người dùng hiện hành có là thành viên của một nhóm Windows nào đó hay không  Bạn cần xác định người dùng hiện hành của ứng dụng có phải là thành viên của một nhóm người dùng Windows nào đó hay không.  Thu lấy đối tượng System.Security.Principal.WindowsIdentity mô tả người dùng hiện hành bằng phương thức tĩnh WindowsIdentity.GetCurrent. Kế tiếp, truyền đối tượng WindowsIdentity cho phương thức khởi dựng của lớp System.Security.Principal.WindowsPrincipal để thu lấy đối tượng
536 Chương 13: Bảo mật WindowsPrincipal. Cuối cùng, gọi phương thức IsInRole của đối tượng WindowsPrincipal để xác định người dùng này có nằm trong một nhóm Windows nào đó hay không. Cơ chế RBS của .NET Framework trừu tượng hóa các tính năng bảo mật dựa-trên-người-dùng của hệ điều hành nằm dưới thông qua hai giao diện chính sau đây: • System.Security.Principal.IIdentity • System.Security.Principal.IPrincipal Giao diện IIdentity mô tả thực thể mà mã lệnh hiện đang chạy trên danh nghĩa của thực thể này, chẳng hạn một người dùng hoặc tài khoản dịch vụ (service account). Giao diện IPrincipal mô tả IIdentity của thực thể và tập các vai trò mà thực thể này thuộc về. Một vai trò chỉ là một sự phân loại, dùng để nhóm các thực thể với các khả năng bảo mật tương tự nhau, chẳng hạn một nhóm người dùng Windows. Để tích hợp RBS với bảo mật người dùng Windows, .NET Framework cung cấp hai lớp sau đây (hiện thực giao diện IIdentity và IPrincipal): • System.Security.Principal.WindowsIdentity • System.Security.Principal.WindowsPrincipal Lớp WindowsIdentity hiện thực giao diện IIdentity và mô tả một người dùng Windows. Lớp WindowsPrincipal hiện thực IPrincipal và mô tả tập các nhóm Windows mà người dùng này thuộc về. Vì .NET RBS là một giải pháp chung được thiết kế sao cho độc lập nền, bạn không thể truy xuất các tính năng và các khả năng của tài khoản người dùng Windows thông qua giao diện IIdentity và IPrincipal, bạn phải sử dụng trực tiếp các đối tượng WindowsIdentity và WindowsPrincipal. Để xác định người dùng hiện hành có phải là thành viên của một nhóm Windows nào đó hay không, trước tiên bạn phải gọi phương thức tĩnh WindowsIdentity.GetCurrent. Phương thức này trả về một đối tượng WindowsIdentity mô tả người dùng Windows mà tiểu trình hiện đang chạy trên danh nghĩa của người dùng này. Kế tiếp, tạo một đối tượng WindowsPrincipal mới và truyền đối tượng WindowsIdentity cho phương thức khởi dựng. Cuối cùng, gọi phương thức IsInRole của đối tượng WindowsPrincipal để kiểm tra xem người dùng này có nằm trong một nhóm (vai trò) cụ thể nào đó hay không. IsInRole trả về true nếu người dùng này là thành viên của nhóm đã được chỉ định, ngược lại trả về false.  Bạn có thể thu lấy tham chiếu IPrincipal đến một đối tượng WindowsPrincipal bằng thuộc tính tĩnh CurrentPrincipal của lớp System.Threading.Thread. Tuy nhiên, kỹ thuật này tùy thuộc vào cấu hình chính sách principal của miền ứng dụng hiện hành; mục 13.14 sẽ thảo luận vấn đề này chi tiết hơn. Phương thức IsInRole có ba phiên bản nạp chồng: • Phiên bản thứ nhất nhận một chuỗi chứa tên của nhóm cần kiểm tra. Tên nhóm phải có dạng [DomainName]\[GroupName] đối với các nhóm dựa-trên-miền và phải có dạng [MachineName]\[GroupName] đối với các nhóm được định nghĩa cục bộ. Nếu muốn kiểm
537 Chương 13: Bảo mật tra tư cách thành viên của một nhóm Windows chuẩn, bạn hãy sử dụng dạng BUILTIN\[GroupName]. IsInRole thực hiện kiểm tra có phân biệt chữ hoa-thường đối với tên nhóm được chỉ định. • Phiên bản thứ hai nhận một số nguyên (int), số này chỉ định một Windows Role Identifier (RID). RID cung cấp một cơ chế để nhận biết các nhóm, không phụ thuộc vào ngôn ngữ (language) và sự bản địa hóa (localization). • Phiên bản thứ ba nhận mộtthành viên thuộc kiểu liệt kê System.Security.Principal.WindowsBuiltInRole. Kiểu liệt kê này định nghĩa các thành viên mô tả các nhóm Windows có sẵn. Bảng 13.3 liệt kê tên, RID, và giá trị WindowsBuiltInRole cho mỗi nhóm Windows chuẩn. Bảng 13.3 Tên, RID, và giá trị WindowsBuiltInRole của các tài khoản có sẵn Tên tài khoản RID (Hex) Giá trị WindowsBuiltInRole BUILTIN\Account Operators 0x224 AccountOperator BUILTIN\Administrators 0x220 Administrator BUILTIN\Backup Operators 0x227 BackupOperator BUILTIN\Guests 0x222 Guest BUILTIN\Power Users 0x223 PowerUser BUILTIN\Print Operators 0x226 PrintOperator BUILTIN\Replicators 0x228 Replicator BUILTIN\Server Operators 0x225 SystemOperator BUILTIN\Users 0x221 User [  Lớp WindowsIdentity cung cấp các phương thức khởi dựng nạp chồng cho phép bạn thu lấy đối tượng WindowsIdentity mô tả một người dùng nào đó (khi chạy trên Microsoft Windows Server 2003 trở về sau). Bạn có thể sử dụng đối tượng này và phương pháp được mô tả trong mục này để xác định xem người dùng đó có phải là thành viên của một nhóm Windows nào đó hay không. Nếu bạn sử dụng một trong các phương thức khởi dựng này khi chạy trên một phiên bản Windows cũ, nó sẽ ném ngoại lệ System.ArgumentException. Trên các nền Windows trước Windows Server 2003, bạn phải sử dụng mã lệnh nguyên sinh (native code) để thu lấy Windows access token mô tả người dùng cần thiết. Kế đó, bạn có thể sử dụng access token này để tạo đối tượng WindowsIdentity; mục 13.15 sẽ trình bày cách thu lấy Windows access token cho những người dùng cụ thể. Ứng dụng WindowsGroupExample dưới đây trình bày cách kiểm tra người dùng hiện hành có là thành viên của một tập các nhóm Windows được nêu tên hay không. Các nhóm này được chỉ định trong các đối số dòng lệnh; bạn nhớ đặt tên máy tính, tên miền, hay BUILTIN (đối với các nhóm Windows chuẩn) vào trước tên nhóm.
538 Chương 13: Bảo mật using System; using System.Security.Principal; public class WindowsGroupExample { public static void Main (string[] args) { // Thu lấy đối tượng WindowsIdentity // mô tả người dùng hiện hành. WindowsIdentity identity = WindowsIdentity.GetCurrent(); // Tạo đối tượng WindowsPrincipal mô tả các khả năng bảo mật // của đối tượng WindowsIdentity được chỉ định. WindowsPrincipal principal = new WindowsPrincipal(identity); // Duyệt qua các đối số dòng lệnh (tên nhóm) và kiểm tra xem // người dùng hiện hành có là thành viên của mỗi nhóm hay không. foreach (string role in args) { Console.WriteLine("Is {0} a member of {1}? = {2}", identity.Name, role, principal.IsInRole(role)); } } } Nếu bạn chạy ví dụ này với tư cách người dùng có tên là nnbphuong81 trên một máy tính có tên là MACHINE bằng lệnh WindowsGroupExample BUILTIN\Administrators BUILTIN\Users MACHINE\Accountants, kết xuất có thể như sau: Is MACHINE\nnbphuong81 a member of BUILTIN\Administrators? = False Is MACHINE\nnbphuong81 a member of BUILTIN\Users? = True Is MACHINE\nnbphuong81 a member of MACHINE\Accountants? = True 14. Hạn chế những người dùng nào đó thực thi mã lệnh của bạn  Bạn cần hạn chế những người dùng nào đó truy xuất các phần tử trong mã lệnh của bạn dựa trên tên người dùng hay các vai trò mà người dùng này là thành viên.
539 Chương 13: Bảo mật  Sử dụng lớp System.Security.Permissions.PrincipalPermission và bản sao đặc tính System.Security.Permissions.PrincipalPermissionAttribute của lớp này để bảo vệ các phần tử trong chương trình của bạn với các yêu cầu RBS. .NET Framework hỗ trợ cả yêu cầu RBS bắt buộc (imperative RBS demand) và yêu cầu RBS khai báo (declarative RBS demand). Lớp PrincipalPermission hỗ trợ các lệnh bảo mật bắt buộc, và bản sao đặc tính PrincipalPermissionAttribute của lớp này hỗ trợ các lệnh bảo mật khai báo. Các yêu cầu RBS sử dụng cú pháp giống như các yêu cầu CAS, nhưng các yêu cầu RBS chỉ rõ tên mà người dùng hiện hành phải có, hoặc thông thường hơn là các vai trò mà người dùng này là thành viên. Một yêu cầu RBS lệnh cho bộ thực thi xét tên và các vai trò của người dùng hiện hành, và nếu chúng không đạt yêu cầu, bộ thực thi sẽ ném ngoại lệ System.Security.SecurityException. Đoạn mã dưới đây trình bày cú pháp của một yêu cầu bảo mật bắt buộc: // Cú pháp của một yêu cầu bảo mật bắt buộc dựa-trên-vai-trò. public static void SomeMethod() { § PrincipalPermission perm = new PrincipalPermission("UserName", "RoleName"); perm.Demand(); § } Trước tiên, bạn phải tạo một đối tượng PrincipalPermission chỉ định tên người dùng và tên vai trò mà bạn yêu cầu, rồi gọi phương thức Demand của nó. Bạn chỉ có thể chỉ định một tên người dùng và tên vai trò cho mỗi yêu cầu. Nếu tên người dùng hoặc tên vai trò là null, bất kỳ giá trị nào cũng sẽ thỏa mãn yêu cầu. Khác với các quyền truy xuất mã lệnh, một yêu cầu RBS không cho kết quả trong một stack walk; bộ thực thi chỉ đánh giá tên người dùng và các vai trò của người dùng hiện hành. Đoạn mã dưới đây trình bày cú pháp của một yêu cầu bảo mật khai báo: // Cú pháp của một yêu cầu bảo mật khai báo dựa-trên-vai-trò. [PrincipalPermission(SecurityAction.Demand, Name = "UserName", Role = "RoleName")] public static void SomeMethod() { /*...*/} Bạn có thể thay các yêu cầu RBS khai báo ở mức lớp hay mức thành viên. Các yêu cầu mức- lớp áp dụng cho tất cả các thành viên của lớp trừ khi có một yêu cầu mức-thành-viên chép đè yêu cầu mức-lớp. Nói chung, bạn có thể tự chọn hiện thực các yêu cầu RBS bắt buộc hay khai báo. Tuy nhiên, các yêu cầu bảo mật bắt buộc cho phép bạn tích hợp các yêu cầu RBS với logic của mã lệnh để thực hiện những yêu cầu RBS phức tạp. Ngoài ra, nếu không biết vai trò hay tên người dùng để yêu cầu lúc biên dịch, bạn phải sử dụng các yêu cầu bắt buộc. Các yêu cầu RBS khai báo có thuận lợi là chúng độc lập với logic của mã lệnh và dễ nhận biết hơn. Ngoài ra, bạn có thể
540 Chương 13: Bảo mật xem các yêu cầu RBS khai báo bằng công cụ Permview.exe (đã được thảo luận trong mục 13.6). Cho dù hiện thực yêu cầu RBS bắt buộc hay khai báo, bạn cũng phải chắc rằng bộ thực thi có thể truy xuất tên và các vai trò của người dùng hiện hành để đánh giá yêu cầu một cách phù hợp. Lớp System.Threading.Thread mô tả một tiểu trình của hệ điều hành (chạy mã lệnh được- quản-lý). Thuộc tính tĩnh CurrentPrincipal của lớp Thread chứa một thể hiện IPrincipal— mô tả người dùng mà tiểu trình hiện đang chạy trên danh nghĩa của người này. Ở mức hệ điều hành, mỗi tiểu trình cũng có một Windows access token kết giao—mô tả tài khoản Windows mà tiểu trình hiện đang chạy trên danh nghĩa của tài khoản này. Bạn cần hiểu rằng thể hiện IPrincipal và Windows access token là hai thực thể riêng biệt. Windows sử dụng access token để thực hiện cơ chế bảo mật hệ điều hành, trong khi bộ thực thi .NET sử dụng thể hiện IPrincipal để đánh giá các yêu cầu RBS ở mức ứng dụng. Mặc dù chúng có thể mô tả cùng một người dùng, nhưng điều này không có nghĩa là luôn luôn như vậy. Theo mặc định, thuộc tính Thread.CurrentPrincipal là không xác định. Vì việc thu lấy các thông tin liên quan đến người dùng có thể mất nhiều thời gian, và chỉ một phần nhỏ trong số các ứng dụng sử dụng thông tin này, các nhà thiết kế .NET chọn cách khởi dựng "lười" đối với thuộc tính CurrentPrincipal. Trước tiên, mã lệnh thu lấy thuộc tính Thread.CurrentPrincipal, bộ thực thi gán một thể hiện IPrincipal cho thuộc tính này theo logic sau đây: 1. Nếu miền ứng dụng mà tiểu trình hiện hành đang thực thi có một principal mặc định, thì bộ thực thi sẽ gán principal này cho thuộc tính Thread.CurrentPrincipal. Theo mặc định, miền ứng dụng không có principal mặc định. Bạn có thể thiết lập principal mặc định của một miền ứng dụng bằng cách gọi phương thức SetThreadPrincipal trên một đối tượng System.AppDomain mô tả miền ứng dụng bạn muốn cấu hình. Để gọi SetPrincipalPolicy, mã lệnh của bạn phải có phần tử ControlPrincipal của SecurityPermission. Bạn chỉ có thể thiết lập principal mặc định một lần cho mỗi miền ứng dụng; lời gọi SetThreadPrincipal thứ hai dẫn đến ngoại lệ System.Security.Policy.PolicyException. 2. Nếu miền ứng dụng không có principal mặc định, chính sách principal của miền ứng dụng sẽ xác định hiện thực IPrincipal nào sẽ được tạo ra và gán nó cho Thread.CurrentPrincipal. Để cấu hình chính sách principal cho một miền ứng dụng, bạn cần thu lấy đối tượng AppDomain mô tả miền ứng dụng và gọi phương thức SetPrincipalPolicy của đối tượng này. Phương thức SetPrincipalPolicy nhận vào một thành viên thuộc kiểu liệt kê System.Security.Principal.PrincipalPolicy, giá trị này cho biết kiểu của đối tượng IPrincipal sẽ được gán cho Thread.CurrentPrincipal. Để gọi SetPrincipalPolicy, mã lệnh của bạn phải có phần tử ControlPrincipal của SecurityPermission. Bảng 13.4 liệt kê các giá trị của PrincipalPolicy; giá trị mặc định là UnauthenticatedPrincipal. 3. Nếu mã lệnh của bạn có phần tử ControlPrincipal của SecurityPermission, bạn có thể tự tạo ra đối tượng IPrincipal và trực tiếp gán nó cho thuộc tính