Security

Select from a list security restrictions that Java 2 environments normally impose on applets running in a browser. The Java 2 security model is policy-based and has superseded the sandbox/trusted approach of Java 1.1. In Java 1.1 remote code (applets, for example) that was not trusted was constrained to the sandbox. If the remote code was signed and trusted then it could access local resources.

Cryptography, Digital signatures and Certificates can be used to increase the security of a system. Java offers a number of interfaces for related services. Firewalls are also important for protecting the gateway between trusted and untrusted networks.

Code Source:A combination of a set of signers (certificates) and a code base URL.By default, Java 2 uses a policy file to associate permissions with code sources

Security Policy File: permission is the right to access a protected resource or guarded object. For Java 2 permissions are specified in the security policy file. Only one policy is in effect at a time. A policy file consists of a number of grant entries. Each grant entry describes the permissions (one or multiple) granted to a code source.

Policy class: You can use java.security.Policy to create your own security policy.

java.security package : The following are some of the classes in the java.security package:

CodeSource – This class extends the concept of a codebase to encapsulate not only the location (URL) but also the certificate(s) that were used to verify signed code originating from that location.

KeyStore – This class represents an in-memory collection of keys and certificates. It manages keys and trusted certificates.

MessageDigest – The MessageDigest class provides applications the functionality of a message digest algorithm, such as MD5 or SHA.

Permission – Abstract class for representing access to a system resource.

Policy – This is an abstract class for representing the system security policy for a Java application environment (specifying which permissions are available for code from various sources).

ProtectionDomain – The ProtectionDomain class encapulates the characteristics of a domain, which encloses a set of classes whose instances are granted the same set of permissions.

Security – Centralizes all security properties and common security methods.

Given an architectural system specification, identify appropriate locations for implementation of specified security features, and select suitable technologies for implementation of those features.

Exposure to threats can be mitigated by using:

Authentication, Authorization (ACLs), Protecting Messages, Auditing

Web tier authentication (This is the usual location for this)

• Basic HTTP – the web server authenticates a principal with user name & password from Web client
• Form-based – lets developers customize the authentication user
• HTTPS mutual authentication – the client and server use X.509 certificates to establish identity over a SSL channel.

EJB/EIS tier authentication

• For EJBs can use protection domains. Thus the EJB tier could entrust the web tier to vouch for the identity of users.
• Put a protected web resource in front of a protected EJB resource.
• Have every web resource that calls an EJB resource route through a protected web resource
• For access to EIS tier resources authentication is usually carried out by the component accessing the EIS resource.
• You can have the container manage the EIS resource authentication or have the app do this itself.
• Authorization
• In J2EE a container serves as an authorization boundary between callers and its components. The authorization boundary is inside the authentication boundary so authorization occurs within the context of successful authentication.
• For component to component invocations inside the container the calling component must make its credentials available to the called component.
• You can have file-based & code-based security in J2EE.
• Access control policy is set a deployment time.
• Controlling access to resources in the container (deployment descriptor)
• To control access to web resources, specify constraint in the deployment descriptor.
• To control access to EJB, specify roles in the deployment descriptor.
• You can specify methods of the remote & home interface that each security role is allowed to invoke
• Protecting Messages
• To ensure message integrity you can use:
• Message signature – a enciphered digest of the message contents (costly in terms of CPU cycles)
• Message confounder – ensures message authentication is useful only once
• A deployer must configure the containers involved in a call to implement integrity mechanisms either because the call will traverse open or unprotected networks or because the call will be made between components that do not trust each other.

Auditing

When security is breached it is usually more important to know who has been allowed access than who has not. Audit records need to be well protected – tapes or logging to a printer vs disk drive

Communication security threats

Eavesdropping: Information is kept intact, but privacy is compromised.

Tampering: Information in transit is changed or replaced and then sent on.

Impersonation: Information passes to the wrong person, who poses as the intended recipient. Persons or systems can pretend to be somebody else (Spoofing) or something else (Misrepresentation).

Goals of cryptography

Privacy: Communication between two parties is unintelligible to an intruder.

Tamper detection: Verify that information has not been changed in transit.

Authentication: Confirm that the sender of the information is who he claims to be.

Non-repudiation: Prevents senders from claiming at a later date the information was never sent.

Symmetric Key Cryptography

One key is used for encryption and decryption.

Problem is key exchange between remote parties. Advantage is efficient implementation.

Public-Key Cryptography

Also called “ asymmetric cryptography”. Pair of two associated keys: The private key is kept secret; the public key is published openly. Encryption with public key ensures privacy.

Digital signatures

Message digest or one-way hash function: Number of fixed bit length that changes with every subtle change in the message and cannot be reversed.

Digital signature: Encryption of the message digest with the public key.

Method: Send digital signature along with message. Receiver calculates message digest of the received message and compares with the decrypted message digest.

Certificates

Problem: Verify validity of a person’s public key.

Certificate: Electronic document that identifies an individual, a server, a company, or some other entity and associates the entity with a public key.

Certification authority (CA): Validates identity and issues certificates.

Certificates contain identity name, expiration date, CA name and digital signature, and other information like a serial number.

Authentication: Process of confirming an identity. In general, can be based on assets (ID cards, private key file), knowledge (ID and password), or individual properties (biometrics).

Network authentication can be password-based or certificate-based. Advantage of certificates: Password does not need to be sent across the network. Single-sign on is easier.

X.509 v3: ITU Standard for certificate content. X.509 v3 binds a distinguished name (DN) to a public key. DN is a series of name-value pairs, e.g. uid=doe,e=doe@abc.com,cn=John Doe,o=ABC,c=US, like in LDAP.

X.509 Data Section: 1) Version no of X.509 standard 2) Serial number (unique to CA) 3) Information 4) Public Key Info: Algorithm and Data 5) Validity Period 6) Subject’s DN 7) Optional extensions

X.509 Signature Section: 1) Algorithm or cipher used by the CA 2) Digital signature of certificate by CA

Certificate chains: Hierarchy of CA’s, parents certifying children. Allows verifying certificates by just having the trusted public key of the root CA.

Public Key Infrastructure (PKI): Set of standards and services that facilitate the use of public-key cryptography and X.509 v3 certificates.

Key recovery or key escrow: Ability to retrieve backups of private keys under certain, carefully defined conditions. Example is the m-of-n principle, m of n trusted individuals have to agree.

Public Key Cryptography Standards (PKCS): Set of standards driven by RSA Labs with broad industry support. Includes RSA public-key and Diffie-Hellman algorithms.

Java Security Model

Security architecture has changed from JDK 1.1 to 1.2. In JDK 1.1, the ‘sandbox model’ distinguished between remote code (applets) that was run with security restrictions in the sandbox, whereas local code was totally trusted. With Java 2, all application code is subject to security control.

The Java language supports writing safe code: Strong type checking, automatic memory management, range checking, JRE bytecode verifier.

The Java 2 platform explicitly supports access control to various important resources like files and sockets through permissions and the SecurityManager.

Protection domain: Conceptual set of resources that are currently available to a principal.

Permissions are resolved by checking the protection domain assigned to a class.

Two main protection domains: Application and system.

Classes

Permission: Abstract base class for all permissions, e.g. java.io.FilePermission.

PermissionCollection: List of permissions of same type. Permissions: List of PCs.

Types of permissions: (Basic), File, Socket, Property, Property, Runtime, AWT, Net, Security, All

Defining new permissions: Descend from Permission, implement implies method.

CodeSource: Defines URL of a remote codebase along with associated certificates.

Policy: The current security policy. Policy.getPolicy(), getPermissions(CodeSource)

ProtectionDomain: Uniquely identified by a CodeSource. A class belongs to exactly one PD.

AccessController: Has checkPermission method (also called by SecurityManager)

AccessControlContext: Defines state of access control, used to pass access info between threads.

Principal: Interface for entities like persons, companies, used in X.509 certificates

Tools

keytool

Create public/private key pairs, issue cert requests (for sending to CA), manage key store.

jarsigner

Signing and verifying JAR files. “jarsigner [options] jar-file alias”

policytool

Files

Can be found in {JDK Home}/lib/security

Java.security – Security Properties File

Java.policy – System Policy File

Cacerts – Certificates Keystore File

Java Cryptography Architecture (JCA)

Package java.security.

Engine classes: MessageDigest, Signature, KeyPairGenerator, KeyStore, SecureRandom etc.

Interface are implemented by providers.

Default provider SUN is shipped with Sun’s JDK 1.2, includes DSA, MD5, SHA-1, X.509 certs, JKS.

Additional Java Security Services

Java Authentication and Authorization Service (JAAS) 1.0

Supports access control based on who runs the code. J2SE only supports access control based on where code is coming from and who signed it.

Implements Pluggable Authentication Module (PAM).

Principal: Named entity or account. (Roles and Groups are Principals as well.)

Subject: Person or Service using a system. Represented by a set of Principals.

Credential: Additional security info about a subject, e.g. certificate, password. Public/Private

Two-phase login like two-phase commit.

Authorization: Policy files like Java 2 policies, with new principal key word.

Java Cryptography Extension (JCE) 1.2.1

Extensions to the Java Cryptography Architecture (JCA), that is part of J2SE.

Java Secure Sockets Extension (JSSE) 1.0.2

Provides SSL (Secure Sockets Layer) 3.0 and TLS (Transport Layer Security) 1.0.

SSLSocket and SSLServerSocket classes

HTTPS support

Package javax.net.ssl

Firewalls

A firewall is a system that enforces an access control policy between two networks.

Purpose of firewalls: Control incoming and outgoing travel, address translation, monitoring.

Screening types: Check whether data have been requested, check sender, check content.

Network Address Translation (NAT): Make it seem like all outgoing traffic originates from the firewall.

Attack types: Information theft, Information sabotage, Denial of service.

Firewalls are certified by the ICSA (International Computer Security Agency).

ICSA firewall categories

Packet filter firewalls: Based on information in single IP packets; port, source/dest IP address

Application-level proxy servers: Inspection of data for specific services, e.g. HTTP, FTP, SMTP

Stateful packet inspection firewalls: Stores requests and checks incoming data against them.

Additional support might be provided for:

De-militarised zones (DMZ): Zone for protected, controlled public access, separate from intranet.

Virtual Private Networks (VPN). VPN’s are more cost-effective than leased lines or dial-in.

Virus detection

Load Balancing

Firewall implementation types

Router/Firmware-based firewalls: Built into router. Usually limited capabilities available.

Software-based firewalls: Sophisticated applications on a workstation. Difficult to maintain.

Dedicated firewall appliances: Best solution. High throughput, less maintenance, more security.

From Oracle’s website

Effective June 1, 2011, Java, Oracle Solaris, MySQL, and NetBeans certification exams will be offered through a new test delivery partner – Pearson VUE – and will no longer be available through Prometric.

This will consolidate all Oracle Certification exams within the operations of a single testing vendor so we can provide better service and global testing coverage for these Oracle certification exams. Pearson VUE currently has over 5,000 test centers worldwide in 165 countries.

To help prepare you for this transition, here are some important dates for you to be aware of:

• If you are planning to take an exam on/after June 1: Registration will begin at Pearson VUE on May 16, 2011 for all scheduled exams on or after June 1. Visit pearsonvue.com/oracle on or after this date to create a new web account and get started.
• If you are currently registered to take an exam with Prometric or planning to take an exam on or before May 31: You can continue to register at Prometric through May 23, 2011 (walk-in registrations will be permitted through May 31, 2011), but you must complete your exam by June 1, 2011.

If you currently have a Sun or Oracle exam voucher or exam retake voucher:All vouchers will still be valid through their original expiration date and will be redeemable with Pearson VUE starting on May 16, 2011.

Full announcement can be viewed here

We have contacted the creator of these tests Ikoko , and he has clarified thatthe Spring documentation for the exam syllabus has changed (improved) since he had created the exam so the tests now appear to be different to the syllabus

The historical documentation and support for the certification has been poor from Spring and might even be incorrect.

he also pointed out that Skill-guru test-takers basing their opinions on the Spring documentation and not actually doing the Spring exam are therefore possibly misled by the official documentation

From Ikoko’s email

I sat both the 2.5 exam and 3.0 exam so have experienced both exams first-hand and have been keen to keep my exams accurate based on real exam-experience and not any vague syllabus published by Spring

Having said all, this at a higher topic level I only noticed the category of SpEL (Spring expression language) being a category in my tests that was not in the offical syllabus. I had 1 SpEL question in test 1, and 2 questions in test 2. I have now removed all three questions.

Hope  this clarifies the doubt of our readers and thanks to MaggieL and Shane Mannion for pointing this out

Traditional J2EE application servers work well for a large class of applications. This class can broadly be categorized as applications that run in a stateless cluster in front of a database. I call this a symmetric cluster:

- All the cluster members can perform any task at any time.

- The application is stateless.

- The application is modal which means it only performs work synchronously in response to a client request which can be received using HTTP/IIOP or JMS.

There are other applications that do not work well in such an environment, for example, an electronic trading system in a bank. Such applications typically use tricks that can greatly improve performance such as partitioning, multi-threading and write through caching. These are applications that can exploit asymmetric clustering. An asymmetric cluster is practically the opposite of a symmetric cluster:

- applications can declare named partitions at any point while it’s running

- partitions are highly available uniquely named singletons and run on a single cluster member at a time

- incoming work for a partition is routed to the cluster member hosting the partition

- The application is amodal. Partitions have a lifecycle of their own and can start background threads/alarms as well as respond to incoming events whether they are IIOP/HTTP or JMS/foreign messages.

WebSphere XD offers a new set of programming API’s called the “Partitioning Facility”. These APIs allow applications that require an asymmetric cluster to be deployed on a J2EE server for the first time to my knowledge.

How can partitioning improve application performance?

A stateless cluster will only scale so far once the cluster members start competing for database access. If the workload is a read mostly workload then solutions like caching with optimistic locking work well. However, as the write rate increases this starts to break down because of collisions. Some workloads also require incoming work to be executed in order, for example, buy and sell orders for a stock symbol need to be processed in order of price and then in order of arrival. When the work is spread over a cluster then this is made more complex and while it can be done, it’s not easy. Partitioning allows the application to partition itself, split the incoming requests in to streams corresponding to those partitions and then route incoming work for a particular event/request stream exclusively to a single partition. This incoming work needs to be classified in to partitions and the requests are then routed to the cluster member hosting that partition using either IIOP or messaging. Once the work arrives then the cluster member can aggressively cache read/write data specific to that partition as the developer knows this data can only be modified on this cluster member. The cluster member can also order the work and ensure that it’s processed in the correct sequence in memory independently of any other cluster members. The database is now offloaded as it just gets writes from the cluster, all reads are satisfied using the cache in the cluster member. So long as there are more partitions than boxes then adding boxes will make this application run faster until the database ultimately becomes a bottleneck.

The other situation where async beans plus partitioning improves performance is that both these features provide low level primitives that can be used to practically build a custom application container that fully leverages the features of the application server. The J2EE specification provides a very high level set of services to an application developer. If this set of services isn’t what the application developer requires then the standard spec does not allow the developer to provide an alternative. The normal option is write a standalone J2SE application that does it or try to have features added to the next release of the commercial application server. The partitioning facility and async beans provide low level primitives that allow this code to run on top of the application server in a fully supported manner. This approach allows advanced customers to have the benefit of using a commercial application server without the normal limitations of the J2EE one size fits all philosophy.

Why might the asymmetric/partitioned model scale better than the symmetric model?

A financial application that matches buyers with sellers is an example of one type of application that we’ve seen. The application trades a set of financial instruments such as stocks. It tracks the buy and sell orders for each stock and attempts to match buyers with compatible sellers. It would also compare the buyers and sellers with prices from other exchanges and may route orders to an external exchange if that exchange is currently posting a better price. Orders should be processed in price order and if orders have the same price then they are processed in the order they arrived. Such a system might receive between 20,000 and 100,000 orders per day but would also receive between 500 and 2000 remote exchange prices/second (2 million prices/hour) and this volume is growing at about 40% a year. Clearly handling the prices volume is the main performance problem. Partitioned application can also better exploit SQL batching to significantly improve performance as they don’t need to worry about optimistic locking collisions. The rows are only being changed on a single server, no collisions.

What kind of applications typically implemented on symmetric clusters might benefit from being refactored into asymmetric ones?

Applications with smaller data sets that experience high request volumes and a relatively high write to read ratio. This kind of application typically doesn’t scale horizontally because of contention between cluster members even using approaches such as optimistic locking.

Applications that require sequenced request handling where a subset of the incoming events must be processed using some sequence or order. This can be implemented more efficiently using partitioning than with approaches using database locking.

Applications that have dynamic messaging requirements. If the set of message queues or topics used by an application changes dynamically during the time the application is deployed then a dynamic POJO message listener framework can be easily constructed with the exact threading model needed by the application rather than the normal cookie cutter approach.

Applications that have very high incoming message rates and where it makes sense to split the incoming message feed so that a specific subset only goes to a single cluster member. We’re partitioning the incoming topics into groups using hashing or some deterministic approach and each cluster member only receives messages for topics assigned to partitions hosted by that cluster member. This cluster member can then aggressively cache state for this subset and this improve performance as well as offloads the database. This again enables horizontal scale up especially when message order is important.

Based on my experience studying for and taking the part 1 of the certification, here is what I would suggest that you read before taking the exam. You could skip a couple of the following references and still pass (don’t skip the EJBs though).

There is another test with 22 questions J2EE Architect Certification Practice Test which is similar to what you take in Part 1

The test will tell you how many correct answers there are for each question, and the software will let you know if provide more or less answers than the expected amount. The structure of the multiple choice test was helpful and made the test a little easier. There are 48 questions on the test and you have 90 minutes to complete the test. I finished with 20 minutes to spare and spent the extra time going over my answers. The software allows you to skip questions and also mark questions. After answering question 48, you get a display showing the questions that you have skipped, are incomplete because you didn’t provide as many answers as expected, as well as questions that you have marked. You can then revisit any of the questions. The software also always displays the amount of time you have remaining.

The following topic areas are not how Sun breaks it out. Rather, it is how I would break it out in terms of the topics that you need to study. At least 16 out of the 48 questions on the exam when I took it where related to EJBs. There were between 2  and 5 questions on all other topic areas.

Problem

Sometimes we have multiple operations that need to be implemented on a structure of objects. Traditionally we would implement each of the objects to derive of a base class with each of the operations, and then override the operations to implement them. This can be a problem if the operations are different in nature, as well as if the number of operations exceeds the number of different subclasses in the tree. How can we overcome this problem?

Solution

The solution is the visitor pattern. The visitor pattern has each object class in the structure only has one method called AcceptVisitor() which takes a visitor class as a parameter. A visitor is an implementation of a particular operation, and has methods for each of the class types in the structure. The object in the structure calls its appropriate method on the visitor. For example, if a tree structure contained two types of classes, Foo and Fib. Then when we wanted to perform a function on them we pass down a visitor that implements the function, and nodes of type Foo call the VisitedFoo() function on the visitor, which implements the function for objects of type Foo

Consequences

It is easy to add operations, simply derive anew visitor class.

However, it is hard to add new class types to the structure, since you need to change both the base class and all subclasses of the visitors for the change.

Problem

Consider the case where you have a structural hierarchy of object that is not necessarily subclasses from the same base class. Now lets say there is a piece of functionality that they all can implement, but it is not statically determinate which should handle the case. Now I know that sounds a little complicated, but picture a context sensitive help system. Each piece of the display may have a piece of text that is wants to display when ever the cursor is over top of it, or it may not. In the case where a piece doesn’t want to handle it, you want the class that contains it to display a more general help string. You also want this system to be dynamic at run-time. How can this be done?

Solution

The Chain of responsibility can solve this problem. The chain of responsibility requires that each of the classes involved inherit from a base class, let’s say HelpHandler. Now when they are instantiated, the objects all initialize their parent class with a successor, which is a reference to another object that is also derived from the base class. When the time comes to call the method that you want to pass up the chain, the first object picked is the most appropriate one. If the object doesn’t want (or can’t handle) the request, it calls the BaseClass::Method() which calls the method for the successor, and so on, until one of the objects handles the request.

Consequences

The chain of responsibility makes it so the client doesn’t need know who is in fact handling the request, only that the request is being handled. As well, you can change the hierarchy at run-time to provide for a changing environment. However, it should be noted that in this system all participants in the chain could refuse to handle the request, and the client would not know.

How can we issue request to other objects in a system, without having to know who will receive the request, or even what the request is? This can be useful for implementing functionality such as a menu system, where each menu item has a command that it executes, but it doesn’t want to know what it is, it only needs to trigger the command at the right time. How can this be done?

Solution

The command pattern is simple the use of objects as commands in a system. The command class has a virtual member called Execute(). In our above example, the menu item could take a command object as an initialization parameter, and when the application runs, then menu item gets a command, the when the menu item is clicked it calls Execute() on the command.

Consequences

Commands are very powerful, and can support a lot of different functionality. For example, if the command registered itself with some global undo class when it executes, then simply by reversing each command in reverse order (I smell a stack…) we can undo any sequence of commands provided every command class can be undone. Command object separates the object that triggers an operation from the one that executes the operation. By using the Composite pattern you can extend a command to execute multiple commands. And since all commands derive from the command base class, adding new commands is easy.

I myself have used this pattern to implement a dynamic console in a game. At run-time, sections of code register commands into the console. The console then accepts textual input, and pattern matches against a Name() method of each command, and upon finding a match it calls Execute() on the command. I had implemented this before discovering Design Patterns, so could have saved myself a lot of work in knowing the intricacies of this pattern if I had read the book.