Advance java session 19
Download as PPTX, PDF0 likes91 views
- Listeners allow monitoring of events in a web application. Main listener types are servlet context listeners, which monitor initialization and destruction of the servlet context, and session listeners, which monitor creation and destruction of sessions. Listeners are implemented by overriding appropriate methods in listener interfaces and declared in web.xml. They provide access to the servlet context and session to monitor changes.
Advance java session 19
- 1. Security
- 2. Agenda • Understanding major security concern • Declarative v/s programmatic security • Using form based authentication • Using BASIC authentication
- 3. Understanding major security concern • Two major components of Web application security - Authentication - Authorization
- 4. Understanding major security concern • Preventing unauthorized users from accessing sensitive data - Access restriction • Identifying which resources need protection • Identifying who should have access to them - Authentication • Identifying users to determine if they are one of the authorized ones • Preventing attackers from stealing network data while it is in transit. - Encryption (usually with SSL)
- 5. Declarative Security • Servlets or JSP’s need not have any security-aware code • Security aspects must be handled by the server - Prevent unauthorized access • Declare certain URL as protected in web.xml • Designate authentication method that server uses - Safeguard network data • Certain URL should only be accessed with SSL • If users uses regular HTTP then server should automatically redirect them to HTTPS(SSL) equivalent
- 6. Programmatic Security • Protected Servlets and JSP pages atleast partially manage their own security - Less dependency on server specific setting • To prevent unauthorized access - Each Servlets or JSP page must either authenticate the user or verify that the user has been authenticate previously • To safeguard network data - Each servlet and JSP page has to check the network protocol used to access it
- 7. Web-tier Authentication Schemes • HTTP basic authentication based - with or without SSL • Form-based authentication based - with or without SSL • Client-certificate authentication based - Has to use SSL • Digest authentication based - Does not need to use SSL
- 8. HTTP Basic Authentication • Web server collects user identification (user name and password) through a browser provided dialog box • Not secure since user name and password are in “easily decodable” form over the wire - Encoding scheme is Base64 - Someone can easily decode it - Not encrypted
- 9. Steps for Basic Authentication 1. Set up username, passwords, and roles (realms) 2. Tell web container that you are using Basic authentication 3. Specify which URLs (web resources) should be access- controlled (password-protected)
- 10. Steps for Setting up realms • <install-dir>/conf/tomcat-users.xml • Unencrypted: not secure but easy to set up and maintain <?xml version='1.0'?> <tomcat-users> <role rolename="manager"/> <role rolename="employee"/> <role rolename="admin"/> <user username="sang" password="sangPassword" roles="manager,employee"/> </tomcat-users>
- 11. Step II: Tell your application • In web.xml file of your web application <web-app> ... <security-constraint>...</security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>realm name</realm-name> </login-config> ... </web-app>
- 12. Form based Authentication • Web application collects user identification (user name, password, and other information) through a custom login page • Not secure since user name and password are in “easily decodable” form over the wire - Encoding scheme is Base64 - Someone can easily decode it - Not encrypted
- 14. Steps to configure Form Based Authentication 1. Set up username, passwords, and roles (realms) 2. Tell web container that you are using Form-based authentication 3. Create custom “Login page” 4. Create custom “Login failure error page” 5. Specify which URLs (web resources) should be access- controlled (password-protected)
- 15. Step I : Setting up realms • <install-dir>/conf/tomcat-users.xml • Unencrypted: not secure but easy to set up and maintain <?xml version='1.0'?> <tomcat-users> <role rolename="manager"/> <role rolename="employee"/> <role rolename="admin"/> <user username="sang" password="sangPassword" roles="manager,employee"/> </tomcat-users>
- 16. Step II: Tell your application • In web.xml file of your web application <web-app> ... <security-constraint>...</security-constraint> <login-config> <auth-method>FORM</auth-method> <realm-name>realm name</realm-name> </login-config> ... </web-app>
- 17. Step IV: Create Login Failure page • Can be HTML or JSP page • No specific content is mandated
- 18. Step III: Create a custom Login page • Can be HTML or JSP page • Contains HTML form like following <FORM ACTION="j_security_check" METHOD="POST"> … <INPUT TYPE="TEXT" NAME="j_username"> … <INPUT TYPE="PASSWORD" NAME="j_password"> … </FORM>
- 19. Summary • Main security issues - Preventing access by unauthorized user - Preventing attackers from stealing network data • Declarative security - Much less work than programmatic security - Requires server-specific password setup • Form-based authentication - Attempts to access restricted resources get redirected to login page. HTML form gathers username and password.Session tracking tracks authenticated users. • BASIC authentication - Attempts to access restricted resources results in dialog box. Dialog gathers username and password. HTTP headers track authenticated users.
- 20. Understanding Listeners • JSP is a template page technology - High level abstraction of Servlets • Separation of presentation from logic • Even non java programmer can create JSP pages with reasonable ease
- 21. Available Listeners • Servlet context listeners. - These listeners are notified when the servlet context (i.e.,the Web application) is initialized and destroyed. • Servlet context attribute listeners. - These listeners are notified when attributes are added to,removed from, or replaced in the servlet context. • Session listeners. - These listeners are notified when session objects are created, invalidated, or timed out. • Session attribute listeners. - These listeners are notified when attributes are added to, removed from, or replaced in any session.
- 22. Creating a Listeners • Implement the appropriate interface. - Use ServletContextListener, ServletContextAttributeListener, - HttpSessionListener, or HttpSessionAttributeListener. • Override the methods needed to respond to the events of interest. - Provide empty bodies for the other methods in the interface. • Access the important Web application objects. - Six objects that you are likely to use in event-handling methods: • The servlet context • The name of the servlet context attribute that changed • The value of the servlet context attribute that changed • The session object • The name of the session attribute that changed
- 23. Creating a Listeners • Use these objects. - This process is application specific, but there are some common themes. For example, with the servlet context, you are most likely to read initialization parameters getInitParameter), store data for later access (setAttribute), and read previously stored data (getAttribute). • Declare the listener. - You do this with the listener and listener-class elements of the general Web application deployment descriptor (web.xml) or of a tag library descriptor file. • Provide any needed initialization parameters. - Servlet context listeners commonly read context initialization parameters to use as the basis of data that is made available to all servlets and JSP ages. You use the context-param web.xml element to provide the
- 24. Monitoring Creation and Destruction • The ServletContextListener class responds to the Initialization and destruction of the servlet context. - These events correspond to the creation and shutdown of the Web application itself. • ServletContextListener is most commonly used to - Set up application-wide resources like database connection pools - Read the initial values of application-wide data that will be used by multiple servlets and JSP pages.
- 25. Implementing ServletContextListener • Implement the ServletContextListener interface. • Override contextInitialized and contextDestroyed. - contextInitialized is triggered when the Web application is first loaded and the servlet context is created. Most common tasks: • Creating application-wide data (e.g., by reading context init params) • Storing that data in an easily accessible location . - contextDestroyed is triggered when the Web application is being shut down and the servlet context is about to be destroyed. Most common task: • Releasing resources (e.g. closing connections). • Obtain a reference to the servlet context. - The contextInitialized and contextDestroyed methods each take a ServletContextEvent as an argument. - The ServletContextEvent class has a getServletContext method that returns the servlet context
- 26. Implementing ServletContextListener • Use the servlet context. - Read initialization parameters: getInitParameter - Store data:setAttribute - Make log file entries: log. • Declare the listener. <listener> <listener-class>package.Listener</listener-class> </listener> • Provide needed initialization parameters. <context-param> <param-name>name</param-name> <param-value>value</param-value> </context-param>
- 27. Implementing ServletContextAttributeListener • Implement ServletContextAttributeListener • Override attributeAdded, attributeReplaced, and attributeRemoved. - attributeAdded is triggered when a new attribute name is first added to the servlet context. - attributeReplaced is triggered when a new value is assigned to an existing name. attributeAdded is not triggered in this case. The old value is obtained via event.getValue and the new value is obtained via context. - getAttribute. attributeRemoved is triggered when a servlet context attribute is removed altogether. • Obtain references to the attribute name, attribute value, and servlet context. - Call the following methods of the event object: getName,getValue, and getServletContext
- 28. Implementing ServletContextAttributeListener • Use the objects. - You normally compare attribute name to a stored name to see if it is the one you are monitoring. The attribute value is used in an application-specific manner. The servlet context is usually used to read previously stored attributes (getAttribute), store new or changed attributes (setAttribute), and make entries in the log file (log). • Declare the listener. - Use the listener and listener-class elements to list the fully qualified name of the listener class, <listener> <listener-class> somePackage.SomeListener </listener-class> </listener>
- 29. Recognizing Session Creation and destruction • Implement the HttpSessionListener interface. • Override sessionCreated and sessionDestroyed. - sessionCreated is triggered when a new session is created. - sessionDestroyed is triggered when a a session is destroyed. This destruction could be due to an explicit call to the invalidate method or because the elapsed time since the last client access exceeds the session timeout. - Multithreaded access is possible. Synchronize if necessary. • Obtain a reference to the session and possibly to the servlet context. - Each of the two HttpSessionListener methods takes an HttpSessionEvent as an argument. The HttpSessionEvent class has a getSession method that provides access to the session object.You almost always want this reference; you occasionally also want a reference to the servlet context. If so, first obtain the session object and then call getServletContext on it
- 30. Recognizing Session Creation and destruction • Use the objects. - One of the only methods you usually call on the session is setAttribute. Do this in sessionCreated if you want to guarantee that all sessions have a certain attribute. - Wait! What about getAttribute? Nope. In sessionCreated, there is nothing in the session yet, so getAttribute is pointless. In addition, all attributes are removed before sessionDestroyed is called, so calling getAttribute is also pointless there. If you want to clean up attributes that are left in sessions that time out, you use the attributeRemoved method of HttpSessionAttributeListener. So, sessionDestroyed is mostly reserved for listeners that are simply keeping track of the number of sessions in use. • Declare the listener. - In web.xml or the TLD file, use listener and listener-class to list fully qualified name of listener class, as below. <listener> <listener-class>package.SomeListener</listener-class> </listener>
- 31. Using HttpSessionAttributeListener • Implement HttpSessionAttributeListener. • Override attributeAdded, attributeReplaced, and attributeRemoved. - attributeAdded is triggered when a new attribute name is first added to a session. - attributeReplaced is triggered when a new value is assigned to an existing name. attributeAdded is not triggered in this case. The old value is obtained via event.getValue and the new value is obtained via session.getAttribute. - attributeRemoved is triggered when a session attribute is removed altogether. This removal can be due to an explicit programmer call to removeAttribute, but is more commonly due to the system removing all attributes of sessions that are about to be deleted because their timeout expired.
- 32. Using HttpSessionAttributeListener • Obtain references to the attribute name, attribute value, session, & ServletContext. - The HttpSessionAttributeListener methods take an HttpSessionBindingEvent as args. HttpSessionBindingEvent has three useful methods: getName (name of attribute that was changed), getValue (value of changed attribute—new value for attributeAdded and previous value for attribute Replaced and attributeRemoved), and getSession (the HttpSession object). If you want access to the servlet context, first obtain the session and then call getServletContext on it. • Use the objects. - The attribute name is usually compared to a stored name to see if it is the one you are monitoring. The attribute value is used in an application-specific manner. The session is usually used to read previously stored attributes (getAttribute) or to store new or changed attributes (setAttribute). • Declare the listener. - Use listener and listener-class in web.xml as before. `
- 33. Summary of Listeners - Servlet context listeners. • Notified when servlet context is initialized and destroyed. - Servlet context attribute Listeners. • Notified when context attributes are added/removed/replaced - Session listeners. • Notified when sessions are created, invalidated, or timed out. - Session attribute listeners. • Notified when session attributes are added/removed/replaced