1. Securing web applications using Java EE Dr Jim Briggs 1

2. Introduction Security is a pervasive issue – All e-commerce systems require it Three aspects of security: – Confidentiality – Integrity – Availability To achieve these, we distinguish two functions: – authentication: how users prove who they say they are – authorisation: how access to specific resources is allowed or denied 2

3. Three areas to cover 1.HTTP and other authentication mechanisms 2.Application-managed security 3.Container-managed security 1.Declarative 2.Programmatic 3

4. AUTHENTICATION MECHANISMS 4

5. HTTP authentication 1 HTTP provides facilities for authentication – http://www.ietf.org/rfc/rfc2617.txt http://www.ietf.org/rfc/rfc2617.txt HTTP authentication operates on a challenge/response paradigm – If server receives a request for an access-protected object, and an acceptable Authorization header is not sent, the server responds with a "401 Unauthorized" status code. – The client must then resend the request with an Authorization header. Most browsers will prompt the user for a username and password. Most browsers cache this for the duration of the browser session; some will allow the user to save it between sessions. We leave it as an exercise for the reader as to whether storing a password on the client machine is secure or not! 5

6. HTTP authentication 2 Two mechanisms – Basic Authentication – passes usernames and passwords in clear text (actually in Base64 format, but this is easily translatable) – Digest Authentication – scrambles the password by sending a checksum (by default, MD5) of: the username the password a given nonce value (sent by the server with the 401 response) the HTTP method the requested URI Why are all of these necessary? HTTP authentication operates within a realm. A realm is essentially the store (e.g. file, database,...) against which user credentials are checked. 6

7. Transporting passwords Problem: Basic authentication sends passwords in clear Digest authentication better – only sends password digest Secure Sockets Layer (SSL) HTTPS – secure HTTP 7

8. Non-HTTP authentication Provide user with a login form (HTML) – Boxes for username and password – Typically provides link for forgotten password Username and password sent as normal form data Server-side processes it like any other form data 8

9. Identifying a logged-in user If using HTTP authentication, browser will resend credentials with all relevant requests – Server effectively rechecks each request If using application authentication, server will store user-id in session – Application needs to recheck every request 9

10. Java Authentication and Authorization Service (JAAS) Common to all Java platforms (apps, applets and servlets) Two basic concepts (interfaces): – Principal: represents an (authenticated) user – Role: group of principals who share common set of permissions 10

11. APPLICATION MANAGED SECURITY 11

12. Common features Mechanism to test authorisation – Code in every servlet Or every servlet extends one with the security in-built – Filter applied to all relevant servlets – Framework-specific mechanism (e.g. Interceptor in Struts2) – Java EE standard mechanism Mechanism to force authentication – Via HTTP – Via a form – Store result so that it can be reused 12

13. Java EE facilities request.getRemoteUser() request.getUserPrincipal() request.isUserInRole(role) Use session attributes to store the user's identity Use cookies to store username and password (can be persistent between browser sessions) 13

14. Checking login: business method public User login(String username, String password) throws Exception { Query q = em.createQuery("select p from Person p where p.username = :username and p.password = :password"); q.setParameter("username", username); q.setParameter("password", password); try { User u = (User) q.getSingleResult(); return u; } catch (NoResultException ex) { return null; } 14

15. Checking login: controller method user = userMgmt.login(username, password); if (user != null) { request.getSession().setAttribute("LoggedInUser", user); setMessage("Logged in as " + user.getUsername()); log.info(user.getUsername() + " logged in successfully"); return SUCCESS; } else { setMessage("Username and/or password not known"); this.addActionError("Username and/or password not known"); return Constants.LOGIN_FAILED; } 15

16. Authorisation: check access user = request.getSession().getAttribute("LoggedInUser"); if (user == null) { // not logged in! //redirect to a login page if (user.inRole("admin") { if (securityManager.isUserinRole(user, "admin")) { if (securityManager.isAdmin(user)) { 16

17. Pros and cons of application-managed security Pro: complete control Pro: can fine-tune for performance Con: you might forget to put it in a method Con: managing site-wide may be a problem 17

18. CONTAINER MANAGED SECURITY 18

19. Container managed security Standard set of functionality Security can span a set of separate web applications (single sign-on) 19

20. Java EE security annotations @PermitAll @DenyAll @RolesAllowed @DeclareRoles @RunAs 20

21. Java EE Configuration Container (e.g. Glassfish) – Configure: realm (and implementation) for container to use security role mappings (via glassfish-web.xml) – assign principals and/or groups to roles Application – web.xml login configuration – basic/digest/form/certificate security roles security constraints – URL constraints – authentication constraints – data (transport) constraint 21

22. Accessing a Java EE application 22

23. Accessing a Java EE application 23

24. Accessing a Java EE application 24

25. Accessing a Java EE application 25

26. Accessing a Java EE application 26