Sunday, September 25, 2005

Security with Java Cryptography Architecture

Security with Java Cryptography Architecture

In the last week I was going through some discussions on how to provide security on our new application we are building at Scali AS. In our architecture the server is a C deamon which uses OpenSSL for security where as the client is a Java RCP which uses JSSE.

One observation I had in working with java security frameworks is that Java has lot of Security components, but most of the developers has no very clear understanding of where those components fits in to the application requirement they have. So I thought of having a blog post which introduces the Java security components and their usage.

Here we go... Broadly there are several components belonging to the Java Cryptography Architecture (JCA) (or simply Java Security). JCA can be divided in to several sub categories as follows :

a) Java Authentication and Authorization Services (JAAS)
b) Java Secure Socket Extension (JSSE)
c) Java Cryptography Extension (JCE)
d) General Security Services (Java GSS-API)
e) Java Certification Path API
f) Java Simple Authentication and Secure Layer (Java SASL)

JAAS is the Java solution (framework) for authenticating and authorization uses and services. JAAS provides user-centric as well as code-centric access control mechanisms. JAAS can be considered as a framework and an API focused mainly for non-connection oriented (stand-alone) application security. It is not about encrypting data but it is a implementation neutral API for authentication and authorization (For an example if we decide to move our usernames/passwords from a properties file to a database, still JAAS wil allow us to do this with out changing application code).

JAAS authentication mechanism is pluggable so vendors/users may write there own ‘login modules’ to read/validate authentication credentials from their preferred source (e.g. database, directory service). As I know, JDK does not provide many default ‘login modules’ but generally application servers come-up with several reusable login modules such for reading “prop-files”, “simple database tables”, etc...

JSSE provides a framework and implementation for securing your data in network communications by introducing security later on top of TCP/IP. J2SDK 1.4 onwards supports SSL 3.0 and TCL 1.0 protocols. The most popular SSL model used on internet is to authenticate only the server identity and use encryption on data. Client identity is authenticated using username/password provided by the client (e.g. a typical e-commerce web-site) JSSE provides a convenient API on top of java sockets for enabling your TCP connection security.

JCE consists of a framework defining java security components such as data encriptors, key generators, etc… Sun has provides a default implementation called “SunJCE” for this framework (For example RSA, DES encryption algorithms, DES key generators are provided with the ‘SunJCE’ provider). We may use this default SunJCE (any other third party provider) to provide some cryptographic operation such as encrypting a data stream using “DES symmetric key” encryption.

Java GSS-API allows java developers to make their programs to work with Kerberos based authentication. Similar to JSSE, GSS-API provides authentication, encryption and integrity protection on your data. The underline mechanism used is the widely known Kerberos security model. Kerberos provides strong token based security and supports single sign-on capabilities for the applications. (GSS API mechanism is defined as a Internet Standard under RFC2853)

Java Certification path consists of abstract framework classes which allows user to create, validate, manipulate ‘Certification Chains’. Certification chain is a ordered list of certificates which will establish a trustable mapping from ones identity to his ‘public key’. Java Certification Path API also consists of a default implementation for working with X.509 certificates.

Java SASL is the java implementation of the SASL internet standard defined under RFC2222. As the name suggest the SASL standard also provides authentication and secure transmission of data (so it also can be categorize with GSS and JSSE). SASL is defined to be a light weight protocol and used by LDAP and IMAP implementations. Thus any application intended to work with those applications may need Java SASL API for security integration.

Thus the bottom line is that, we should decide on the technology to be used based on our application context. As a rough example if my application is TCP socket based I may go for JSSE, if my organization security is Kerberos based then I go for GSS-API, if I need to communicate with a LDAP service I may need to consider Java SASL API and so on…

Sunday, September 18, 2005

Ruby blocks, C# delegates, C function pointers and Java inner classes

Ruby blocks, C# delegates, C function pointers and Java inner classes

During the weekend I spent some time to look in to the Ruby 'Blocks'. Blocks are a Ruby language construct which adopts the concept of method references in a very useful manner. Even though this is not a new idea I haven’t seen a language adapting and using method references to the extent as Ruby does. Let’s look at how Ruby adapts this concept. One of the Ruby’s powers is that it takes fewer lines of codes compared to most of the other languages. For an example in Ruby iterating on an array and printing the elements will look like the following:

array.each { |animal| puts animal }

Actually what happens here is, to the "Array.each" method we pass the code block "{ |animal| puts animal }" so “array.each” method will call the passed code block for each element of the array (more information). As u may see this is not exactly passing methods as references. Instead of passing an external method as a parameter, in Ruby we write our code inline as a code block.

Let’s look at some other languages to see the way they allow developers to pass code blocks as parameters of a method.

In C# we may gain the same power with Delegates. Delegate is a type that describes a method signature. Methods with the same signature can be stored in a delegate and can be passed as parameters or be invoked. But delegates are more structured, complex and requires more coding compared to Ruby blocks.

Function pointers of C allows developers to pass functions as parameters to other functions. They are not type safe as C# delegates so the developers are able to pass functions with different signatures as parameters.

Java has no concept called method references and it does that using interfaces and classes. We need to define our code block inside a class and pass that class to the method as a parameter. For an example we use this in implementing listeners, callback routines, and to pass utility code blocks such as compare routines to ‘sorting’ algorithms. Mostly we see these code blocks are implemented as inner classes or anonymous inner classes in java.

If you are a regular reader of my blog you may remember the post “Intermediate Representations vs Software Performance”. There I have explained how to pass a code block to a DAO so that as and when the DAO encounters a database record it will invoke the passed code block. If you look at the way of Ruby’s “array.each” method works you can see both these implementations share the same concept to a some extent.

So I may say ruby has adopted the concept of passing code blocks to a method and made it a really useful construct in the language.

Sunday, September 11, 2005

JMeter in Web Application Testing

JMeter in Web Application Testing

Last week I was discussing with Kartik on performing JMeter performance testing on the Ripple product. They were facing some difficulties in HTTP session handling in their JMeter test plan. This conversation allowed me to refresh my knowledge on this powerful testing framework. So I thought of making a note about JMeter on my blog. This will be a quick and short overview on some of the general JMeter capabilities.

When considering the non functional testing we often hear people talking about different types of tests. Some of those are “Load testing”, “Performance Testing” or “Stress Testing” on the application under test. First of all it is important to know the meaning and differences of these terms used in application testing.

a) Load testing is applying a heavy load on the application and monitors the behavior of it under a heavy load.

b) Performance testing may be carried out to ensure the application responses within acceptable timing on the requests it’s getting.

c) Stress testing is for ensuring fault tolerance capability of the application. For an example we may restart the database while application is in operation and check whether the application can recover under such a condition.

Let's have a quick look at JMeter. JMeter can be readily used in Load and performance testing. The test scripts we may create are called ‘Test Plans’. We can have create several test plans to test our application. These test plans can be used even as automated tests by running JMeter in non graphical mode.

There are several types of elements in a JMeter test plan. JMeter uses ‘Samplers’ to produce requests. It has ‘Logic controllers’ so we can control our test flow with them (e.g. to repeat a request). ‘Listeners’ are used to capture test results. Delays may be introduced by its ‘Timer’ elements.

Session handling is an important activity in any practical test plan. For general cookie based sessions we may use a Cookie manager to keep our cookie based session information across the requests. But when URL-Rewriting is used in session management we have to use “HTTP URL-Rewriting Modifier’ to keep session information across requests.

For me one of the most interesting elements in JMeter is its assertions. For an example returning HTTP 200 by our server doesn’t always mean that the request has been served successfully. That may be a user friendly error message returned by the server when a critical error occurred. We need to be more specific and probably wants to check the returned html to validate the server response. This is made possible with ‘Assertions’ in JMeter.

When configuring our test plan sometimes we face difficulties in simulating the exact browser behavior with JMeter. One handy tool that would help here is ‘TCPMON’ tool comes with Axis utilities. We can capture and compare http communications of JMeter with the communications of browser easily with this tool.

It is really interesting seeing JMeter as a part of a automated testing environment together with JUnit and HTTPUnit test frameworks…

Tuesday, September 06, 2005

Use of Visitors in Producing Data Streams

Use of Visitors in Producing Data Streams

Few days ago I saw a cool implementation of WBXML parser by Uchitha combining Visitor pattern and Composite pattern. This blog is a note on how we can use Visitor Pattern in producing output streams in a flexible manner.

We will take a specific example of data manipulation to demonstrate the idea. Assume a client and server communicating via a TCP socket. Server expects a specific protocol from the clients communicating with it. In our example assume clients can request two operations from the server.

a) read files from the server
b) execute commands on server

Further assume, before doing any of the above operations clients need to login to the server, and after the operation client logout from the server. We use Java TCP socket to send/receive data from/to server.

Say for an example we need to read a file from the server. Assume steps specified in the protocol are as follows:

1) send to server “LOGIN [username]
2) read from server’s “WELCOME
3) send to server “READ /tmp/myfile.txt
4) read from server “FILE-LENGTH=245
5) read from server next 245 bytes (which is the actual file data)
6) send to server “THANKS
7) read from server “BYE

All these commands are ASCII encoded and send/receive through a TCP socket created with the server. If we look at above conversation
step 1, 2 are related to ‘login’,
step 3, 4, 5 are related to ‘file read’ and
step 6,7 are related to ‘logout’ protocols.

By separating those steps in to separate entities we allow reuse of entities as well as we may combine them to perform more complex communication patterns. Ok… So far so good… but where is the visitor pattern?

Basic idea here is we have a visitor (Java TCP Socket) visiting a set of entities (Login, Read Files, Execute and Logout protocol handlers) to perform a certain task. All the protocol handlers have implemented a simple interface called “IVisitableEntity”. “accept” method is ready to welcome a visitor which will be the socket instance in this case.

public interface IVisitableEntity {
public Object accept(Socket visitor);
}

Concrete classes of this interface will be LoginProtocol, FileReadProtocol, ExecProtocol and LogoutProtocol. Here is an example implementation of LoginProtocol. This will handle the steps 1 and 2 specified above.


public class LoginProtocol implements IVisitableEntity {

private String username;

public LoginProtocol(String username) {
this.username = username;
}

public Object accept(Socket visitor) {
//get out put stream
OutputStream os = visitor.getOutputStream();

//get input stream as a BufferedReader so we can read full line once
BufferedReader in = new BufferedReader(visitor.getInputStream());

//write the login request to the socket
os.write(("LOGIN " + this.username).getBytes());

//read the response and validate it
String response = in.readLine();
validateResponse(response);

//we do not return any thing in this entity
return null;
}
}

In the same manner we can implement FileReadProtocol, ExecProtocol and LogoutProtocol concrete classes which will handle their own protocols atomically.

Now lets see how we assemble complex operations with these atomic protocols we have… say we have to implement a process which needs to read a file on the server and then executes a command on the server. This simple process may be coded as follows.

public void process() {
Socket socket = getTCPSocket();//obtain the socket to server

//login to the server, username as a parameter
LoginProtocol loginProtocol = new LoginProtocol("hasith");
loginProtocol.accept(socket);

//read the remote file content
FileReadProtocol fileReadProtocol = new FileReadProtocol("/tmp/myfile.txt");
byte[] fileData = fileReadProtocol.accept(socket);

//call the command on remote server
ExecProtocol execProtocol = new ExecProtocol ("command -o param");
execProtocol.accept(socket);
}

Look at the above implementation. Our socket act as a visitor, it visits different entities and those entities will accept the visitor and perform read/write on the socket according to the protocol.

Here are some notes on the pattern:
a) As all the protocol entities are implemented the “IVisitableEntity” interface we can even define the process flow dynamically at runtime.

b) Logic (protocol) is separated from data structure (socket data) fulfilling primary goal of Visitor pattern.

c) Logic entities are atomic and reusable in making complex process flows.

d) Also we may wrap the visiting socket to provide more extensibility. For an example to make the socket access thread safe.

This pattern may be also used on converting xml structure in to a plain text stream as I mentioned in the beginning of the blog. There, due to repetitive nature of xml elements and attributes we can also combine “Composite Pattern” to provide more power to our converter.