260 likes | 403 Views
Securing web applications using Java EE. Dr Jim Briggs. 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:
E N D
Securing web applications using Java EE Dr Jim Briggs
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
Three areas to cover • HTTP and other authentication mechanisms • Application-managed security • Container-managed security • Declarative • Programmatic
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!
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.
Transporting passwords • Problem: Basic authentication sends passwords in clear • Digest authentication better – only sends password digest • Secure Sockets Layer (SSL) • HTTPS – secure HTTP
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
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
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
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
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)
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; } }
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; }
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)) {
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
Container managed security • Standard set of functionality • Security can span a set of separate web applications (single sign-on)
Java EE security annotations • @PermitAll • @DenyAll • @RolesAllowed • @DeclareRoles • @RunAs
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