Làm thế nào để bảo mật các web component của J2EE?

Web application phải được phát triển với sự bảo mật ngay từ khi bắt đầu. Các developer nên lập kế hoạch bảo mật một web application với cả web server và application server. Việc bảo mật một J2EE application có thể trông rất phức tạp, tuy nhiên trong bài viết này, phần đầu tiên sẽ giải thích làm thế nào để bảo mật các web component của J2EE.

1.“Phòng bệnh tốt hơn chữa bệnh”

Câu ngạn ngữ cổ xưa này vẫn đúng thậm chí cho đến ngày hôm nay, đặc biệt trong trường hợp các web application. Deface site chỉ là một cách tấn công website. Nó không phải là điềm báo trước nếu như bảo mật một application cần được quan tâm đầu tiên sau một cuộc tấn công. Các application phải được phát triển với khả năng bảo mật của chúng được định ra ở mức độ cao.

Cho đến một vài năm trước đây, bảo mật có nghĩa là bảo mật web server. Nhưng với sự trông đợi của lập trình server-side, bảo mật không thể là giới hạn tài nguyên bên trong web server, mà hầu hết yêu cầu xử lý và dịch vụ được thực hiện bằng việc thực thi mã bên trong application server. Trong trường hợp của J2EE, bảo mật một web application có thể phức tạp: một J2EE application có thể chứa một hay nhiều hơn các component khác nhau, mỗi component cung cấp dịch vụ cho một layer khác nhau. Thế giải pháp là gì? Giải pháp đến từ hai package khác nhau:

    * Declareative security : nếu một application tuân theo cách này, thì tất cả những xác lập bảo mật nằm trong file web.xml của application. Container đọc những xác lập này và thực thi truy cập điều khiển cho application cụ thể.

    * Programmatic security : Dưới mô hình này, trách nhiệm bảo mật web application thuộc về duy nhất lập trình viên. Logic ủy quyền và phân chia quyền hạn user được nhúng vào trong application. Nó có thể tồn tại một dịch vụ toàn bộ application hoặc trong mỗi module.

Bảo mật dựa trên Realm có trước, trong khi bảo mật dựa trên Java Authentication and Authorization Services (JASS) đến sau. Câu hỏi rõ ràng kế tiếp đặt ra là cái nào tốt hơn? Câu trả lời , thường lặp lại, đó là ngữ cảnh xác định việc xử dụng. Nếu việc bảo mật mã ít hơn thì declarative security là tốt hơn. Nếu điều khiển từng phần được yêu cầu thì programmatic security là sự lựa chọn tốt nhất.

Quay về ngữ cảnh J2EE component, chúng được chia thành Web Components và Business Components. Các Servlet và JSP là những Web Component trái lại Enterprise Java Beans (EJB) là những Business Component. Phương thức bảo mật các Web Component khác với cách bảo mật các Business Component. Trong tutorial này, chúng ta thảo luận về làm thế nào để bảo mật các Web Component bằng việc sử dụng JAAS. Trước khi bắt đầu thảo luận, tốt hơn là làm quen với JAAS, tổng quan về nó và từ vựng của nó.

2.JAAS là gì?

Theo truyền thống, bảo mật cung cấp bởi bảo mật dựa trên mã Java (chúng ta sẽ sử dụng Java khi đề cập đến J2SE). Trong bảo mật dựa trên mã, chữ ký của mã cung với mã gốc được chứng thực. Các đặc quyền của user chạy mã không bao giờ được kiểm tra. Vì thế điều khiển truy cập không bao giờ có hiệu lực. Để vượt qua giới hạn này, package JAAS được giới thiệu. Trong phiên bản hiện thời, JAAS là một trong những module cốt lõi của Java Development Kit. JAAS có hai component: một authentication component (xác nhận), và một authorization component (phân quyền). Authentication component cung cấp các dịch vụ để xác nhận định danh user người đang thực thi mã. Authorization component bổ sung những đặc điểm bảo mật mã tồn tại bằng việc hạn chế mã từ việc thực thi các tác nhiệm hệ thống. Điều này được thực hiện bằng cách tăng hiệu lực điều khiển truy cập dựa trên việc xác nhận. Module authorization có thể cung cấp dịch vụ này cho bất kỳ kiểu mã nào mà nó có đang được thực thi từ bên trong một application hay không, applet và servlet hay cho EJB. Một phần bên ngoài, JAAS thực hiện việc xác nhận và phân quyền của nó trong một kiểu pluggable. Những đặc điểm này của JAAS làm cho nó tốt hơn trong việc bảo mật các ứng dụng J2EE.

3.Tại sao sử dụng JAAS?

Trong J2EE, câu trả lời nằm ở những cơ sở dưới đây:

    * Như đã được mô tả, JAAS bao gồm những đặc điểm bảo mật đựơc cung cấp bởi Java

    * Nó thích hợp với bảo mật J2EE. Việc tích hợp của JAAS với J2EE cũng rất dễ dàng

    * Việc xác nhận thực hiện bởi JAAS theo phương cách thiết kế Pluggable Authentication Module. Cách làm này Java có được từ kỹ thuật xác nhận mà sự thay đổi trong kỹ thuật này có thể đạt được mà không phải viết lại mã

[HaiPhong-Aptech] st

Subject, principals và credentials

Subject

Nói một cách ngắn gọn, một subject liên quan đến một cá thể, ví dụ một user hoặc một hệ thống khác. Những user của hệ thống phụ thuộc trên những tài nguyên khác nhau được cung cấp bởi hệ thống để thực thi những tác nhiệm tính toán khác nhau. Các tài nguyên này hầu hết luôn luôn nằm trong một dạng của các Service. Trong những trường hợp nào đó, bản thân một hệ thống phải phụ thuộc vào những service chạy trên những hệ thống khác. Vì thế, trong cả hai trường hợp, dù đó là một cá thể sử dụng các service hệ thống hoặc hệ thống khác thì JAAS phải chứng thực nó. Vì thế trong thuật ngữ của JAAS, cả hai trở thành những subject.

Principal

Một service luôn luôn được kết hợp với tên của subject đang sử dụng service đó. Và mỗi subject có thể sử dụng nhiều service khác nhau dưới những tên khác nhau. Vì thế, principal, về thực chất là tên được kết hợp với một subject. Nói một cách khác, tên kết hợp một subject và một service chính là principal. Giống như subject, principal là một trong những class cốt lõi.

Credential

Một service, tại nhiều thời điểm, sẽ đính kèm những thuộc tính bảo mật (cũng đồng thời là dữ liệu) cho một subject khác với principal. Hầu hết các thời điểm những thuộc tính này thường không có gì, nhưng thông tin được hỗ trợ bởi subject cho authentication (việc chứng thực). Những thuộc tính như thế là những credential được giới hạn. Credential có thể là bất kỳ kiểu đối tượng nào. Chúng có thể bao gồm password (mật khẩu), Kerberos ticket, và các public key certificate (khóa xác nhận). Các đặc điểm pluggable (cắm & xài) này của JAAS đảm bảo rằng việc bổ sung credential của bên thứ ba có thể được tập hợp vào bên trong JAAS mà không phải tốn nhiều công sức.

Các thuật ngữ quan hệ thế nào trong code?

Hãy cùng nhìn một chút. Như tôi đã thảo luận, mỗi subject có thể có nhiều tên. Một subject sẽ có một tập các principal

public interface Principal {     public String getName(); } public final class Subject {     public Set getPrincipals() {     } }

Tương tự như thế:

public final class Subject {     ...     public Set getPublicCredentials() { }// không kiểm tra bảo mật     public Set getPrivateCredentials() { } // kiểm tra bảo mật }

Trong nhiều thuật ngữ cần giải thích hơn, class Subject có một method trả về những principal được kết hợp với subject, kiểu trả về là một collection – Set. Class subject có những method tốt hơn cho các Credential. Có hai kiểu credential trong ví dụ trên: các public credential và private credential. Các public credential chứa các Public key, các Kerberos ticket của instance Subject vân vân... trong khi các private credential chứa các Private Key, các password vân vân... Vì thế, subject chứa những method để lấy những credential và principal được kết hợp với nó.

[HaiPhong-Aptech] st

Bổ sung module bảo mật JAAS

Đã lý luận quá nhiều, bây giờ là thời gian để xem xét những bước đòi hỏi việc bổ sung JAAS như một module. Việc bổ sung dưới đây được phát triển để cung cấp bảo mật cho một ứng dụng Java Mail. Để viết những bổ sung tùy biến, sử dụng những bước sau:

* Bổ sung LoginModule

* Viết CallBackHandler

* Cung cấp các bổ sung tùy biến cho Principal và Action (đây là lựa chọn)

* Cấu hình file JAAS policy

* Cấu hình J2EE Application Server

Trước khi đi vào chi tiết của bổ sung, package mà bạn cần phải import là javax.security

Bổ sung LoginModule

LoginModule là một trong những module cốt lõi của JAAS. Nó đóng gói tính logic của việc chứng thực dành cho JAAS framework. Để bổ sung LoginModule, một trong bốn method sau phải được override.

* login()

Method này thực thi các tác nhiệm trong việc thu thập thông tin đăng nhập và việc chứng thực user. Nói một cách ngắn gọn, tính logic để chứng thực một user là ở đây. Việc thu thập thông tin đăng nhập được thực hiện như dưới đây

Callback[ callbacks=new Callbacks[2]; Callbacks[0] = new NameCallback(“userModule username:”); Callbacks[0] = new NameCallback(“userModule password:”,false); callbackHandler.handle(calls);

Hiển nhiên là trong đoạn mã ở trên, thông tin đăng nhập được thu thập sử dụng CallBackHandler. Một khi thông tin đăng nhập được tập hợp với nhau, method login sẽ cố gắng để kết nối với server. Nếu kết nối được, method sẽ trả về true. Đoạn mã nhỏ dưới đây chỉ ra thủ tục đó:

boolean succeeded=false; try {     user=((NameCallback)callbacks[0]).getName();     passwd=((NameCallback)callbacks[0]).getPassword();     props.put(Context.SECURITY_PRINCIPAL,user);     props.put(Context.SECURITY_CREDENTIALS,passwd);     ctx = new InitialDirContext(props);     succeeded =true; }… return succeeded;

Trong khối lênh try – catch, nó cố gắng để kết nối với LDAP server với thông tin đã được tập hợp. Nếu kết nối thành công (dĩ nhiên, method InitialDirContext() không ném ra các ngoại lệ), biến chứng thực được set là true. Ở đây, thay vì LDAP server, database server được sử dụng như là server dành cho việc chứng thực.

* commit()

Method này set username đã được kiểm tra trong session context. Mã thể hiện subject với các vai trò và các credential (chẳng hạn như các private key) bất kỳ cũng ở đây.

if(!succeeded) {     return false; } else {     userPrincipal=new userPrincipal(user);     if(!subject.getPrincipals().contains(userPrincipal) {         subject.getPrincipals().add(userPrincipal);         ...      }     commitSucceeded=true;     return true; }

* abort()

Method này được gọi khi việc chứng thực LoginContext bị lỗi. Method này cũng được tự động thực thi bởi runtime nếu như một runtime exception xảy ra. Để tạo nên xử lý tùy biến trong trường hợp việc chứng thực bị lỗi này, đoạn mã thực hiện như sau

if(!succeed) {//this is for authentication failure     return false; } else if(succeeded&&commitSucceeded==false) {//this is for //runtime //error     user=null;     passwd=null;     throw new FailedLoginException(“Exception in Processin”); }

* logout()

Bất kỳ khi nào user đăng xuất, method này sẽ được gọi. Vì thế, nếu bạn muốn gỡ bỏ một vài credential hay giải phóng tài nguyên nắm giữ bởi user bạn có thể thực hiện ở đây. Đoạn mã sử dụng như dưới đây:

subject.getPrincipals.remove(userPrincipal); succeeded = false; succeeded = commitSucceeded; user = null; if(password!=null) {     password=null; } userPrincipal=null; return true;

Viết CallBackHandler

Để tập hợp thông tin chứng thực của user, LoginModule sử dụng javax.security.auth.callback.CallBackHandler. Một application bổ sung interface này và truyền nó cho LoginContext. LoginContext sau đó chuyển tiếp nó cho LoginModules nằm dưới. Vì thế, dữ liệu được tập hợp có thể gồm một cặp từ các bổ sung chứng thực. Một phần của bổ sung CallBackHandler là kiểu dữ liệu được sử dụng để kiểm tra user. Dưới đây là đoạn mã mà CallBackHandler sử dụng trong application của chúng ta. Tạo một class bổ sung interface CallBackHandler và override method handle()

  if(callback<img src="http://hp-aptech.edu.vn/emoticons/emotion-55.gif" alt="Idea" /> instanceof NameCallback) {     NameCallback nc = (PasswordCallback)callbacks<img src="http://hp-aptech.edu.vn/emoticons/emotion-55.gif" alt="Idea" />;     // làm những gì cần thiết     ...     nc.setPassword(password.toCharArray()); } if(callback<img src="http://hp-aptech.edu.vn/emoticons/emotion-55.gif" alt="Idea" /> instanceof PasswordCallback) {     PasswordCallback pc= (PasswordCallback)callbacks<img src="http://hp-aptech.edu.vn/emoticons/emotion-55.gif" alt="Idea" />;     //làm những gì cần thiết     ...     pc.setPassword(password.toCharArray()); }

Cung cấp các bổ sung tùy biến cho Principal và Action

Đây là một bước lựa chọn. Bước này hữu dụng khi lưu trữ username và so sánh nó với một login mới. Cũng như những bước trước, bắt đầu bằng việc tạo ra một class. Nếu tôi sử dụng class này để so sánh hai userPrincipal chúng ta thực hiện việc đó trong method equals()

public class userPrincipal implements Principal, java.io.Serializable {     ...     public boolean equals(Object o) {         if(o==null) {             return false;         }         if(this ==o) {             return true;         }         if(!(o instanceof userPrincipal)) {             return false;         }         userPrincipal that=(userPrincipal)o;         if (this.getName().equals(that.getName())) {             return true;         }         return false;     }     public String getName() {         return userPrincipal.getName();     } }

Đầu tiên, đoạn mã kiểm tra đối tượng null. Sau đó, nó kiểm tra xem các đối tượng có giống nhau không. Một khi điều đó được thực hiện xong, nó gán đối tượng cho một đối tương kiểu userPrincipal và kiểm tra xem giá trị được chứa trong nó có bằng nhau không. Chỉ có một method được override là getName(). Trong trường hợp của chúng ta nó chỉ trả về tên được chứa trong đối tượng userPrincipal truyền đi.

Kế tiếp là bổ sung cho PrivilagedAction. Bằng cách làm điều này, chúng ta có thể điều khiển việc truy cập tài nguyên trên các quyền cơ bản vào thời điểm thực.

Tạo ra một bổ sung tùy biến bằng việc bổ sung PrivilagedAction interface. Sau đó override method run() như đã được chỉ dưới đây. Những bổ sung có thể khác.

public class userAction implements PrivilagedAction {     ...     public Object run() {         File f=new File(“tips.html”);         if(!f.exists()) {             System.out.println(“File does not exists in user directory”);             //làm những gì khác cần thiết             return null;         }     } }

Ở đây, chúng ta chỉ kiểm tra sự file tồn tại của file. Method exists() trả về true chỉ nếu như đối tượng file có quyền truy cập đến. Trong trường hợp này, đối tượng file chỉ có quyền nếu như nó nằm trong thư mục nhà của user.

Cấu hình file JAAS policy

Việc cấu hình JAAS policy được thực hiện trong các file .policy. Chỉ có một LoginModule là được cấu hình cho module bảo mật. Các policy được set trong user.policy và user_jaas.conf

User.policy:

/*cấp quyền cho user LoginModule AllPermission ví dụ cho tất cả quyền cho LoginModule.*/ grant codebase “file:./user_module.jar” {     permission java.security.AllPermission; } grant codebase “file:./user.jar” {     permission javax.security.auth.AuthPermission “createLoginContext.User”;     permission javax.security.auth.AuthPermission “doAs”;     permission javax.security.util.PropertyPermission “java.home”,”read”;     permission javax.security.util.PropertyPermission “user.home”,”read”;     java.io.FilePermission “tips.html”,”read”; } /*Cũng set các quyền tương tự cho các file khác. Chúng không được chỉ ra ở đây*/

Bây giờ có một vài sự giải thích. Đầu tiên là toàn bộ việc cấp quyền cho userLoginModule. UserLoginModule được xem như được cung cấp đầy đủ. Vì thế nó có tất cả các quyền. Thứ hai là toàn bộ việc cấp quyền cho bản thân chương trình, khi ứng dụng không được cung cấp đầy đủ. Vì thế subject được chứng thực đầu tiên, và Subject.doAs được gọi cùng với subject đó và một userAction, có thể truy cập thuộc tính hệ thống – java.home, user, home và file tips.html. Bây giờ là user_jaas.conf. Nó cung cấp tên ứng dụng và các tham số yêu cầu

user_jaas.conf: Userend {     userLoginModule required debug=true }

Cấu hình J2EE Application Server

Bước này thay đổi với mỗi application server, vì thế nên tra cứu trong các tài liệu được cung cấp bởi vendor

[HaiPhong-Aptech]

Sử dụng JAAS Module để bảo mật web component

Đây là bước cuối cùng trong quá trình hoàn tất. Cách tốt nhất để làm nó là bổ sung một servlet-filter. Bất kỳ lúc nào, một request được tạo nên cho web application, request đi thông qua servlet-filter, nếu đã được bổ sung hay có sẵn. Vì thế từ trang đăng nhập, dữ liệu liên quan đến user có thể dễ dàng được truyền cho CallBackHander.

Để bổ sung một servlet filter, đầu tiên bổ sung Filter và sau đó override method doFilter(). Trong method doFilter , gọi bổ sung CallBackHandler và truyền vào dữ liệu user.

public class JAASLoginFilter implements Filter {     public void doFilter(ServletRequest request, ServletResponse response, FilterChain  chain) {         // login         String username = request.getSession().getAttribute("username");         char[ password = request.getSession().getAttribute("password");         handler = new UsernamePasswordHandler(username, password);         LoginContext lc = new LoginContext("client-login", handler);         lc.login();         // run the servlet         chain.doFilter(request, response);            // logout         lc.logout();     } }

Đoạn mã ở trên chỉ cách bổ sung. Method doFilter gọi CallBackHandler và cung cấp cho nó dữ liệu của user. Việc bổ sung trên không phải là một phiên bản thu gọn. Nó chỉ là một phiên bản ở mức cao. Có nhiều cách khác nhau để làm điều này. 

Để tích hợp điều này vào trong web application, cần có một tham khảo trong ví dụ web.xml được cung cấp bởi vendor.

Đó là tất cả những gì để cài đặt JAAS với servlet filter.

Vì thế điều này mang đến cho chúng ta kết thúc bảo mật web application sử dụng JAAS. Trong thế giới bảo mật web ngày hôm nay, để cung cấp bản chất điều khiển, JAAS là lựa chọn tốt nhất có sẵn cho bất kỳ lập trình viên J2EE nào nếu như nó kết hợp cả hai vai trò dựa trên bảo mật và lập trình nó.

[HaiPhong-Aptech]