INFITT01 - Internettechnologie WEEK 7
Programma • Beveiliging • Filters
Security • Beveiliging 4 belangrijke aspecten: – – – –
Authenticatie (is de ‘persoon’ wie hij/zijn zegt dat hij/zij is?) Autorisatie (welke rechten?) Vertrouwelijkheid (luistert er niemand mee?) Data integriteit: (data niet veranderd onderweg?)
Authenticatie - basic
Authenticatie – form based
Authenticatie - verder • Client based authenticatie – public keys die aanwezig moet zijn op de client – meer secure dan basic/form
• Mutual authenticatie – client en server authentiseren elkaar d.m.v. certificaten
• Digest (=verteren) – wachtwoord encrypted verstuurd – veiliger dan basic/form – weinig gebruikt
Authenticatie – configuratie • In WEB.XML:
BASIC FORM /loginPage.html /errorPage.html
Authenticatie • In geval van form based authenticatie in login.jsp:
• Vet gedrukte namen niet wijzigen! • Gebruikers toevoegen in bestand of database • Meer info: http://download.oracle.com/javaee/1.4/tutorial/doc/Security5.html
Autorisatie • • • •
Voor autorisatie heb is authenticatie nodig! Rechten (toegang) gebruiker Programmeren of declaratief (voorkeur in web.xml) Definieer rollen op basis waarvan toegang tot een resource wordt bepaald. • Gebruiker heeft een of meerdere rollen
Autorisatie - vendor • TOMCAT in config:
<user username”Frits” password=”Frits” roles=”Admin,Member”/>
• In web.xml: <security-role>
Admin Guest Member
Autorisatie <security-constraint> <web-resource-collection> <web-resource-name>mijnwebapp
/Beer/AddRecipe/* /Beer/Review/* GET POST Admin <security-role> is bedoeld voor vendor specifieke mapping en het benoemen/definiëren van je rollen die je gaat gebruiken in
Autorisatie •
Authorizatie....
<web-resource-name>
– verplicht (ook al doe je er waarschijnlijk niets mee) •
– minimaal 1 – mapping zoals bij servlets •
– optioneel – met url-pattern wordt bepaald wie in de auth-constraint toegang heeft met bepaalde http methode. – NIET gespecificeerd → ALLE methodes hebben de constraint! Dus resources ALLEEN toegankelijk voor auth-constraint roles! •
– – – – •
Optioneel geldt voor alle resources in <web-resource-collection> aanwezig → container MOET authenticatie doen voor de urls niet aanwezig → container MOET niet geauthentiseerde toegang toestaan
– optioneel
Autorisatie • http-method en url-pattern bepalen samen wie in auth-constraint toegang heeft. – alleen GET en POST methodes zijn geldig voor Admin om toegang tot de resources te krijgen – role die niet in auth-constraint staat kan wel een PUT, TRACE, HEAD, DELETE en OPTIONS doen op de resources (alleen als je servlet die methodes ondersteunt met bijv. doPut())
• • Een lege betekent dat NIEMAND direct toegang heeft (maar je kunt wel indirect toegang hebben via bijv. een JSP). – GEEN auth-constraint, dan • kan iedereen een constraint request maken (met de toegestane http methodes) • hetzelfde als * (role-names zijn case sensitive)
autorisatie • Bij meerdere <web-resource-collection> – Indien er overlap is tussen 2 web-resource-collection's (url-pattern gelijk en http-method, rollen verschillend) dan: • • • •
combineer de rollen en alle rollen hebben toegang rol * laat iedereen toe lege auth-constraint met alle andere dingen laat NIEMAND toe. geen auth-constraint met iets anders laat iedereen toe.
Data integriteit en vertrouwelijkheid <security-constraint> <web-resource-collection> … Admin <user-data-constraint> CONFIDENTIAL
Data integriteit en vertrouwelijkheid • Waardes voor : – NONE = geen van beide – INTEGRAL • data mag niet veranderd worden onderweg • dwingt geen complete secure connection af zoals ssl
– CONFIDENTIAL • data mag niet gezien worden onderweg
• Vrijwel elke container gebruikt SSL en dus zijn INTEGRAL en CONFIDENTIAL nagenoeg hetzelfde. Je kunt maar 1 <userdata-constraint> per <security-constraint> hebben.
Data integriteit en vertrouwelijkheid
Data integriteit en vertrouwelijkheid
Data-integriteit en vertrouwelijkheid
Filters • • • •
soort servlets configureren in web.xml ‘achtergrond’ classes taken op basis van bijv. een url
• Implementeer de javax.servlet.Filter interface: – void destroy() – void init(FilterConfig filterConfig) – void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
Filters - toepassing • • • •
Authenticatie Data conversie/compressie Logging en auditing Encryptie
Filters - werking Er komt een request binnen voor servlet A. Op deze url staan ook 2 filters geconfigureerd. Eerst wordt filter 1 aangeroepen, vervolgens door chain.doFilter filter 7 en dan de servlet. Terug in omgekeerde volgorde. Servlet
Filter 1
Filter 7
Filter 7
Filter 7
Filter 1
Filter 1
Filter 1
Filter 1
Filters - configuratie
Filters....wat zijn dat(4)?
In WEB.XML: Naam // verplicht foo.mijnfilter // verplicht <param-name>paramnaam <param-value>waarde
Filters - configuratie • op basis van url-pattern: Naam *.do
• op basis van servlet: Naam <servlet-name>mijnServlet
Filters • Indien meer dan 1 filter: – geen ‘winnend’ filter zoals bij servlets – alle ‘matching’ filter worden uitgevoerd. • eerst url-pattern filters in volgorde als gedeclareerd in DD • dan de servlet-name filters in volgorde als gedeclareerd in DD
Filters • LET OP: Als je nog iets met de response wil doen tijdens de output, dan moet je de response wrappen. De container buffert de output niet voor de filters. • Utility classes: – – – –
ServletRequestWrapper ServletResponseWrapper HttpServletRequestWrapper HttpServletResponseWrapper
Volgorde initialiseren Container doet het volgende met info in web.xml: 1. 2. 3. 4.
Instantiëren listeners De 'contextInitialized' methode aanroepen van listeners die de ServletContextListener interface implementeren Initialiseren filters Initialiseren servlets die bij starten van de container moeten worden geladen
