JSP - bezpieczeństwo
Strony i serwlety JavaServer udostępniają programistom WWW kilka mechanizmów do zabezpieczania aplikacji. Zasoby są chronione deklaratywnie, identyfikując je w deskryptorze wdrażania aplikacji i przypisując im rolę.
Dostępnych jest kilka poziomów uwierzytelniania, od uwierzytelniania podstawowego przy użyciu identyfikatorów i haseł po zaawansowane uwierzytelnianie przy użyciu certyfikatów.
Uwierzytelnianie oparte na rolach
Mechanizm uwierzytelniania w specyfikacji serwletu wykorzystuje technikę o nazwie role-based security. Chodzi o to, że zamiast ograniczać zasoby na poziomie użytkownika, tworzysz role i ograniczasz zasoby według roli.
Możesz zdefiniować różne role w pliku tomcat-users.xml, który znajduje się poza katalogiem domowym Tomcata w conf. Przykład tego pliku pokazano poniżej -
<?xml version = '1.0' encoding = 'utf-8'?>
<tomcat-users>
<role rolename = "tomcat"/>
<role rolename = "role1"/>
<role rolename = "manager"/>
<role rolename = "admin"/>
<user username = "tomcat" password = "tomcat" roles = "tomcat"/>
<user username = "role1" password = "tomcat" roles = "role1"/>
<user username = "both" password = "tomcat" roles = "tomcat,role1"/>
<user username = "admin" password = "secret" roles = "admin,manager"/>
</tomcat-users>
Ten plik definiuje proste mapowanie między plikami username, password, i role. Zwróć uwagę, że dany użytkownik może mieć wiele ról; na przykład,username = "both" jest w roli „kocur” i „rola1”.
Po zidentyfikowaniu i zdefiniowaniu różnych ról ograniczenia zabezpieczeń oparte na rolach można umieścić w różnych zasobach aplikacji sieci Web przy użyciu rozszerzenia <security-constraint> element w web.xml plik dostępny w katalogu WEB-INF.
Poniżej znajduje się przykładowy wpis w pliku web.xml -
<web-app>
...
<security-constraint>
<web-resource-collection>
<web-resource-name>SecuredBookSite</web-resource-name>
<url-pattern>/secured/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>
Let only managers use this app
</description>
<role-name>manager</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>manager</role-name>
</security-role>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
...
</web-app>
Powyższe wpisy oznaczałyby -
Każde żądanie HTTP GET lub POST skierowane do adresu URL dopasowanego przez / zabezpieczone / * podlegałoby ograniczeniom bezpieczeństwa.
Osoba pełniąca rolę menedżera ma dostęp do zabezpieczonych zasobów.
Plik login-config element służy do opisu BASIC forma uwierzytelnienia.
Jeśli spróbujesz przeglądać dowolny adres URL, w tym /securitykatalogu, zostanie wyświetlone następujące okno dialogowe z pytaniem o nazwę użytkownika i hasło. Jeśli podasz nazwę użytkownika"admin" i hasło "secret", wtedy będziesz mieć dostęp do adresu URL dopasowanego przez /secured/* ponieważ zdefiniowaliśmy administratora użytkownika z rolą menedżera, który ma dostęp do tego zasobu.
Uwierzytelnianie oparte na formularzach
Korzystając z metody uwierzytelniania FORMULARZ, należy podać formularz logowania, aby poprosić użytkownika o podanie nazwy użytkownika i hasła. Poniżej znajduje się prosty kodlogin.jsp. Pomaga to stworzyć formularz w tym samym celu -
<html>
<body bgcolor = "#ffffff">
<form method = "POST" action ="j_security_check">
<table border = "0">
<tr>
<td>Login</td>
<td><input type = "text" name="j_username"></td>
</tr>
<tr>
<td>Password</td>
<td><input type = "password" name="j_password"></td>
</tr>
</table>
<input type = "submit" value = "Login!">
</form>
</body>
</html>
Tutaj musisz się upewnić, że formularz logowania musi zawierać wymienione elementy formularza j_username i j_password. Akcja w<form> tag musi być j_security_check. POSTmusi być używana jako metoda formularza. W tym samym czasie będziesz musiał zmodyfikować plik<login-config> tag, aby określić metodę uwierzytelniania jako FORM -
<web-app>
...
<security-constraint>
<web-resource-collection>
<web-resource-name>SecuredBookSite</web-resource-name>
<url-pattern>/secured/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>Let only managers use this app</description>
<role-name>manager</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<role-name>manager</role-name>
</security-role>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/error.jsp</form-error-page>
</form-login-config>
</login-config>
...
</web-app>
Teraz, gdy próbujesz uzyskać dostęp do dowolnego zasobu za pomocą URL /secured/*, wyświetli powyższy formularz z pytaniem o identyfikator użytkownika i hasło. Gdy kontener zobaczy „j_security_check"akcja, używa wewnętrznego mechanizmu do uwierzytelnienia dzwoniącego.
Jeśli logowanie powiedzie się, a wywołujący jest upoważniony do dostępu do zabezpieczonego zasobu, kontener używa identyfikatora sesji do zidentyfikowania sesji logowania dla wywołującego od tego momentu. Kontener utrzymuje sesję logowania za pomocą pliku cookie zawierającego identyfikator sesji. Serwer odsyła plik cookie z powrotem do klienta i tak długo, jak wywołujący przedstawia ten plik cookie z kolejnymi żądaniami, kontener będzie wiedział, kim jest dzwoniący.
Jeśli logowanie nie powiedzie się, serwer odsyła stronę zidentyfikowaną przez ustawienie strony błędu formularza
Tutaj, j_security_checkto czynność, którą aplikacje korzystające z logowania opartego na formularzu muszą określić dla formularza logowania. W tej samej formie powinieneś mieć również kontrolkę wprowadzania tekstu o nazwiej_username i a password input control nazywa j_password. Gdy to zobaczysz, oznacza to, że informacje zawarte w formularzu zostaną przesłane na serwer, który sprawdzi nazwę i hasło. Sposób, w jaki to się robi, zależy od serwera.
Sprawdź implementacje dziedziny standardowej, aby zrozumieć, jak to zrobićj_security_check działa dla kontenera Tomcat.
Programowe bezpieczeństwo w serwlecie / JSP
Plik HttpServletRequest obiekt udostępnia następujące metody, których można użyć do wydobywania informacji o bezpieczeństwie w czasie wykonywania -
S.No. | Metoda i opis |
---|---|
1 | String getAuthType() Plik getAuthType() metoda zwraca obiekt String, który reprezentuje nazwę schematu uwierzytelniania używanego do ochrony serwletu. |
2 | boolean isUserInRole(java.lang.String role) Plik isUserInRole() metoda zwraca wartość logiczną: true, jeśli użytkownik jest w danej roli lub false, jeśli nie. |
3 | String getProtocol() Plik getProtocol()metoda zwraca obiekt String reprezentujący protokół, który został użyty do wysłania żądania. Tę wartość można sprawdzić, aby określić, czy użyto bezpiecznego protokołu. |
4 | boolean isSecure() Plik isSecure()metoda zwraca wartość logiczną reprezentującą, czy żądanie zostało wysłane przy użyciu protokołu HTTPS. Wartość true oznacza, że tak było i połączenie jest bezpieczne. Wartość false oznacza, że żądanie nie było. |
5 | Principle getUserPrinciple() Plik getUserPrinciple() metoda zwraca obiekt java.security.Principle, który zawiera nazwę aktualnie uwierzytelnionego użytkownika. |
Na przykład dla strony JavaServer, która zawiera linki do stron dla menedżerów, możesz mieć następujący kod -
<% if (request.isUserInRole("manager")) { %>
<a href = "managers/mgrreport.jsp">Manager Report</a>
<a href = "managers/personnel.jsp">Personnel Records</a>
<% } %>
Sprawdzając rolę użytkownika na stronie JSP lub serwlecie, można dostosować stronę WWW tak, aby wyświetlała użytkownikowi tylko te elementy, do których ma on dostęp. Jeśli potrzebujesz nazwy użytkownika, która została wprowadzona w formularzu uwierzytelniania, możesz zadzwonić dogetRemoteUser metoda w obiekcie żądania.