Are You Recruiter/Hiring Manager?
Cloud-based Candidate Screening | Online Tests
PMP 1600 Questions
PMP 1600 Questions
1600 PMP mock questions 1400 CAPM mock questions 800 SCJP 6 mock questions 600 OCAJP 7 mock questions 590 OCPJP 7 mock questions 556 SCWCD 5 mock questions 500 OCEJWCD 6 mock questions pdfDownload (java,struts, hibernet etc)

Tutorial Home

Hibernate

  • Advantage of Hibernate over JDBC
  • Hibernate Setup with an web Application
  • First Hibernate Application
  • Hibernate mapping with Database TABLE
  • Hibernate Data Type-Java Data Type - SQL Data Type mapping
  • One to Many Relation in Hibernate
  • One to Many Relation in Hibernate bi-directional
  • Many to Many Relation in Hibernate
  • HQL: The Hibernate Query Language
  • Criteria Queries
  • Criteria Queries : Equal (eq), Not Equal(ne), Less than (le), greater than (gt),greater than or equal(ge) and Ordering the results
  • Criteria Queries: And OR conditions
  • Hibernate generator to generate id (primary key)
  • prevent concurrent update in Hibernate,slate object updatation in Hibernate,version checking in Hibernate

    Struts


  • Model View Controller (MVC)
  • Model View Controller (MVC)
  • Struts Flow-How Struts Works?
  • Struts Tutorial - Struts Setup- First Struts Action class setup
  • Message Resources
  • Validation Framework
  • Validation Framework-client side
  • ForwardAction
  • IncludeAction
  • DispatchAction
  • LookupDispatchAction
  • DynaActionForm
  • DynaActionForm
  • Struts Tutorial - Mutli-click prevention using struts tokens-Prevent Duplicate Submission
  • Logic Iterate Map and List

    JSP


  • JSP Tutorial
  • Introduction to JSP
  • JSP Comments
  • JSP Syntax
  • JSP Scripting Elements :Scriptlet, expression, declaration
  • JSP Directives
  • implicit objects in JSP
  • JSP Actions
  • Introduction to JSP
  • jsp:useBean
  • The jsp:setProperty Action
  • The jsp:getProperty Action
  • Introduction to JSP

    Spring


  • Spring Tutorial
  • Introduction to Spring
  • Benefits of Using Spring Framework
  • Inversion of Control in Spring
  • Introduction to BeanFactory
  • Dependency Injection in Spring
  • Collections Setter Injection
  • Bean Scopes in Spring
  • Spring IOC Setup Step by Step
  • Bean Lifecycle in Spring
  • ApplicationContext
  • MessageSources in Spring
  • Web Spring MVC framework
  • Developing Your First Spring Web Application
  • Developing Your Second Spring Web Application with Spring Form
  • Developing Your First Spring Web Application with Spring Validation Framework with Code Example
  • Spring integration with Hibernate
  • SCWCD : Web Application Security

    SCWCD 1.5 Exam Kit

    Based on the servlet specification, compare and contrast the following security mechanisms: (a) authentication, (b) authorization, (c) data integrity, and (d) confidentiality.

    Authentication.

    Authentication means by which communicating entities prove to one another that they are acting on behalf of specific identities that are authorized for access.

    Authentication is any process by which you verify that someone is who they claim they are. This usually involves a username and a password, but can include any other method of demonstrating identity, such as a smart card, retina scan, voice recognition, or fingerprints. Authentication is equivalent to showing your drivers license at the ticket counter at the airport.

    Authorization (access control for resources).

    Authorization means by which interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints.

    Authorization is finding out if the person, once identified, is permitted to have the resource. This is usually determined by finding out if that person is a part of a particular group, if that person has paid admission, or has a particular level of security clearance. Authorization is equivalent to checking the guest list at an exclusive party, or checking for your ticket when you go to the opera.

    Data Integrity.

    Data integrity means used to prove that information has not been modified by a third party while in transit.

    Confidentiality (Data Privacy).

    Confidentiality means used to ensure that information is made available only to users who are authorized to access it.

    In the deployment descriptor, declare a security constraint, a Web resource, the transport guarantee, the login configuration, and a security role.

    Specifying Security Constraints.

    Security constraints are a declarative way of defining the protection of web content. A security constraint associates authorization and or user data constraints with HTTP operations on web resources. A security constraint, which is represented by security-constraint in deployment descriptor, consists of the following elements:

    • web resource collection (web-resource-collection in deployment descriptor)

    • authorization constraint (auth-constraint in deployment descriptor)

    • user data constraint (user-data-constraint in deployment descriptor)

    A security constraint that does not contain an authorization constraint shall combine with authorization constraints that name or imply roles to allow unauthenticated access. The special case of an authorization constraint that names NO roles shall combine with any other constraints to OVERRIDE their affects and cause access to be PRECLUDED.

    The HTTP operations and web resources to which a security constraint applies (i.e. the constrained requests) are identified by one or more web resource collections. A web resource collection consists of the following elements:

    • URL patterns (url-pattern in deployment descriptor)

    • HTTP methods (http-method in deployment descriptor)

    An authorization constraint establishes a requirement for authentication and names the authorization roles permitted to perform the constrained requests. A user must be a member of at least one of the named roles to be permitted to perform the constrained requests. The special role name '*' is a shorthand for all role names defined in the deployment descriptor. An authorization constraint that names NO roles indicates that access to the constrained requests MUST NOT be permitted under any circumstances. An authorization constraint consists of the following element:

    • role name (role-name in deployment descriptor)

    A user data constraint establishes a requirement that the constrained requests be received over a protected transport layer connection. The strength of the required protection is defined by the value of the transport guarantee. A transport guarantee of INTEGRAL is used to establish a requirement for content integrity and a transport guarantee of CONFIDENTIAL is used to establish a requirement for confidentiality. The transport guarantee of NONE indicates that the container must accept the constrained requests when received on any connection including an unprotected one. A user data constraint consists of the following element:

    • transport guarantee (transport-guarantee in deployment descriptor)

    If no authorization constraint applies to a request, the container must accept the request without requiring user authentication. If no user data constraint applies to a request, the container must accept the request when received over any connection including an unprotected one.

    				
    <security-constraint>
    	<web-resource-collection>
    		<web-resource-name>restricted methods</web-resource-name>
    		<url-pattern>/*</url-pattern>
    		<url-pattern>/acme/wholesale/*</url-pattern>
    		<url-pattern>/acme/retail/*</url-pattern>
    		<http-method>DELETE</http-method>
    		<http-method>PUT</http-method>
    	</web-resource-collection>
    	<auth-constraint/>
    </security-constraint>
    
    					

    '/*' DELETE access precluded

    '/*' PUT access precluded

    '/acme/wholesale/*' DELETE access precluded

    
    <security-constraint>
    	<web-resource-collection>
    		<web-resource-name>wholesale</web-resource-name>
    		<url-pattern>/acme/wholesale/*</url-pattern>
    		<http-method>GET</http-method>
    		<http-method>PUT</http-method>
    	</web-resource-collection>
    	<auth-constraint>
    		<role-name>SALESCLERK</role-name>
    	</auth-constraint>
    </security-constraint>
    
    					

    '/acme/wholesale/*' GET SALESCLERK

    
    <security-constraint>
    	<web-resource-collection>
    		<web-resource-name>wholesale</web-resource-name>
    		<url-pattern>/acme/wholesale/*</url-pattern>
    		<http-method>GET</http-method>
    		<http-method>POST</http-method>
    	</web-resource-collection>
    	<auth-constraint>
    		<role-name>CONTRACTOR</role-name>
    	</auth-constraint>
    	<user-data-constraint>
    		<transport-guarantee>CONFIDENTIAL</transport-guarantee>
    	</user-data-constraint>
    </security-constraint>
    
    					

    '/acme/wholesale/*' POST CONTRACTOR CONFIDENTIAL

    								
    <!--
    The security-constraint element is used to associate security
    constraints with one or more web resource collections
    
    Used in: web-app
    -->
    
    <!ELEMENT security-constraint (display-name?, web-resource-collection+,
    auth-constraint?, user-data-constraint?)>
    
    					

    Web resource.

    				
    <!--
    The web-resource-collection element is used to identify a subset
    of the resources and HTTP methods on those resources within a web
    application to which a security constraint applies. If no HTTP methods
    are specified, then the security constraint applies to all HTTP
    methods.
    
    Used in: security-constraint
    -->
    
    <!ELEMENT web-resource-collection (web-resource-name, description?,
    url-pattern*, http-method*)>
    
    					

    Transport guarantee.

    
    <!--
    The user-data-constraint element is used to indicate how data
    communicated between the client and container should be protected.
    
    Used in: security-constraint
    -->
    
    <!ELEMENT user-data-constraint (description?, transport-guarantee)>
    
    					

    Login configuration.

    				
    <!--
    The login-config element is used to configure the authentication
    method that should be used, the realm name that should be used for
    this application, and the attributes that are needed by the form login
    mechanism.
    
    Used in: web-app
    -->
    
    <!ELEMENT login-config (auth-method?, realm-name?, form-login-config?)>
    
    					

    
    <!-- login configuration uses form-based authentication -->
    <login-config>
    	<auth-method>FORM</auth-method>
    	<realm-name>Form-Based Authentication Area</realm-name>
    	<form-login-config>
    		<form-login-page>/protected/login.jsp</form-login-page>
    		<form-error-page>/protected/error.jsp</form-error-page>
    	</form-login-config>
    </login-config>
    
    					

    Security role.

    
    <!--
    The security-role element contains the definition of a security
    role. The definition consists of an optional description of the
    security role, and the security role name.
    
    Used in: web-app
    
    Example:
    
        <security-role>
    	<description>
    	    This role includes all employees who are authorized
    	    to access the employee service application.
    	</description>
    	<role-name>employee</role-name>
        </security-role>
    -->
    
    <!ELEMENT security-role (description?, role-name)>
    
    					

    				
    <!-- Security roles referenced by web application -->
    <security-role>
    	<role-name>user</role-name>
    </security-role>
    <security-role>
    	<role-name>admin</role-name>
    </security-role>    
    
    					

    Compare and contrast the authentication types (BASIC, DIGEST, FORM, and CLIENT-CERT); describe how the type works; and given a scenario, select an appropriate type.

    A web client can authenticate a user to a web server using one of the following mechanisms:

    • HTTP Basic Authentication

    • HTTP Digest Authentication

    • HTTPS Client Authentication

    • Form Based Authentication

    HTTP Basic Authentication.

    HTTP Basic Authentication, which is based on a username and password, is the authentication mechanism defined in the HTTP/1.0 specification. A web server requests a web client to authenticate the user. As part of the request, the web server passes the realm (a string) in which the user is to be authenticated. The realm string of Basic Authentication does not have to reflect any particular security policy domain (confusingly also referred to as a realm). The web client obtains the username and the password from the user and transmits them to the web server. The web server then authenticates the user in the specified realm.

    Basic Authentication is not a secure authentication protocol. User passwords are sent in simple base64 ENCODING (not ENCRYPTED !), and the target server is not authenticated. Additional protection can alleviate some of these concerns: a secure transport mechanism (HTTPS), or security at the network level (such as the IPSEC protocol or VPN strategies) is applied in some deployment scenarios.

    				
    <web-app>
    	<security-constraint>
    		<web-resource-collection>
    			<web-resource-name>User Auth</web-resource-name>
    			<url-pattern>/auth/*</url-pattern>
    		</web-resource-collection>
    		<auth-constraint>
    			<role-name>admin</role-name>
    			<role-name>manager</role-name>
    		</auth-constraint>
    	</security-constraint>
    	
    	<login-config>
    		<auth-method>BASIC</auth-method>
    		<realm-name>User Auth</realm-name>
    	</login-config>
    	
    	<security-role>
    		<role-name>admin</role-name>
    	</security-role>
    	<security-role>
    		<role-name>manager</role-name>
    	</security-role>
    </web-app>
    
    					

    HTTP Digest Authentication.

    Like HTTP Basic Authentication, HTTP Digest Authentication authenticates a user based on a username and a password. However the authentication is performed by transmitting the password in an ENCRYPTED form which is much MORE SECURE than the simple base64 encoding used by Basic Authentication, e.g. HTTPS Client Authentication. As Digest Authentication is not currently in widespread use, servlet containers are encouraged but NOT REQUIRED to support it.

    The advantage of this method is that the cleartext password is protected in transmission, it cannot be determined from the digest that is submitted by the client to the server.

    Digested password authentication supports the concept of digesting user passwords. This causes the stored version of the passwords to be encoded in a form that is not easily reversible, but that the Web server can still utilize for authentication. From a user perspective, digest authentication acts almost identically to basic authentication in that it triggers a login dialog. The difference between basic and digest authentication is that on the network connection between the browser and the server, the password is encrypted, even on a non-SSL connection. In the server, the password can be stored in clear text or encrypted text, which is true for all login methods and is independent of the choice that the application deployer makes.

    				
    <web-app>
    	<security-constraint>
    		<web-resource-collection>
    			<web-resource-name>User Auth</web-resource-name>
    			<url-pattern>/auth/*</url-pattern>
    		</web-resource-collection>
    		<auth-constraint>
    			<role-name>admin</role-name>
    			<role-name>manager</role-name>
    		</auth-constraint>
    	</security-constraint>
    	
    	<login-config>
    		<auth-method>DIGEST</auth-method>
    		<realm-name>User Auth</realm-name>
    	</login-config>
    	
    	<security-role>
    		<role-name>admin</role-name>
    	</security-role>
    	<security-role>
    		<role-name>manager</role-name>
    	</security-role>
    </web-app>
    
    					

    HTTPS Client Authentication.

    End user authentication using HTTPS (HTTP over SSL) is a strong authentication mechanism. This mechanism requires the user to possess a Public Key Certificate (PKC). Currently, PKCs are useful in e-commerce applications and also for a single-sign-on from within the browser. Servlet containers that are not J2EE technology compliant are not required to support the HTTPS protocol.

    Client-certificate authentication is a more secure method of authentication than either BASIC or FORM authentication. It uses HTTP over SSL, in which the server and, optionally, the client authenticate one another with Public Key Certificates. Secure Sockets Layer (SSL) provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection. You can think of a public key certificate as the digital equivalent of a passport. It is issued by a trusted organization, which is called a certificate authority (CA), and provides identification for the bearer. If you specify client-certificate authentication, the Web server will authenticate the client using the client's X.509 certificate, a public key certificate that conforms to a standard that is defined by X.509 Public Key Infrastructure (PKI). Prior to running an application that uses SSL, you must configure SSL support on the server and set up the public key certificate.

    				
    <web-app>
    	<security-constraint>
    		<web-resource-collection>
    			<web-resource-name>User Auth</web-resource-name>
    			<url-pattern>/auth/*</url-pattern>
    		</web-resource-collection>
    		<auth-constraint>
    			<role-name>admin</role-name>
    			<role-name>manager</role-name>
    		</auth-constraint>
    	</security-constraint>
    	
    	<login-config>
    		<auth-method>CLIENT-CERT</auth-method>
    		<realm-name>User Auth</realm-name>
    	</login-config>
    	
    	<security-role>
    		<role-name>admin</role-name>
    	</security-role>
    	<security-role>
    		<role-name>manager</role-name>
    	</security-role>
    </web-app>
    					
    					

    Form Based Authentication.

    The look and feel of the 'login screen' cannot be varied using the web browser's built-in authentication mechanisms. This specification introduces a required form based authentication mechanism which allows a Developer to CONTROL the LOOK and FEEL of the login screens.

    The web application deployment descriptor contains entries for a login form and error page. The login form must contain fields for entering a username and a password. These fields must be named j_username and j_password, respectively.

    When a user attempts to access a protected web resource, the container checks the user's authentication. If the user is authenticated and possesses authority to access the resource, the requested web resource is activated and a reference to it is returned. If the user is not authenticated, all of the following steps occur:

    1. The login form associated with the security constraint is sent to the client and the URL path triggering the authentication is stored by the container.

    2. The user is asked to fill out the form, including the username and password fields.

    3. The client posts the form back to the server.

    4. The container attempts to authenticate the user using the information from the form.

    5. If authentication fails, the error page is returned using either a forward or a redirect, and the status code of the response is set to 200.

    6. If authentication succeeds, the authenticated user's principal is checked to see if it is in an authorized role for accessing the resource.

    7. If the user is authorized, the client is redirected to the resource using the stored URL path.

    The error page sent to a user that is not authenticated contains information about the failure.

    Form Based Authentication has the same lack of security as Basic Authentication since the user password is transmitted as plain text and the target server is not authenticated. Again additional protection can alleviate some of these concerns: a secure transport mechanism (HTTPS), or security at the network level (such as the IPSEC protocol or VPN strategies) is applied in some deployment scenarios.

    Form based login and URL based session tracking can be problematic to implement. Form based login should be used only when sessions are being maintained by cookies or by SSL session information.

    In order for the authentication to proceed appropriately, the action of the login form must always be j_security_check. This restriction is made so that the login form will work no matter which resource it is for, and to avoid requiring the server to specify the action field of the outbound form.

    Here is an example showing how the form should be coded into the HTML page:

    					
    <form method='post' action='j_security_check'>
    	<input type='text' name='j_username'>
    	<input type='password' name='j_password'>
    </form>	
    					
    					

    				
    <web-app>
    	<security-constraint>
    		<web-resource-collection>
    			<web-resource-name>User Auth</web-resource-name>
    			<url-pattern>/auth/*</url-pattern>
    		</web-resource-collection>
    		<auth-constraint>
    			<role-name>admin</role-name>
    			<role-name>manager</role-name>
    		</auth-constraint>
    	</security-constraint>
    	
    	<login-config>
    		<auth-method>FORM</auth-method>
    		<realm-name>User Auth</realm-name>
    		<form-login-config>
    			<form-login-page>login.jsp</form-login-page>
    			<form-error-page>error.jsp</form-error-page>
    		</form-login-config>
    	</login-config> 
    	
    	<security-role>
    		<role-name>admin</role-name>
    	</security-role>
    	<security-role>
    		<role-name>manager</role-name>
    	</security-role>
    </web-app>
    					
    					

    The information you are posting should be related to java and ORACLE technology. Not political.