Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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