JAAS - Pengantar Teknologi (Bagian 2)

Kelanjutan artikel bagian pertama tentang JAAS. Mari kita cari tahu apakah mungkin menggunakan anotasi saja untuk JAAS, dan masalah apa yang akan kita hadapi. Kita akan mempelajari di bagian ini alat API Servlet mana yang memungkinkan kita membuat kode lebih universal. Dan mari kita rangkum apa yang kita baca.

Kelanjutan

Pada bagian pertama tinjauan teknologi JAAS (lihat " JAAS - Pengantar Teknologi (Bagian 1) ") kami melihat kasus penggunaan utama JAAS dan API Servlet. Kami melihat bahwa kontainer servlet Tomcat mengelola keamanan aplikasi web kami menggunakan arsitektur JAAS. Memiliki pengetahuan tentang "metode auth" dan "Alam Keamanan", wadah Tomcat itu sendiri memberi kami implementasi yang diperlukan dari mekanisme otentikasi dan itu sendiri memberi kami CallbackHandler, kami hanya menggunakan semuanya dalam modul login kami. Satu-satunya hal penting yang perlu diingat adalah browser menyimpan data login dan kata sandi yang dikirimkan melalui otentikasi BASIC. Oleh karena itu, untuk setiap pemindaian baru menggunakan Chrome, Anda dapat menekan Ctrl+Shift+N untuk membuka jendela baru agar berfungsi dalam mode penyamaran.

Anotasi

Konfigurasi menggunakan XML sudah lama ketinggalan zaman. Oleh karena itu, penting untuk mengatakan bahwa dimulai dengan Servlet API versi 3.0, kita memiliki kesempatan untuk mengatur pengaturan servlet menggunakan anotasi, tanpa menggunakan file deskriptor penerapan web.xml. Mari kita lihat bagaimana manajemen keamanan akan berubah jika kita menggunakan anotasi. Dan apakah mungkin menerapkan pendekatan yang dijelaskan di atas menggunakan anotasi? Spesifikasi Servlet API dan bagiannya “ Anotasi dan pluggability ” sekali lagi akan membantu kita memahami anotasi . Bagian ini mengatakan bahwa deklarasi servlet web.xmldapat diganti dengan anotasi @WebServlet. Oleh karena itu, servlet kita akan terlihat seperti ini:

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

Selanjutnya mari kita lihat bab " 13.3 Keamanan Terprogram ". Dikatakan bahwa kita juga dapat mendeklarasikan Batasan Keamanan melalui anotasi:

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

Sekarang web.xmlhanya tersisa satu blok di blok kita - login-config. Masalahnya, kebetulan saja tidak ada cara yang mudah dan sederhana untuk menggantinya. Karena hubungan erat antara pengaturan keamanan aplikasi web dan pengaturan keamanan server web, tidak ada cara sederhana dan universal untuk melakukan hal ini, bahkan secara terprogram. Ini adalah salah satu masalah otentikasi menggunakan JAAS dan Servlet API. Berbicara tentang blok login-config, perlu dipahami bahwa ini adalah deskripsi deklaratif dari Mekanisme Otentikasi, yaitu. mekanisme otentikasi. Masih belum ada cara universal sederhana untuk menggantinya, karena... pemrosesan web.xmlterjadi jauh di dalam wadah servlet. Misalnya, di Tomcat Anda dapat melihat sumbernya ContextConfig.java . Oleh karena itu, bahkan untuk container servlet Tomcat ada beberapa opsi dan semuanya berbeda. Misalnya, jika kita menggunakan wadah servlet Tomcat Tertanam (yaitu kita meningkatkan server web dari kode), maka Anda dapat membaca tentang opsi tersebut di sini: “ Tomcat Tertanam dengan otentikasi dasar melalui kode ”. Selain itu, contoh umum membesarkan Embedde Tomcat dapat dilihat pada panduan platform Heroku PaaS: “ Membuat Aplikasi Web Java Menggunakan Embedded Tomcat ”. Jika Tomcat tidak digunakan dalam mode Tertanam, maka untuk Tomcat Anda dapat menggunakan pendekatan yang umum digunakan - pendengar acara. Di Tomcat ini adalah " Komponen Pendengar LifeCycle ". Pada saat yang sama, penting untuk dipahami bahwa kontainer servlet (dalam kasus kami Tomcat) mungkin memiliki pemuat kelasnya sendiri dan tidak mungkin mengambil dan menggunakan kelas Anda begitu saja. Untuk Tomcat Anda perlu memahami " CARA-CARA Pemuat Kelas ". Dalam wadah servlet lain yang disebut Undertow, hal ini dapat dicapai dengan menggunakan " Ekstensi Servlet ". Seperti yang Anda lihat, beberapa telah menyediakan mekanisme yang lebih fleksibel, sementara yang lain belum. Seperti yang Anda lihat, tidak ada pilihan tunggal. Semuanya sangat berbeda. Apakah mungkin melakukan sesuatu yang universal hanya dengan Servlet API dan JAAS? Di Internet Anda dapat menemukan proposal untuk menggunakan Filter Servlet untuk melakukan otentikasi tanpa blok login-config. Mari kita akhirnya mempertimbangkan opsi ini. Ini akan memungkinkan kita mengulangi cara kerja JAAS.

Filter Otentikasi

Jadi, tujuan kami adalah menghapus web.xmlfile tersebut sepenuhnya. Jika kita menghilangkannya, sayangnya kita tidak dapat lagi menggunakan Batasan Keamanan, karena pemrosesannya dapat terjadi jauh lebih awal daripada filter servlet diterapkan. Ini adalah biaya yang harus Anda bayar untuk “fleksibilitas” penggunaan filter. Itu. kita harus menghapus anotasi tersebut @ServletSecurity, dan semua pemeriksaan yang kami jelaskan sebelumnya dalam batasan keamanan harus dilakukan secara terprogram. Seperti yang Anda lihat, opsi ini juga memberlakukan banyak batasan yang tidak menyenangkan pada kami. Pertama-tama, mari kita hapus anotasi @ServletSecuritydari sumber daya dan blok login-configdari file web.xml. Sekarang, kita sendiri yang harus menerapkan otentikasi dasar. Sekarang mari tambahkan filter kita:

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

Sejauh ini tampaknya sederhana. Mari kita menulis metode inisialisasi:

@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, kita sekarang terpaksa menggunakan alat dasar JAAS untuk mencari file konfigurasi jaas. Ini memiliki kelemahan besar - jika ada beberapa aplikasi, satu aplikasi dapat merusak otentikasi aplikasi lainnya. Bagaimana Anda dapat mengatur file Jaas Config secara umum dijelaskan secara rinci dalam dokumentasi JAAS: " Lampiran A: Pengaturan JAAS di File Properti Keamanan java.security ". Selanjutnya kami akan menjelaskan metode pemfilteran itu sendiri. Mari kita mulai 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 sederhana di sini. Jika Prinsipal tersedia, maka otentikasi berhasil. Selanjutnya, Anda perlu menjelaskan tindakan filter ketika pengguna belum melewati otentikasi, mis. dia belum dikenali. Sebelumnya kami telah menjelaskan metode otentikasi dasar, BASIC. Karena Karena sekarang kita sedang menulis filternya sendiri, kita harus mencari tahu bagaimana sebenarnya otentikasi BASIC bekerja. Anda dapat menggunakan " dokumen web MDN: otorisasi HTTP ". Dan juga " Bagaimana Cara Kerja Otentikasi HTTP? " Dari uraian cara kerja otentikasi Dasar terlihat jelas bahwa jika server ingin melakukan otentikasi BASIC, dan pengguna belum memberikan data, maka server mengirimkan header khusus "WWW-Authenticate" dan kode kesalahan 401. Mari kita buat metode internal 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 metode ini dan tambahkan doFilterblok kode berikut ke metode ini:

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

Sekarang mari tambahkan cabang for if, yang akan dieksekusi ketika header telah dikirimkan:

// Проверяем аутентификацию
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 dapat menambahkan otorisasi ke kode ini, misalnya: req.isUserInRole("admin") Jadi kami telah melakukan otentikasi dengan Anda menggunakan filter. Di satu sisi, ada banyak kode dan pemrosesan manual. Di sisi lain, ada fleksibilitas dan kemandirian server.

Kesimpulan

Sekarang kita telah mencapai akhir ulasan ini. Saya berharap sekarang menjadi lebih jelas apa itu JAAS, apa itu Subjek dan apa itu Prinsipal. Kata-kata Security Realm dan Login Config tidak lagi menimbulkan pertanyaan. Selain itu, sekarang kita tahu cara menggunakan JAAS dan Servlet API secara bersamaan. Selain itu, kami belajar tentang kemacetan di mana anotasi di API Servlet tidak akan menyelamatkan kami. Tentu saja, ini belum semuanya. Misalnya, otentikasi di Java mungkin tidak hanya BASIC. Anda dapat melihat tentang tipe lainnya pada spesifikasi Servlet API di bagian " 13.6 Authentication ". Sulit untuk menemukan informasi rinci tentang JAAS di Internet. Tapi saya dapat merekomendasikan materi ini:

• " Semua JAAS itu: Keamanan Java yang terukur dengan JAAS "

Semoga informasi dari ulasan ini bermanfaat dan dapat dimengerti. #Viacheslav