Security

Exam Objectives
Identify elements of the security model in the Java SE environment for remote clients, including Web Start, applets and the role of the Securitymanager class. Select appropriate locations to implement Java EE security technologies or features in a UML component and deployment diagram. Classify security threats to an enterprise application select measures an architect can propose to mitigate them. Identify techniques associated with declarative and programmatic security, including the use of annotations, deployment descriptors, and )AS technology. Identify the security technologies that apply to an applications code, messaging and transport layers

Java Web Start Applications

Unsigned JAR files launched by Java Web Start run in the sandbox, meaning they cannot access local files or the network. Restrictions: No access to local disk. All JAR files must be downloaded from the same host. Network connections are enabled only to the host from which the JAR files are downloaded. No security manager can be installed. No native libraries. Limited access to system properties. The application has read/write access to all system properties defined in the JNLP File, as well as read-only access to the same set of properties than an Applet has access to.

Applets
Default applet security restrictions deny applets the right to open sockets back to any server other than their originating host; they also block any attempt to listen for socket connections. To get around this, JRMP allows a client and server to simulate two-way communication using a single socket. In the current implementation, up to 256 virtual connections can be opened, each identified by a unique ID. Connecting via a socket back to the server is not always possible for applets running behind firewalls (e.g., on a corporate intranet), which typically blocks any attempt to open a socket back to the Internet. It should fail to open a connection, and RMI client wraps its method invocation

inside the body of an HTTP request (which is the protocol browsers use to communicate with Web servers), and the RMI server sends any results as an HTTP response. Allowed permissions Create a thread Manipulate AWT event queue Read but not modify some system properties Make network connections to the host from which it was loaded. Denied Permissions Any operation that might compromise the host (excluding CPU, memory or bandwidth usage) Make network connections to arbitrary hosts Access to the file system Restricted access to 10 system and therefore cannot open top level windows (with no security warning)

Security Concepts
Security Architectures A typical security system will use the following techniques to keep information safe. Identification The principal (individual making a request) identifies himself to the system. Typically identified using a password Authentication The process of confirming that a principal is who they claim. Often using a password or PIN, but potentially using biometrics, e.g. fingerprints. Some options for doing this at the web tier are: Basic HTTP The web server authenticates a principal with user name and password from web client. Form-based Lets developers customize the user authentication. HTTPS mutual authentication The client and server use X.509 certificates to establish identity over a SSL channel.

Authorization Checking that the authenticated principal or their associated role has the privileges to do the work requested. Often enforced using Access Control Lists (ACLs) or Resource Access Control (RAC). Protecting messages Messages can either be transmitted in encrypted form or in clear form with a message signature attached (a enciphered digest of the message contents which is costly in terms of CPU cycles). Auditing Despite all other measures, auditing is required to stop persistent attacks from breaking into a system. Cryptography Cryptography is the name given to the techniques that allow information to be temporarily transformed as it passes through public view making it unreadable. There are two distinct forms of cryptography: Symmetric Asymmetric Symmetric The key used to transform a message between its original and encrypted form is shared by the sender and recipient. The major consequences of this key are: The key must be securely shared between the sender and recipient which means that there is typically a significant overhead as the key is passed through some secure medium, e.g. a person to person meeting. The algorithm that uses the key to transform data is not considered a part of the security system and may be made public. Undemanding on system resources to encrypt and decrypt information

Asymmetric aka public key cryptography There are two keys used - one to transform the original information into an encrypted form (the public key) and another to transform the encrypted content back to unencrypted information (private key). Signatures and Certificates By using a private key to encrypt a message (the opposite of asymmetric cryptography) it is possible to verify that the sender of a message held the private key. If we know that the identity of the only holder of that key, then we can assert to the identity of the message sender. Rather than applying this process to the whole message, it is usually applied to representative section of it, called a digest. The problem of knowing that the real identity of the holder of a private key is significant. To solve this problem, it is possible to create a certificate that contains a public key and identity details. This certificate in turn is signed by another entity who verifies the authenticity of the certificate. This entity is typically a certificate authority (CA). The CA will either have a certificate, which in turn is signed by another authority or it will be a root certificate authority who choose to trust. Certificate authorities will authenticate a certificate after verifying the identity of the certificate's owner using a set of rules set down in their Certification Practice Statement (CPS). These rules can be very casual checks and so an important part of trusting a certificate should be dependent on the CPS of the CA.

Security Concept - Cross-site scripting (XSS)

Read more at htto://en.wikinedia.ora/wiki/Cross-site scrintina Cross-site scripting (XSS) is a type of computer security vulnerability typically found in Web applications. XSS enables attackers to inject client-side script into Web pages viewed by other users. Security on the web is based on a variety of mechanisms, including an underlying concept of trust known as the same origin policy. This essentially states that if content from one site (such as https://mybank.example.com) is granted permission to access resources on the system, then any content from that site will share these permissions, while content from another site (https://othersite.example.com) will have to be granted permissions separately.[citation needed] Cross-site scripting uses known vulnerabilities in web-based applications, their servers, or plugin systems on which they rely. Exploiting one of these, they fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access-privileges to sensitive page content, session cookies, and a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are therefore a special case of code injection.

Security Tools - Secure Sockets Layer (SSL)

SSL is a framework for two hosts to set up encryption between themselves. HTTPS When HTTP is passed over a SSL infrastructure, it is called HTTPS. This is different to the earlier SHHTP - which is usually no longer appropriate. HTTPS will use the encryption chosen by SSL, which could potentially be weak. It also will exchange certificates if available. Although an increasing number of online vendors will have a certificate most consumers will not. This means that although a consumer can be reasonably sure that a vendor is who they claim, a vendor will have less confidence in the identity of a consumer.

Security Tools
Web Logins One of the solutions to identify a consumer is by asking them to log in using an identifier and password. This process is only as secure as the process used to identify the consumer before providing them with a password.

Network Topologies
Simple Firewall Use a firewall as the only entry and exit point between an intranet and the external network. Two Firewalls and a DMZ A demilitarized zone (DMZ) contains all the services, which are provided externally allowing a second, more restrictive firewall to be used to secure the internal network. In this topology, the second firewall is typically very restrictive allowing no traffic directly from the outside. Instead a proxy server may be used to forward appropriate requests. This topology may be extended by utilizing it inside the intranet to secure sensitive sections or data. Tunneling Tunneling through a network is a way of getting through firewalls by wrapping a particular service to make it appear to be another permitted service. Wrapping as HTTP is often used. Tunneling may be used to provide access to an external service. In this case, the best solution is likely to be to open the firewall to allow the service rather than tunneling to get through an existing port.

Unspecified EJB Method Permissions

Security Roles Defining the security roles in the metadata annotations and/or deployment descriptor is optional. If Java language metadata annotations are used, the Bean Provider uses the DeclareRoles and RolesAllowed annotations to define the security roles. The set of security roles used by the application is taken to be the aggregation of the security roles defined by the security role names used in the DeclareRoles and RolesAllowed annotations. Note: The exam objective tests your knowledge in selecting techniques associated with declarative and programmatic security, including the use of annotations, deployment descriptors, and JAAS technology. You may not require EJE. security coding knowldge but it is good to know the annotations and techniques explained in the next chapters.

Security Roles
The Bean Provider and/or Application Assembler use the security-role deployment descriptor element as follows: Define each security role using a security-role element. Use the role-name element to define the name of the security role. Optionally, use the description element to provide a description of a security role.

Security Role References

Declaration of security Roles Referenced from the Bean's Code The Bean Provider is responsible for using the DeclareRoles annotation or the securityrole-ref elements of the deployment descriptor to declare all the security role names used in the enterprise bean CODE. The DeclareRoles annotation is specified on a bean class, where it serves to declare roles that may be tested by calling isCallerInRole from within the methods of the annotated class. Declaring the security roles allows the Bean Provider, Application Assembler, or Deployer to link these security role names used in the code to the security roles defined for an assembled application. In the absence of this linking step, any security role name as used in the code will be assumed to correspond to a security role of the SAME name. Security Role References The Bean Provider declares the security roles referenced in the code using the DeclareRoles metadata annotation. When declaring the name of a role used as a parameter to the isCallerInRole(String roleName) method, the declared name MUST be the same as the parameter value. The Bean Provider may optionally provide a description of the named security roles in the description element of the DeclareRoles annotation.

Linking Security Role References to Security Roles

The security role references used in the COMPONENTS of the application are linked to the security roles defined for the APPLICATION. In the absence of any explicit linking, a security role reference will be linked to a security role having the SAME name. The Application Assembler may explicitly link all the security role references declared in the DeclareRoles annotation or security-role-ref elements for a component to the security roles defined by the use of annotations and/or in the security-role elements. The Application Assembler links each security role reference to a security role using the role-link element. The value of the role-link element MUST be the name of one of the security ROLES defined in a security-role element or by means of the DeclareRoles annotations or RolesAllowed annotations, but need not be specified when the role-name used in the code is the same as the name of the security-role [to be linked].

Method Permissions
If the Bean Provider and/or Application Assembler have defined security roles for the enterprise beans in the ejb-jar file, they can also specify the methods of the business, home, and component interfaces, and/or web service endpoints that each security role is allowed to invoke. Metadata annotations and/or the deployment descriptor can be used for this purpose. Method permissions are defined as a binary relation from the set of security roles to the set of methods of the business interfaces, home interfaces, component interfaces, and/or web service endpoints of session and entity beans, including all their superinterfaces [including the methods of the E)BHome and EMObject interfaces and/or EJBLocalHome and OBLocalObject interfaces]. The method permissions relation includes the pair [R, M] if and only if the security role R is allowed to invoke the method M.

Responsibilities
Responsibilities of the Bean Provider and/or Application Assembler The Bean Provider and Application Assembler [which could be the same party as the Bean Provider] may define a security view of the enterprise beans contained in the ejbjar file. Providing the security view is optional for the Bean Provider and Application Assembler. The main reason for providing the security view of the enterprise beans is to simplify the Deployer's job. The security view consists of a set of security roles. A security role is a semantic grouping of permissions that a given type of users of an application must have in order to successfully use the application.

Deployer's Responsibilities
The Deployer is responsible for ensuring that an assembled application is secure after it has been deployed in the target operational environment. The Deployer uses deployment tools provided by the EJB Container Provider to read the security view of the application supplied by the Bean Provider and/or Application Assembler in the metadata annotations and/or deployment descriptor. The Deployer's job is to map the security view that was specified by the Bean Provider and/or Application Assembler to the mechanisms and policies used by the security domain in the target operational environment.

Responsibilities
Deployer's Responsibilities The output of the Deployer's work includes an application security policy descriptor that is specific to the operational environment. The format of this descriptor and the information stored in the descriptor are specific to the EJB container. <session> <ejb-name>TestManager</ejb-name> <ejbclass> com.epractizelabs.skillevaluation.admin.TestManagerBean </ejb-class> ... <security-role-ref> <description> This role should be assigned to the administrators. </description> <role-name>admin</role-name> </security-role-ref> ... </session>

EJB Container Provider's Responsibilities

The ElB Container Provider is responsible for providing the deployment tools that the Deployer can use to perform the deployment tasks.

Use of getCallerPrincipal
The purpose of the getCallerPrincipalmethod is to allow the enterprise bean methods to obtain the current caller principal's name. The methods might, for example, use the name as a key to information in a database. An enterprise bean can invoke the getCallerPrincipal method to obtain a java. security.Principal interface representing the current caller. The enterprise bean can then obtain the distinguished name of the caller principal using the getName method of the java. security.Principal interface. If the security identity has not been established, getCallerPrincipal returns the container's representation of the UNAUTHENTICATED identity.

@Stateless public class EmployeeServiceBean implements EmployeeService { @Resource SessionContext ctx; @PersistenceContext EntityManager em; public void changePhoneNumber(...) { // obtain the caller principal. callerPrincipal = ctx.getCallerPrincipal(); // obtain the caller principal???s name. callerKey = callerPrincipal.getName(); // use callerKey as primary key to find EmployeeRecord EmployeeRecord myEmployeeRecord = em.find(EmployeeRecord.class, callerKey); // update phone number myEmployeeRecord.setPhoneNumber(...); } }

Use of IsCallerInRole
The main purpose of the isCallerInRole(String roleName) method is to allow the Bean Provider to code the security checks that cannot be easily defined declaratively in the deployment descriptor using method permissions. Such a check might impose a role-based limit on a request, or it might depend on information stored in the database. The enterprise bean code can use the isCallerInRole method to test whether the current caller has been assigned to a given security role. Security roles are defined by the Bean Provider or the Application Assembler, and are assigned to principals or principal groups that exist in the operational environment by the Deployer.

@Stateless public class TestManagerBean implements TestManager { @Resource SessionContext ctx; public void updateTest (Test testIn) test= ... read from database; // The test and questions can be changed only by callers // who have the security role admin if (!ctx.isCallerInRole(admin")) throw new SecurityException(...); } } .. }

Security and Method Permissions Metadata Annotations

The following security-related annotations are in the package javax.annotation.security. Security Role References The DeclareRoles annotation is used to declare the references to security roles in the enterprise bean code: package javax.annotation.security; @Targete{TYPE}) @Retention(RUNTIME) public @interface DeclareRoles { String[ ] value(); }

Method Permissions The RolesAllowed annotation specifies the security roles that are allowed to invoke the methods of the bean. The value of the RolesAllowed annotation is a list of security role names. This annotation can be specified on the bean class and/or it can be specified on methods of the class that are methods of the business interface. Specifying the RolesAllowed annotation on the bean class means that it applies to ALL applicable interface methods of the class. If the PermitAll annotation is applied to the bean class, and RolesAllowed is specified on an individual method, the value of the RolesAllowed annotation OVERRIDES for the given method. package javax.annotation.security; @TargetaTYPE, METHOD}) @Retention(RUNTIME) public @interface RolesAllowed { String[] value[]; }

PermitAll The PermitAll annotation specifies that all security roles are allowed to invoke the specified method[s] - i.e., that the specified method[s] are "unchecked". package javax.annotation.security; @Target ({TYPE, METHOD}) @Retention(RUNTIME) public @interface PermitAll {} DenyAll The DenyAll annotation specifies that no security roles are allowed to invoke the specified method - i.e. that the specified method is to be EXCLUDED from execution. package javax.annotation.security; @Target [METHOD] @Retention(RUNTIME) public @interface DenyAll {} RunAs The RunAs annotation is used to specify the bean's run-as property. This annotation is applied to the bean class. Its value is the name of a security role. package javax.annotation.security; @Target(TYPE) @Retention(RUNTIME) public @interface RunAs { String value();}; Specification of method Permissions in the Deployment Descriptor The application assembler is permitted to override the method permission values using the bean's deployment descriptor. The method element uses the ejb-name, method-name, and method-params elements to denote one or more methods of an enterprise bean's business , home, and component interface, and/or web service endpoint. There are three legal styles for composing the method element <method> <ejb-name>E3BNAME</ejb-name> <method-name>*</method-name> </method>