JAAS - Pengenalan kepada Teknologi (Bahagian 2)

Sambungan bahagian pertama artikel tentang JAAS. Mari kita fikirkan sama ada boleh menggunakan anotasi untuk JAAS sahaja, dan masalah yang akan kita hadapi. Kami akan mempelajari dalam bahagian ini alat Servlet API yang membolehkan kami menjadikan kod lebih universal. Dan mari kita ringkaskan apa yang kita baca.

sambungan

Dalam bahagian pertama semakan teknologi JAAS (lihat " JAAS - Pengenalan kepada Teknologi (Bahagian 1) ") kami melihat kes penggunaan utama untuk JAAS dan API Servlet. Kami melihat bahawa bekas servlet Tomcat menguruskan keselamatan aplikasi web kami menggunakan seni bina JAAS. Mempunyai pengetahuan tentang "kaedah pengesahan" dan "Alam Keselamatan", bekas Tomcat itu sendiri memberikan kami pelaksanaan mekanisme pengesahan yang diperlukan dan dengan sendirinya memberikan kami CallbackHandler, kami hanya menggunakan semuanya dalam modul log masuk kami. Satu-satunya perkara penting yang perlu diingat ialah penyemak imbas menyimpan data log masuk dan kata laluan yang dihantar melalui pengesahan ASAS. Oleh itu, untuk setiap imbasan baharu menggunakan Chrome, anda boleh menekan Ctrl+Shift+N untuk membuka tetingkap baharu untuk berfungsi dalam mod inkognito.

Anotasi

Konfigurasi menggunakan XML telah lama ketinggalan zaman. Oleh itu, adalah penting untuk mengatakan bahawa bermula dengan Servlet API versi 3.0, kami mempunyai peluang untuk menetapkan tetapan servlet menggunakan anotasi, tanpa menggunakan fail deskriptor penggunaan web.xml. Mari lihat bagaimana pengurusan keselamatan akan berubah jika kita menggunakan anotasi. Dan adakah mungkin untuk melaksanakan pendekatan yang diterangkan di atas menggunakan anotasi? Spesifikasi Servlet API dan bahagiannya " Anotasi dan kebolehpasangan " sekali lagi akan membantu kami memahami anotasi . Bahagian ini mengatakan bahawa pengisytiharan servlet web.xmlboleh digantikan dengan anotasi @WebServlet. Oleh itu, servlet kami akan kelihatan seperti ini:

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

Seterusnya, mari kita lihat bab " 13.3 Keselamatan Programatik ". Ia mengatakan bahawa kami juga boleh mengisytiharkan Kekangan Keselamatan melalui anotasi:

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

Kini web.xmlhanya tinggal satu blok sahaja di dalam kita - login-config. Masalahnya ialah kebetulan bahawa tidak ada cara untuk menggantikannya dengan mudah dan mudah. Disebabkan hubungan rapat antara tetapan keselamatan aplikasi web dan tetapan keselamatan pelayan web, tidak ada cara yang mudah dan universal untuk melakukan ini, walaupun secara pemrograman. Ini adalah salah satu masalah dengan pengesahan menggunakan JAAS dan Servlet API. Bercakap tentang blok login-config, perlu difahami bahawa ia adalah perihalan deklaratif Mekanisme Pengesahan, i.e. mekanisme pengesahan. Masih tiada cara universal yang mudah untuk menggantikannya, kerana... pemprosesan web.xmlberlaku jauh di dalam bekas servlet. Sebagai contoh, dalam Tomcat anda boleh melihat sumber ContextConfig.java . Oleh itu, walaupun untuk bekas servlet Tomcat terdapat beberapa pilihan dan semuanya berbeza. Sebagai contoh, jika kami menggunakan bekas servlet Tomcat Terbenam (iaitu kami menaikkan pelayan web daripada kod), maka anda boleh membaca tentang pilihan tersebut di sini: " Tomcat Terbenam dengan pengesahan asas melalui kod ". Di samping itu, contoh umum menaikkan Embedde Tomcat boleh dilihat dalam panduan platform Heroku PaaS: " Cipta Aplikasi Web Java Menggunakan Tomcat Terbenam ". Jika Tomcat tidak digunakan dalam mod Embedded, maka untuk Tomcat anda boleh menggunakan pendekatan yang biasa digunakan - pendengar acara. Dalam Tomcat ini ialah " Komponen Pendengar LifeCycle ". Pada masa yang sama, adalah penting untuk memahami bahawa bekas servlet (dalam kes kami Tomcat) mungkin mempunyai pemuat kelas mereka sendiri dan tidak mungkin untuk mengambil dan menggunakan kelas anda sahaja. Untuk Tomcat anda perlu memahami " Class Loader HOW-TO ". Dalam bekas servlet lain yang dipanggil Undertow, ini boleh dicapai menggunakan " Servlet Extensions ". Seperti yang anda lihat, ada yang menyediakan mekanisme yang lebih fleksibel, sementara yang lain tidak. Seperti yang anda lihat, tiada pilihan tunggal. Mereka semua sangat berbeza. Adakah mungkin untuk melakukan sesuatu yang universal dengan hanya Servlet API dan JAAS? Di Internet anda boleh mencari cadangan untuk menggunakan Penapis Servlet untuk melaksanakan pengesahan tanpa sekatan login-config. Akhirnya mari kita pertimbangkan pilihan ini. Ini akan membolehkan kami mengulangi cara JAAS berfungsi.

Penapis Pengesahan

Jadi, matlamat kami adalah untuk membuang web.xmlfail sepenuhnya. Jika kita menyingkirkannya, maka, malangnya, kita tidak lagi dapat menggunakan Kekangan Keselamatan, kerana pemprosesan mereka boleh berlaku lebih awal daripada penapis servlet digunakan. Ini ialah yuran yang perlu anda bayar untuk "fleksibiliti" menggunakan penapis. Itu. kami perlu mengalih keluar anotasi @ServletSecuritydan semua semakan yang kami nyatakan sebelum ini dalam kekangan keselamatan perlu dilakukan secara pemrograman. Seperti yang anda lihat, pilihan ini juga mengenakan banyak sekatan yang tidak menyenangkan kepada kami. Pertama sekali, mari kita keluarkan anotasi @ServletSecuritydaripada sumber dan blok login-configdaripada web.xml. Sekarang, kita sendiri perlu melaksanakan pengesahan Asas. Sekarang mari tambah penapis kami:

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

Setakat ini nampak mudah. Mari tulis kaedah permulaan:

@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);
}

Seperti yang anda lihat, kami kini terpaksa menggunakan alatan JAAS asas untuk mencari fail konfigurasi jaas. Ini mempunyai kelemahan besar - jika terdapat beberapa aplikasi, maka satu aplikasi boleh memecahkan pengesahan yang lain. Cara anda secara amnya boleh menetapkan fail Jaas Config diterangkan secara terperinci dalam dokumentasi JAAS: " Lampiran A: Tetapan JAAS dalam Fail Sifat Keselamatan java.security ". Seterusnya, kami akan menerangkan kaedah penapisan itu sendiri. Mari mulakan dengan menerima permintaan 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);
	}

Semuanya mudah di sini. Jika Pengetua tersedia, maka pengesahan berjaya. Seterusnya, anda perlu menerangkan tindakan penapis apabila pengguna belum lulus pengesahan, i.e. dia belum lagi dikenali. Sebelum ini kami menerangkan kaedah pengesahan asas, BASIC. Kerana Memandangkan kami kini menulis penapis sendiri, kami perlu memikirkan cara pengesahan ASAS sebenarnya berfungsi. Anda boleh menggunakan " MDN web docs: HTTP authorization ". Dan juga " Bagaimana Pengesahan HTTP Berfungsi? " Daripada penerangan tentang cara pengesahan Asas berfungsi, adalah jelas bahawa jika pelayan ingin melakukan pengesahan ASAS, dan pengguna tidak memberikan data, maka pelayan menghantar pengepala khas "WWW-Authenticate" dan kod ralat 401. Mari buat kaedah dalaman untuk ini:

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);
}

Sekarang mari kita gunakan kaedah ini dan tambahkan doFilterblok kod berikut kepada kaedah:

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

Sekarang mari tambah cawangan untuk if, yang akan dilaksanakan apabila pengepala telah dihantar:

// Проверяем аутентификацию
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);
	}
}

Anda boleh menambah kebenaran pada kod ini, contohnya: req.isUserInRole("admin") Jadi kami telah melakukan pengesahan dengan anda menggunakan penapis. Di satu pihak, terdapat banyak kod dan pemprosesan manual. Sebaliknya, terdapat fleksibiliti dan kebebasan pelayan.

Kesimpulan

Sekarang kita telah sampai ke penghujung ulasan ini. Saya harap kini akan menjadi lebih jelas sedikit apa itu JAAS, apakah itu Mata Pelajaran dan apakah itu Pengetua. Perkataan Alam Keselamatan dan Konfigurasi Log Masuk tidak akan menimbulkan persoalan lagi. Selain itu, kami kini tahu cara menggunakan JAAS dan API Servlet bersama-sama. Selain itu, kami mengetahui tentang kesesakan yang mana anotasi dalam Servlet API tidak akan menyelamatkan kami. Sudah tentu, ini bukan semua. Sebagai contoh, pengesahan dalam Java mungkin bukan sahaja ASAS. Anda boleh melihat tentang jenis lain dalam spesifikasi API Servlet dalam bahagian " 13.6 Authentication ". Sukar untuk mencari maklumat terperinci mengenai JAAS di Internet. Tetapi saya boleh mengesyorkan bahan ini:

• " Semua JAAS itu: Keselamatan Java boleh skala dengan JAAS "

Saya harap maklumat daripada ulasan ini berguna dan boleh difahami. #Viacheslav