Download Securing web applications using Java EE

Securing web applications using
Java EE
Dr Jim Briggs
1
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
Three areas to cover
1. HTTP and other authentication mechanisms
2. Application-managed security
3. Container-managed security
1. Declarative
2. Programmatic
3
AUTHENTICATION MECHANISMS
4
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!
5
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
Transporting passwords
• Problem: Basic authentication sends
passwords in clear
• Digest authentication better – only sends
password digest
• Secure Sockets Layer (SSL)
• HTTPS – secure HTTP
7
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
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
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
APPLICATION MANAGED SECURITY
11
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
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
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
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
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
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
CONTAINER MANAGED SECURITY
18
Container managed security
• Standard set of functionality
• Security can span a set of separate web
applications (single sign-on)
19
Java EE security annotations
•
•
•
•
•
@PermitAll
@DenyAll
@RolesAllowed
@DeclareRoles
@RunAs
20
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
Accessing a Java EE application
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