| programmera.net -> jsp -> normal för utskrift | info@programmera.net |
Säkerhet
|
1. Säkerhet i webb-behållaren 2. Ett första exempel 3. tomcat-users.xml 4. web.xml 5. Skriv JSP-sidorna 6. Testa applikationen 7. login-config 8. security-constraint |
1. Säkerhet i webb-behållaren
Webb-behållaren har några inbyggda säkerhetsfunktioner som underlättar programmeringen. I webb-behållaren behöver du t.ex. inte kontrollera att en besökare är inloggad, detta gör behållaren åt dig.
2. Ett första exempel
Som vanligt blir det lättare att fatta om man först tittar på ett exempel. I detta exempel ska vi se till att man måste logga in för att kunna se undersidor till mappen secure/. För att nå vårt mål ska vi utföra följande steg:
3. tomcat-users.xml
Denna fil har sökvägen CATALINA_HOME/conf/tomcat-users.xml. Vi lägger till 2 rader:
Det viktiga här är att den nya användaren har rollen programmera som vi tidigare använt i web.xml som auth-constraint. Som tur är behöver man inte editera tomcat-users.xml för hand, det blir opraktiskt då man har ett stort antal användare.Tomcat har en admin-applikation som du kan logga in på, och där kan du lägga till och ta bort användare och roller via JSP-sidor, se
Tomcat admin .
<role rolename="programmera" />
<user username="olle" password="x3h" roles="programmera"/>
4. web.xml
Nu är det dags att uppdatera CATALINA_HOME/webapps/programmera/WEB-INF/web.xml. Nedan visas filens innehåll:
Koden innebär:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<display-name>Programmera</display-name>
<description>
This is a place for examples and tests.
</description>
<security-constraint>
<web-resource-collection>
<web-resource-name>Programmera secure area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected -->
<url-pattern>/secure/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- Anyone with one of the listed roles may access this area -->
<role-name>programmera</role-name>
</auth-constraint>
</security-constraint>
<!-- Default login configuration uses form-based authentication -->
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/secure/login.jsp</form-login-page>
<form-error-page>/secure/error.jsp</form-error-page>
</form-login-config>
</login-config>
</web-app>
5. Skriv JSP-sidorna
Först skriver vi en login.jsp-sida:
Spara till sökvägen CATALINA_HOME/webapps/programmera/secure/login.jsp. Här finns en del viktiga saker att lägga märke till:
<HTML>
<BODY>
<H1>Login</H1>
<FORM method="post" action='<%= response.encodeURL("j_security_check") %>' >
Namn: <INPUT type="text" name="j_username">
<BR/>Lösen: <INPUT type="password" name="j_password">
<BR/><INPUT type="submit" value="Logga in">
</FORM>
</BODY>
</HTML>
Först om dessa tre krav är uppfyllda kan man logga in på det skyddade området. Sedan skriver vi en error.jsp-sida:
Spara till sökvägen CATALINA_HOME/webapps/programmera/secure/error.jsp. Och till sist skriver vi en index.html-sida, som man får se om inloggningen lyckas:
<HTML>
<BODY>
<H1>Fel lösenord</H1>
<A href='<%= response.encodeURL("login.jsp") %>' >login</A>
</BODY>
</HTML>
Spara till sökvägen CATALINA_HOME/webapps/programmera/secure/index.html.
<HTML>
<BODY>
<H1>Välkommen till Programmeras säkra område</H1>
</BODY>
</HTML>
6. Testa applikationen
Först, starta om Tomcat för att få servern att läsa web.xml. Nu ska vi försöka titta på sidan index.html som ligger i det säkra området. Vi öppnar en webbläsare och skriver in localhost:7070/programmera/secure/index.html, men det vi får se är:
Vi har redan skapat en användare olle med lösen x3h i filen tomcat-users.xml. Om vi loggar in med fel lösenord kommer vi till felsidan:
Om vi loggar in med rätt lösenord får vi se index.html:
7. login-config
login-config bestämmer hur själva inloggningen ska gå till. Inloggningsförfarandet man väljer gäller för alla inloggningar inom webbapplikationen. Nedan listas den DTD som beskriver login-config:
Vi tittar på elementens betydelse:
<! ELEMENT login-config (auth-method?, realm-name?, form-login-config?)>
<! ELEMENT form-login-config (from-login-page, from-error-page)>
Element Obligatorisk Beskrivning auth-method Nej Någon av metoderna BASIC, DIGEST, FORM eller CLIENT-CERT. Dessa beskrivs nedan. realm-name Nej Detta element specifierar vilket realm-name HTTP-BASIC ska använda. Beskrivs nedan. form-login-config Nej Detta element krävs om man har valt FORM, här specifierar man sökvägarna till den login och fel-sida man kommer att använda.
De olika säkerhetsmetoderna beskrivs nedan:
Nedan visas hur en BASIC-inloggning ser ut:
Som vi ser nedan kan metoderna BASIC och FORM också använda HTTPS.
8. security-constraint
security-constraint används för att koppla en viss roll till en del av en webbapplikation. I detta element kan man även specifiera att SSL ska användas för säkerhetsmetoderna BASIC och FORM. Nedan listas den DTD som besriver security-constraint:
Vi tittar på betydelsen av de olika elementen i security-constraint:
<! ELEMENT security-constraint (display-name?, web-resource-collection+,
auth-constraint?, user-data-constraint?)>
<! ELEMENT web-resource-collection (web-resource-name, description?,
url-pattern*, http-method*)>
<! ELEMENT auth-constraint (description?, role-name*)>
<! ELEMENT user-data-constraint (description?, transport-guarantee)>
Element Obligatorisk Beskrivning display-name Nej Säkerhetskravets namn. web-resource-collection Ja Innehåller de resurser som ska skyddas. Resurserna kan vara en eller flera mappar under applikationens root. auth-constraint Nej Beskriver vilka roller som har rätt att komma åt resurserna. * betyder alla roller. Om ingen roll specifieras kan ingen användare se resurserna. Man kan också bestämma vilka HTTP-metoder som ska skyddas, men default är att alla HTTP-metoder skyddas, dvs GET,POST,PUT,DELETE. user-data-constraint Nej Detta element har ett underelement som heter transport-guarantee. Om transport-guarantee sätts till CONFIDENTIAL eller INTEGRAL kommer data att skickas över SSL (HTTPS) om man använder BASIC eller FORM som säkerhetsmetod. CONFIDENTIAL används för att förhindra spioneri, INTEGRAL används för att se till att innehållet inte kan förändras av en tredje part under överföringen.
Tyvärr har defaultinstallationen av Tomcat inte SSL, så man måste installera det själv, se
http://java.sun.com/webservices/docs/1.2/tutorial/doc/Security7.html .