Securing web applications using Java EE
description
Transcript of 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
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