JAAS - Giới thiệu công nghệ (Phần 2)

Tiếp nối phần đầu bài viết về JAAS. Hãy cùng tìm hiểu xem liệu có thể chỉ sử dụng các chú thích cho JAAS hay không và chúng ta sẽ gặp phải những vấn đề gì. Trong phần này chúng ta sẽ tìm hiểu những công cụ API Servlet nào cho phép chúng ta làm cho mã trở nên phổ biến hơn. Và hãy tóm tắt những gì chúng ta đọc.

Tiếp tục

Trong phần đầu tiên của bài đánh giá về công nghệ JAAS (xem " JAAS - Giới thiệu về Công nghệ (Phần 1) ") chúng ta đã xem xét trường hợp sử dụng chính của JAAS và API Servlet. Chúng tôi thấy rằng bộ chứa servlet Tomcat đã quản lý tính bảo mật của ứng dụng web của chúng tôi bằng kiến ​​trúc JAAS. Có kiến ​​thức về “phương thức xác thực” và “Vương quốc bảo mật”, chính vùng chứa Tomcat đã cung cấp cho chúng tôi triển khai cơ chế xác thực cần thiết và chính nó đã cung cấp cho chúng tôi CallbackHandler, chúng tôi chỉ sử dụng tất cả trong mô-đun đăng nhập của mình. Điều quan trọng duy nhất cần nhớ là trình duyệt lưu dữ liệu đăng nhập và mật khẩu được truyền qua xác thực BASIC. Do đó, đối với mỗi lần quét mới bằng Chrome, bạn có thể nhấn Ctrl+Shift+N để mở cửa sổ mới hoạt động ở chế độ ẩn danh.

Chú thích

Cấu hình sử dụng XML từ lâu đã lỗi thời. Do đó, điều quan trọng cần nói là bắt đầu với Servlet API phiên bản 3.0, chúng ta có cơ hội thiết lập cài đặt servlet bằng cách sử dụng chú thích mà không cần sử dụng tệp mô tả triển khai web.xml. Hãy xem việc quản lý bảo mật sẽ thay đổi như thế nào nếu chúng ta sử dụng chú thích. Và liệu có thể triển khai các phương pháp được mô tả ở trên bằng cách sử dụng chú thích không? Đặc tả API Servlet và phần “ Chú thích và khả năng cắm ” của nó sẽ một lần nữa giúp chúng ta hiểu các chú thích . Phần này nói rằng một khai báo servlet web.xmlcó thể được thay thế bằng một chú thích @WebServlet. Theo đó, servlet của chúng ta sẽ trông như thế này:

@WebServlet(name="app", urlPatterns = "/secret")
public class App extends HttpServlet {

Tiếp theo chúng ta cùng xem chương " 13.3 Bảo mật lập trình ". Nó nói rằng chúng ta cũng có thể khai báo Ràng buộc bảo mật thông qua các chú thích:

@WebServlet(name="app", urlPatterns = "/secret")
@ServletSecurity(httpMethodConstraints = {
        @HttpMethodConstraint(value = "GET", rolesAllowed = "admin")
})
public class App extends HttpServlet {

Bây giờ web.xmlchỉ còn một khối trong khối của chúng tôi - login-config. Vấn đề là nó xảy ra đến mức không có cách nào để thay thế nó một cách dễ dàng và đơn giản. Do có sự kết nối chặt chẽ giữa cài đặt bảo mật ứng dụng web và cài đặt bảo mật máy chủ web nên không có cách nào đơn giản và phổ biến để thực hiện việc này, kể cả bằng lập trình. Đây là một trong những vấn đề khi xác thực bằng JAAS và API Servlet. Nói về khối login-config, cần hiểu rằng đó là mô tả khai báo về Cơ chế xác thực, tức là. các cơ chế xác thực. Vẫn chưa có cách phổ biến đơn giản nào để thay thế nó, bởi vì... quá trình xử lý web.xmldiễn ra sâu bên trong các thùng chứa servlet. Ví dụ: trong Tomcat bạn có thể xem nguồn ContextConfig.java . Do đó, ngay cả đối với bộ chứa servlet Tomcat cũng có một số tùy chọn và tất cả chúng đều khác nhau. Ví dụ: nếu chúng tôi sử dụng bộ chứa servlet Tomcat nhúng (tức là chúng tôi xây dựng một máy chủ web từ mã), thì bạn có thể đọc về các tùy chọn như vậy tại đây: “ Tomcat nhúng với xác thực cơ bản thông qua mã ”. Ngoài ra, có thể xem một ví dụ chung về việc nâng cao Embedde Tomcat trong hướng dẫn nền tảng Heroku PaaS: “ Tạo ứng dụng web Java bằng cách sử dụng Tomcat nhúng ”. Nếu Tomcat không được sử dụng ở chế độ Nhúng thì đối với Tomcat, bạn có thể sử dụng một phương pháp thường được sử dụng - trình xử lý sự kiện. Trong Tomcat, đây là " Thành phần Trình nghe LifeCycle ". Đồng thời, điều quan trọng là phải hiểu rằng các thùng chứa servlet (trong trường hợp của chúng ta là Tomcat) có thể có các trình nạp lớp riêng và sẽ không thể đơn giản lấy và sử dụng các lớp của bạn. Đối với Tomcat bạn cần hiểu " LÀM THẾ NÀO ĐỂ nạp lớp ". Trong một thùng chứa servlet khác có tên Undertow, điều này có thể đạt được bằng cách sử dụng " Servlet Extensions ". Như bạn có thể thấy, một số đã cung cấp các cơ chế linh hoạt hơn, trong khi một số khác thì không. Như bạn có thể thấy, không có lựa chọn duy nhất. Tất cả họ đều rất khác nhau. Có thể bằng cách nào đó làm được điều gì đó phổ quát chỉ với API Servlet và JAAS không? Trên Internet, bạn có thể tìm thấy đề xuất sử dụng Bộ lọc Servlet để thực hiện xác thực mà không bị chặn login-config. Cuối cùng chúng ta hãy xem xét lựa chọn này. Điều này sẽ cho phép chúng tôi lặp lại cách hoạt động của JAAS.

Bộ lọc xác thực

Vì vậy, mục tiêu của chúng tôi là loại bỏ web.xmlhoàn toàn tệp. Nếu chúng tôi loại bỏ nó thì thật không may, chúng tôi sẽ không thể sử dụng Ràng buộc bảo mật nữa, bởi vì quá trình xử lý của chúng có thể diễn ra sớm hơn nhiều so với việc áp dụng các bộ lọc servlet. Đây là khoản phí bạn phải trả cho tính “linh hoạt” của việc sử dụng bộ lọc. Những thứ kia. chúng tôi sẽ phải xóa chú thích @ServletSecurityvà tất cả các kiểm tra mà chúng tôi đã mô tả trước đây trong ràng buộc bảo mật sẽ phải được thực hiện theo chương trình. Như bạn có thể thấy, tùy chọn này cũng đặt ra nhiều hạn chế khó chịu đối với chúng tôi. Trước hết, hãy xóa chú thích @ServletSecuritykhỏi tài nguyên và khối login-configkhỏi tệp web.xml. Bây giờ, bản thân chúng ta sẽ phải thực hiện xác thực Cơ bản. Bây giờ hãy thêm bộ lọc của chúng tôi:

@WebFilter("/*")
public class JaasFilter implements javax.servlet.Filter {

Cho đến nay nó có vẻ đơn giản. Hãy viết một phương thức khởi tạo:

@Override
public void init(FilterConfig filterConfig) throws ServletException {
	String jaas_conf = filterConfig.getServletContext().getRealPath("/WEB-INF/jaas.config");
	System.getProperties().setProperty("java.security.auth.login.config",jaas_conf);
}

Như bạn có thể thấy, hiện tại chúng ta buộc phải sử dụng các công cụ JAAS cơ bản để tìm kiếm tệp cấu hình jaas. Điều này có một nhược điểm lớn - nếu có một số ứng dụng thì một ứng dụng có thể phá vỡ xác thực của ứng dụng khác. Nói chung, cách bạn có thể thiết lập tệp Cấu hình Jaas được mô tả chi tiết trong tài liệu JAAS: " Phụ lục A: Cài đặt JAAS trong Tệp thuộc tính bảo mật java.security ". Tiếp theo, chúng tôi sẽ mô tả chính phương pháp lọc. Hãy bắt đầu bằng cách nhận yêu cầu HTTP:

@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
	HttpServletRequest req = (HttpServletRequest) request;
	// Если в реквесте уже есть Principal - ничего не делаем
	if (req.getUserPrincipal() != null ) {
		chain.doFilter(request, response);
	}

Mọi thứ đều đơn giản ở đây. Nếu Hiệu trưởng có sẵn thì xác thực thành công. Tiếp theo, bạn cần mô tả hành động của bộ lọc khi người dùng chưa vượt qua xác thực, tức là. anh ấy vẫn chưa được công nhận. Trước đây chúng tôi đã mô tả phương pháp xác thực cơ bản, BASIC. Bởi vì Vì hiện chúng tôi đang tự viết bộ lọc nên chúng tôi sẽ phải tìm hiểu cách xác thực BASIC thực sự hoạt động. Bạn có thể sử dụng " Tài liệu web MDN: ủy quyền HTTP ". Và cả " Xác thực HTTP hoạt động như thế nào? " Từ mô tả về cách hoạt động của Xác thực cơ bản, rõ ràng là nếu máy chủ muốn thực hiện xác thực BASIC và người dùng chưa cung cấp dữ liệu thì máy chủ sẽ gửi một tiêu đề đặc biệt "WWW-Authenticate" và mã lỗi 401. Hãy tạo một phương pháp nội bộ cho việc này:

private void requestNewAuthInResponse(ServletResponse response) throws IOException {
	HttpServletResponse resp = (HttpServletResponse) response;
	String value = "Basic realm=\"JaasLogin\"";
	resp.setHeader("WWW-Authenticate", value);
	resp.sendError(HttpServletResponse.SC_UNAUTHORIZED);
}

Bây giờ hãy sử dụng phương thức này và thêm doFilterkhối mã sau vào phương thức:

// Получаем security Header. А если его нет - запрашиваем
String secHeader = req.getHeader("authorization");
if (secHeader == null) {
	requestNewAuthInResponse(response);
}

Bây giờ, hãy thêm một nhánh cho if, nhánh này sẽ được thực thi khi tiêu đề đã được truyền đi:

// Проверяем аутентификацию
else {
	String authorization = secHeader.replace("Basic ", "");
	Base64.Decoder decoder = java.util.Base64.getDecoder();
	authorization = new String(decoder.decode(authorization));
	String[] loginData = authorization.split(":");
	try {
		if (loginData.length == 2) {
			req.login(loginData[0], loginData[1]);
			chain.doFilter(request, response);
		} else {
			requestNewAuthInResponse(response);
		}
	} catch (ServletException e) {
		requestNewAuthInResponse(response);
	}
}

Bạn có thể thêm ủy quyền vào mã này, ví dụ: req.isUserInRole("admin") Vì vậy, chúng tôi đã thực hiện xác thực với bạn bằng bộ lọc. Một mặt, có rất nhiều mã và xử lý thủ công. Mặt khác, có tính linh hoạt và tính độc lập của máy chủ.

Phần kết luận

Bây giờ chúng ta đã đi đến phần cuối của bài đánh giá này. Tôi hy vọng bây giờ nó sẽ trở nên rõ ràng hơn một chút về JAAS là gì, Chủ đề là gì và Hiệu trưởng là gì. Các từ Security Realm và Đăng nhập Config sẽ không còn đặt ra câu hỏi nữa. Ngoài ra, giờ đây chúng tôi đã biết cách sử dụng JAAS và API Servlet cùng nhau. Ngoài ra, chúng tôi đã tìm hiểu về các điểm nghẽn trong đó các chú thích trong API Servlet sẽ không cứu được chúng tôi. Tất nhiên, đây không phải là tất cả. Ví dụ: xác thực trong Java có thể không chỉ là BASIC. Bạn có thể xem về các loại khác trong đặc tả API Servlet trong phần " Xác thực 13.6 ". Rất khó để tìm thấy bất kỳ thông tin chi tiết nào về JAAS trên Internet. Nhưng tôi có thể giới thiệu tài liệu này:

• " Tất cả những điều đó JAAS: Bảo mật Java có thể mở rộng với JAAS "

Tôi hy vọng thông tin từ đánh giá này sẽ hữu ích và dễ hiểu. #Viacheslav