Securing web applications using Java EE

1. Securing web applications using Java EE Dr Jim Briggs

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

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

4. Authentication mechanisms

5. HTTP authentication 1 • HTTP provides facilities for authentication • 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!

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.

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

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

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

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

11. Application managed security

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

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)

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; } }

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; }

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)) {

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

18. Container Managed Security

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

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

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

22. Accessing a Java EE application

23. Accessing a Java EE application

24. Accessing a Java EE application

25. Accessing a Java EE application

26. Accessing a Java EE application