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

1. HTTP and other authentication mechanisms2. Application-managed security3. Container-managed security

1. Declarative2. Programmatic

4

AUTHENTICATION MECHANISMS

5

HTTP authentication 1• HTTP provides facilities for authentication

– https://tools.ietf.org/html/rfc7235 • 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 methodpublic 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 methoduser = 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 accessuser = 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