1. Securing web applications using Java EE
Prof Jim Briggs

2. Introduction Security is a pervasive issue Three aspects of security:
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 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) Application
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