Security and Authorization issues

1. Security and Authorization issues

2. 4 levels or senses of the security issue to look at • Authentication • Authorization • Integrity • Confidentiality

3. Security • Client wants to be sure she is talking to a legitimate server (authentication) and also wants to make sure information passes is confidential. The server wants to make sure the client is who she claims to be, and that information remains confidential. Both sides want to be sure the information passes arrives without tampering.

4. 2.2 security • Web servers are not required to implement all servlet 2.2 API security mechanisms to be 2.2 compliant. • Some implement just parts of it and some implement none at all. • A server must implement all to be J2EE compliant.

5. Role-based authentication • Tags in web.xml and other xml files can specify roles and restrict resource access to those in certain roles. • The deployment descriptor (web.xml) specifies the type of access granted to each role but doesn’t map roles to users. Server-specific tools used during application deployment assign roles, which may come from text, db tables, OS, server files (like tomcat users) and so on.

6. Salary servlet example • We wish to restrict access to a servlet that gives out salary information to managers: import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class SalaryServer extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/plain"); PrintWriter out = res.getWriter(); out.println("Top-secret information:"); out.println("Everyone else gets paid more than you!"); } }

7. Tomcat roles • On tomcat, roles are assigned in a tomcat-users file in the conf directory of tomcat. (This was true at the time the text was written and seems still to be the case). • On another server (container), another sort of mechanism might define these roles.

8. tomcat-users.xml file in conf directory • This is already defined and has some entries in it presumably for jsp or servlet examples that come with Tomcat. • You should have added yourself to it as admin, or looked at it already to get an admin pw, to run the manager utility we looked at earlier. • I added the tomcat-users from the text chapter 8 example file to my users. • The web.xml file security constraint tag then specifies which security roles may access a resource. In the DTD, tags are ordered: <security-constraint>, <login-config>, then <security-role> • The text acknowledges that the web.xml does get a bit complicated and that for handling security issues a graphical manipulation tool (like your proj 2) might be best.

9. Security constraint • The deployment descriptor (next slide) protects the resource (in this example, a servlet named secret) GET and POST methods from anyone who hasn’t logged in as manager using BASIC authentication. The rest of the site is not restricted. • The security constraint tag protects a web resource collection so access is only granted for roles specified in <auth-constraint> • Each <web-resource-collection> contains a name, any number of urls to protect and any number of http methods for which access is restricted. url patterns may use wildcard characters.

10. web.xml file additions for this example <security-constraint> <web-resource-collection> <web-resource-name> SecretProtection </web-resource-name> <url-pattern> /servlet/SalaryServer </url-pattern> <url-pattern> /servlet/secret </url-pattern> <http-method> GET </http-method> <http-method> POST </http-method> </web-resource-collection> <auth-constraint> <role-name> manager </role-name> </auth-constraint> </security-constraint>

11. web.xml file additions <login-config> <auth-method> BASIC <!– coices are: BASIC, DIGEST, FORM, CLIENT-CERT --> </auth-method> <realm-name> Default <!-- optional, only useful for BASIC --> </realm-name> </login-config> <security-role> <role-name> manager </role-name> </security-role>

12. conf/tomcat-users.xml <?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="tomcat"/> <role rolename="role1"/> <user username="tomcat" password="tomcat" roles="tomcat"/> <user username="both" password="tomcat" roles="tomcat,role1"/> <user username="role1" password="tomcat" roles="role1"/> <user name="Dilbert" password="dnrc" roles="engineer" /> <user name="Wally" password="iluvalice" roles="engineer,slacker" /> <user name="MrPointyHair" password="MrPointyHair" roles="manager,slacker" /> </tomcat-users>

13. Server prompts for user info

14. SalaryServer gives info

15. Once logged in • You may continue to access resources here after login without having to reenter pw. • As mentioned in earlier ppts, the client browser session hands the server the name/pw each time a page is requested.

16. If Dilbert tries to login

17. Retrieving authorization information • Servlet API supports two methods getRemoteUser() and getAuthType() from chapter 4 for getting user information. • API 2.2 introduces a new method (on HttpServletRequest) getUserPrincipal(). A principal is the entity being authenticated, a group, a login, a corporation. • getRemoteUser is basically available for CGI compatibility and we looked at this briefly in chapter 7. getUserPrincipal() is the preferred way to authenticate a user. • isUserinRole() returns true only if the user is in a particular role.

18. Retrieving authorization information • These methods allow servlets to handle some of the authentication process. Role aliases can be used in the deployment descriptor. • The following excerpt would enable the servlet to use the alias mgr for the role manager. This would be useful for integrating servlets from different web applications. Aliases are configured per servlet. <servlet>…</servlet-class><security-role-ref><role-name>mgr</role-name><role-link>manager</role-link> </security-role-ref> </servlet>

19. Getting client info public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html"); PrintWriter out = res.getWriter(); out.println("<HTML><HEAD><TITLE>AuthenticationSnoop</TITLE></HEAD><BODY>"); out.println("<H1>This is a password protected resource</H1>"); out.println("<PRE>"); out.println("User Name: " + req.getRemoteUser()); String name = (req.getUserPrincipal() == null) ? null : req.getUserPrincipal().getName(); out.println("Principal Name: " + name); out.println("Authentication Type: " + req.getAuthType()); out.println("Is a Manager: " + req.isUserInRole("manager")); out.println("</PRE>"); out.println("</BODY></HTML>"); }

20. This servlet running in tomcat. (Obviously, we need to combine this example with a Basic or Form-based authentication)

21. Pasting code from AuthenticationSnoop into SalaryServer

22. Pasting code from AuthenticationSnoop into SalaryServer

23. Form-based authentication • Servlets can rely on html forms to do authentication as well. A friendly login page greets site visitors. This is nicer than the generic prompt the browser gives in the server’s authentication scheme previously described. • Form-based authentication is built into the servlet 2.2 API.

24. Form-based authentication • If the server receives a request for a restricted resource, it looks to see if the user has logged in. If it finds a Principal (from last example) it compares with those Principal values allowed to access the recource. If no principal is located the client is redirected to a login page.

25. changes to login-config for web.xml <login-config> <auth-method> FORM </auth-method> <form-login-page> /loginform.html </form-login-page> <form-error-page> /errorpage.html </form-error-page> </form-login-page> </login-config>

26. Html form • Must use POST to server with action j_security_check and values j_username and j_password

27. Html form <HTML> <TITLE>Login</TITLE> <BODY> <FORM METHOD=POST ACTION=j_security_check> <CENTER> <TABLE BORDER=0> <TR><TD COLSPAN=2> <P ALIGN=center> Welcome! Please enter your Name<br> and Password to log in. </TD></TR> <TR><TD> <P ALIGN=right><B>Name:</B> </TD> <TD> <P><INPUT TYPE=TEXT NAME="j_username" VALUE="" SIZE=15> </TD></TR> <TR><TD> <P ALIGN=RIGHT><B>Password:</B> </TD> <TD> <P><INPUT TYPE=PASSWORD NAME="j_password" VALUE="" SIZE=15> </TD></TR> <TR><TD COLSPAN=2> <CENTER> <INPUT TYPE=submit VALUE=" OK "> </CENTER> </TD></TR> </TABLE> </FORM> </BODY></HTML>

28. In IE

29. Error page <HTML> <TITLE>Login Denied</TITLE> <BODY> Sorry, your login was denied. Please hit the Back button to try again. </BODY></HTML>

30. Error page

31. I get null pointer exceptions trying to run the last example… I have to revisit this example

32. CustomAuthorization • A servlet can handle its own custom authorization procedures, looking for names/passwords in a database for example. In a limited context, this servlet might build a hashtable of priviledged users: users.put("Wallace:cheese", "allowed"); users.put("Gromit:sheepnapper", "allowed"); users.put("Penguin:evil", "allowed");

33. CustomAuth

34. CustomAuth

35. An invalid login yields an error

36. Custom Authorization with html forms <HTML> <TITLE>Login</TITLE> <BODY> <FORM ACTION=/servlet/LoginHandler METHOD=POST> <CENTER> <TABLE BORDER=0> <TR><TD COLSPAN=2> <P ALIGN=CENTER> Welcome!<br> Please enter your Account Number,<br> Password, and PIN to log in. </TD></TR> <TR><TD> <P ALIGN=RIGHT><B>Account:</B> </TD> <TD> <P><INPUT TYPE=TEXT NAME="account" VALUE="" SIZE=15> </TD></TR> <TR><TD> <P ALIGN=RIGHT><B>Password:</B> </TD> <TD> <P><INPUT TYPE=PASSWORD NAME="password" VALUE="" SIZE=15> </TD></TR> <TR><TD> <P ALIGN=RIGHT><B>PIN:</B> </TD> <TD> <P><INPUT TYPE=PASSWORD NAME="pin" VALUE="" SIZE=15> </TD></TR> <TR><TD COLSPAN=2> <CENTER> <INPUT TYPE=SUBMIT VALUE=" OK "> </CENTER> </TD></TR> </TABLE> </FORM> </BODY></HTML>

37. Custom Authorization with html forms

38. Custom Authorization with html forms • A client who tries to get to the resource without logging in is redirected to this page and then directed back to the protected resource. • Secret data is revealed in the protected resource only if session information indicates that the client has already logged in.

39. ProtectedResource import java.io.*; import java.util.*; import javax.servlet.*; import javax.servlet.http.*; public class ProtectedResource extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/plain"); PrintWriter out = res.getWriter(); // Get the session HttpSession session = req.getSession(); // Does the session indicate this user already logged in? Object done = session.getAttribute("logon.isDone"); // marker object if (done == null) { // No logon.isDone means she hasn't logged in. // Save the request URL as the true target and redirect to the login page. session.setAttribute("login.target", HttpUtils.getRequestURL(req).toString()); res.sendRedirect("/login.html"); return; } // If we get here, the user has logged in and can see the goods out.println("Unpublished O'Reilly book manuscripts await you!"); }}

40. When ProtectedResource is entered as URL:

41. LoginHandler servlet returns true public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html"); PrintWriter out = res.getWriter(); // Get the user's account number, password, and pin String account = req.getParameter("account"); String password = req.getParameter("password"); String pin = req.getParameter("pin"); // Check the name and password for validity if (!allowUser(account, password, pin)) {////see below …a dummy method that doesn’t really check out.println("<HTML><HEAD><TITLE>Access Denied</TITLE></HEAD>"); out.println("<BODY>Your login and password are invalid.<BR>"); out.println("You may want to <A HREF=\"/login.html\">try again</A>"); out.println("</BODY></HTML>"); } else { // Valid login. Make a note in the session object. HttpSession session = req.getSession(); session.setAttribute("logon.isDone", account); // just a marker object… sets login complete as session value // Try redirecting the client to the page he first tried to access try { String target = (String) session.getAttribute("login.target"); if (target != null) { res.sendRedirect(target); return; } } catch (Exception ignored) { } // Couldn't redirect to the target. Redirect to the site's home page. res.sendRedirect("/"); } } protected boolean allowUser(String account, String password, String pin) { return true; // trust everyone }}

42. After being cleared by LoginHandler

43. Digital certificates • Digital certificates provide a higher level of authentication, confidentiality and integrity than BASIC or FORM-based authentication. • Public key cryptography is the mechanism by which data is transmitted. In such a system, both sides have two keys, a public key and a private key, used to encrypt and decrypt information. The public key is freely distributed. The keys are related but one can’t be derived from the other. • Large prime numbers are used to generate pairs of asymmetric keys: each can decode a message encoded with the other. Keys may be 1024 or 2048 bits in length.

44. Digital certificates • Keys are too big to type in manually, and are stored on disks as “digital certificates”. • Private keys are stored encrypted on disk protected by a passphrase. • Digital certificates can be issued by 3rd party vendors or generated by software. • Secure-aware applications like browsers and servers can load the certificates.

45. Digital certificates • How is authentication provided? The keys are asymmetric… a message encoded/decoded with a private key can also be encoded/decoded with the corresponding public key to guarantee authorship. • It does take more work to do this, so often after identities have been established with asymmetric keys, symmetric keys are exchanged for passing information. • Messages sent using large (>=128 bits) keys are very secure. • Third party certificate authorities often “vouch for” parties exchanging public keys. There are companies (VeriSign) which provide levels of increased guarantee or trust at increasing price.

46. Secure Sockets Layer • The SSL sits between application-level (HTTP) and lower level transport protocol (TCP/IP). • It uses public key cryptography to encrypt all client/server communication. This is the de-facto security standard for online communication. • This forms the basis for TLS (Transport Layer Security) currently under development by the IETF.

47. Secure Sockets Layer • SSL V2 provides authentication of the server, confidentiality and integrity. • A user connects to a secure site using HTTPS (= HTTP+SSL) protocol. • The server signs its public key with its private key and returns it to the browser. • The browser uses the server’s public key to verify that the person who signed the key owns it. • The browser checks to see if a certificate authority signed the key. If not, the browser asks the user if the key can be trusted and proceeds. • The client generates an asymmetric DES key for the session which is encrypted with the server’s public key and sent to the server. This new key is used to encrypt subsequent transactions. • Once you have obtained and installed an appropriate server certificate, and appropriately configured the server, all the SSL details are handled seamlessly and beloiw the layer of servlets.

48. SSL3 • SSL V3 provides client authentication providing support for client certificates. • Clients are supplied certificates like servers. After the client has authenticated the server, the server requests the client’s certificate. The server performs the same authorization process the client just completed. Browsers often require a client pw before sending a certificate. • This does provide an additional seamless layer of security, but now clients must obtain and install certificates and servers must (often) maintain a database of public keys, as well as implementing SSL V3.

49. web.xml <securtiy-constraint> <web-resource-collection> …</web-resource-collection> <auth-constraint> <role-name> manager </role-name> </auth-constraint> <user-data-constraint> <transport-guarantee> CONFIDENTIAL </transport-guarantee> </user-data-constraint> </security-constraint>

50. SSL3 • The deployment descriptor indicates that the application requires HTTPS. • The transport guarantee is INTEGRAL or CONFIDENTIAL. The later entails the former. Integral means no change has taken place to the message in transit and the latter means no unauthorized third party has seen the transmission. • The server may implement the security levels. Generally, 56-bit DES encryption is considered sufficient for integral but not for confidential.