GSI Security Configuration in Tomcat 5.5

Download

To enable GSI security in Tomcat you will require download the J-Globus FX jars.

http://dev.globus.org/wiki/CoG_JGlobus_1.6.0

You will require following additional jars from
http://www.bouncycastle.org/latest_releases.html

1.bcprov-jdk16-143.jar
2.bcprov-ext-jdk14-143.jar

Note:

The binary distribution does not consist of a required class file. For this purpose you need to make the jars from source code.

Alternatively, you can download WS-Core binary distribution to obtain the required jar.

Configuring Tomcat Server with GSI Security

Make the following changes in $TOMCAT_HOME/conf/server.xml

(a) Add an HTTPS connector in the service tag.

<!-- Define a GSI HTTPS/1.1 Connector on port 8443

Supported parameters include:

proxy // proxy file for server to use

or

cert // server certificate file in PEM format

key // server key file in PEM format

cacertdir // directory location containing trusted CA certs

encryption (true/false) // enable/disable encryption

-->

<Connector port="9005"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true"

acceptCount="100" debug="0" scheme="https"

autoFlush="true"

protocolHandlerClassName="org.apache.coyote.http11.Http11Protocol"

socketFactory="org.globus.tomcat.catalina.net.BaseHTTPSServerSocketFactory"

proxy="Path to your proxy file"

cert="path to containers cert file"

key="path to containers key file"

cacertdir="path to certificates folder" />

(b) Add a valve in the engine tag.

< className="org.globus.tomcat.coyote.valves.HTTPSValve55"/>

(c) Tomcat Bug

When using ChunkedInputStream tomcat stores a 0 in its buffer every time a connection is closed. However, when obtaining a new request it does no ignore preceding 0’s resulting in a 0 501 Not implemented error.

This requires a minor change in tomcat’s source code.

In the class org.apache.coyote.http11.InternalInputBuffer’s parseRequestLine method

Replace the existing if block with the following while block.

do
{
// Read new bytes if needed.
if (pos >= lastValid)
{
if (!fill ())
throw new EOFException (sm.getString ("iib.eof.error"));
}
chr = buf [pos++];
}
while ((chr == Constants.CR) || (chr == Constants.LF) || chr == '0');

Replace the class file in $TOMCAT_HOME/server/lib/tomcat-http.jar

OR

Download the altered jar from

https://pegasus.isi.edu/svn/mcs/trunk/lib/tomcat-http.jar and replace it with $TOMCAT_HOME/server/lib/tomcat-http.jar

Refer To - http://mail-archives.apache.org/mod_mbox/tomcat-users/200904.mbox/%3C47CD64D7E22C3949A40CA4751EB20E811174077A70@boumail.infotrustgroup.com%3E
Some additional steps may be required if Globus is not installed on your machine.

Copying required JAR files

(a) Copy the following jars from the JGlobus FX distribution to $TOMCAT_HOME/common/lib

1.cog-jglobus.jar.
2.log4j-xxx.jar.jar.
3.puretls.jar.
4.cryptix32.jar.
5. cryptix-asn1.jar

(b) Copy the following jars from the JGlobus FX distribution If compile from source) OR from WS-Core Distribution to $TOMCAT_HOME/server/lib

1.cog-tomcat.jar

(c) Copy the following jar to $TOMCAT_HOME/common/lib

1. bcprov-jdk16-143.jar
2. bcprov-ext-jdk14-143.jar

Web Service (Axis 2) - Using GSI Security.

Server Side Implementation

Authentication is completely handled by the GSI security jars deployed on the tomcat server.

Obtaining the Authorized User DN can be accomplished with the following code snippet.

private String getAuthorizedUserDn ()
{
MessageContext messageContext = MessageContext.getCurrentMessageContext ();
HttpServletRequest httpRequest = (HttpServletRequest) messageContext.getProperty (HTTPConstants.MC_HTTP_SERVLETREQUEST);
return (String) httpRequest.getAttribute ("org.globus.gsi.authorized.user.dn");
}

The code snippet simply acquires the current HTTPServletRequest object from the message context of Axis2. Once the HTTPServletRequest object is obtained the authorized user DN can be obtained from the object using the getAttribute method of the object. The key o be passed to the getAttribute method is "org.globus.gsi.authorized.user.dn".

Client Side Implementation

The client side implementation is a bit tricky.

The JGlobus FX distribution provides an extended socket which handles GSI security. However, to be able to use this we need control over the socket that Tomcat server uses to send and receive SOAP messages.

Tomcat uses commons-http library for sending and receiving of HTTP messages. This library provides a mechanism with which we can provide it a custom socket. Since we need socket specific to a protocol the library requires us to register the custom socket factory class with the associated protocol.

Refer: http://hc.apache.org/httpclient-3.x/sslguide.html

Write the custom class to create a socket.

https://pegasus.isi.edu/svn/mcs/trunk/src/edu/isi/pegasus/httpclient/socket/MCSGSISocketFactory.java

Register the custom socket factory class with a protocol.

import org.apache.commons.httpclient.protocol.Protocol;
import edu.isi.pegasus.httpclient.socket.MCSGSISocketFactory;

Protocol protocol = new Protocol ("https", new MCSGSISocketFactory (), 8444);
Protocol.registerProtocol ("https", protocol);

Now, whenever tomcat requires a new socket to communicate using the https protocol it will call tomcats create socket method to obtain one.

References

http://dev.globus.org/wiki/CoG_JGlobus_1.6.0

http://www.bouncycastle.org/latest_releases.html

http://hc.apache.org/httpclient-3.x/sslguide.html

https://pegasus.isi.edu/svn/mcs/trunk/src/edu/isi/pegasus/httpclient/socket/MCSGSISocketFactory.java

https://pegasus.isi.edu/svn/mcs/trunk/src/edu/isi/pegasus/mcs/service/restful/MCSServiceImpl.java

http://mail-archives.apache.org/mod_mbox/tomcat-users/200904.mbox/%3C47CD64D7E22C3949A40CA4751EB20E811174077A70@boumail.infotrustgroup.com%3E

Thread Pools

Introduction

There are a variety of applications that provide services to clients. If the servers providing these services are to service one request at a time then the wait time to be serviced would be significantly high. One way to solve this problem is to use threads that could execute in parallel virtually. This leads to the ability to serve multiple requests simultaneously.

What are thread pools?

Thread pools are a collection of a certain number of threads that are created and destroyed dynamically as per the load on the server. The thread pool boasts of a minimum number of threads that are active at all times. When the load on the server increases beyond a certain point new threads are instantiated and added to the pool. Any incoming requests are served by threads in the pool that are idle.

Why use thread pools?

In most scenarios the service duration of a request is significantly small. Just imagine a HTTP server being requested to obtain a file. In this scenario all the server needs to do is place the file on the communication channel. Thread instantiation is an expensive operation, and if for each of these requests a thread is created and later on destroyed on completion of the service a significant cost is incurred in serving the request. To avoid this overhead a pool of threads is maintained.

Thread pool advantages

It minimizes the overhead incurred by the server to instantiate new threads and terminating threads when they have serviced a request.

Thread pool maintain up to a maximum of n number of threads, this prevent a server from creating too many threads when the load on the server is very high.

Thread pool disadvantages

Deadlocks can occur when multiple threads are using objects that cannot be shared. In such cases a thread may acquire a lock on an object A, and issue a request for another object B, while another thread may have the lock to an object B while waiting to acquire a lock on object A. This results in both threads being unable to progress with their tasks.

It is difficult to tune the thread properly to obtain the best performance.

Threads themselves require resources such as memory. If the thread pool size is too large the thread pool puts a load on the machine’s resources.

Active threads may work on shared resources, if these resources are accessed in an improper manner they can lead to the resources being inconsistent.

If the threads themselves are not written in a proper fashion there are chances that a thread may never finish executing, such a a piece of code running in an infinite loop.

Source Code

A rudimentary implementation of such a thread pool is hosted at Thread Pool Source Code.

To be able to use thread pool all you need to do is follow these steps.

1. Create a class that implements the Poolable interface.

public class Request implements Poolable

{

@Override
public void process ()
{

System.out.println ("Executing in thread.");

}

}

2. Instantiate the thread pool in the class where you want to use it.

ThreadPool threadPool = new ThreadPool ();

3. Add a request to be serviced to the queue.

threadPool.submitJob (objRequest);

4. Terminate the thread pool when exiting the server process.

threadPool.stopThreadPool (true);

Mylyn Unplugged - Part I

Anyone involved in development of a software product are aware of the large number of projects present in their workspaces showing hundreds of errors and thousands of warnings. The thing to take notice of is that the developer requires only two or three of the projects at any given time depending on the build structure of the larger whole. With lightening fast searches most programmers are willing to accept the hassles of having n projects in a memory sucking IDE, but completely unaware of existence of the Mylyn thought process.

Mylyn or Mylar as it was formerly known is a task management system. To a programmer a task is probably an entry in a timesheet application, or a defect assigned to them in Issue tracker tool like Bugzilla, Trac or Jira. Mylyn provides an integrated form of task management allowing a programmer to keep track of time spent on tasks or update status of issues in an issue tracker system directly from the development environment. So far the ideation doesn’t seem appealing or relevant to anything mentioned yet, but what is to follow will make life much simpler for a programmer. There are three features that are the essence of Mylyn; Task Management, Task Context, and Task tracking.

Mylyn allows any one involved with a project to define task from an IDE or what is more commonly known as a Defect, Enhancement, etc. into an issue tracking system. All stag programmers need not loose interest as Mylyn still holds promise. Mylyn allows for tasks to be created locally without having to be associated with an issue tracking system.

Task Context is an innovative way to fashion your workspace. Context to one is relevance, and task context is relevance to a task. Question that would be popping is what is relevant to a programmer’s task. The answer is anything and everything that one would refer to or need to fulfill the task. It could be a tutorial that you refer to learn about syntax or a formal document depicting the requirements of the task, or the most basic thing the source code files that are created or altered or deleted while working on a task.

What Mylyn manages for you is this context. The significance of this would be apparent when the feature is clubbed with a Rich UI. Mylyn keeps track of all material referred while a task is active and exposes only these files to the user.

Task tracking is a feature that is bound to please a Project Manager troubled with his employees not filling their timesheets and programmers who end up having to recollect time spent on tasks while filling up time sheets. Only a programmer involved with multiple tasks will realize the significance of this.

Why?

Some one once told me that the most important question one can ask is why. The advantages are manifold. For one, you reduce the number of applications you use during development by a decent number. Now you need not contend with an issue tracker to locate and update work items assigned to you, or a mailbox with automated mails from issue trackers, or timesheet filling systems. Secondly, while a task is active Mylyn actively keeps track about the time you spend on the task freeing you from scratching your brains while filling those hideous timesheets. And last and by far the best is automated context management. Mylyn’s confluence of a Rich UI with the task context will literally clear your workspace clutter. Mylyn keeps track of all files that are used for any task and selectively displays only that very context. Effectively 95% of your workspace has been flushed out of your view. Mylyn goes a step further to keep track of elements within the source files you alter like methods, or variables. In a contrasting way Mylyn clears information from your view while at the same time overwhelming you with specifics that you refer to in a file, only difference being that all that what you see is what you need to see.

Programmers using it feel that their IDE has gone intelligent, but the fact is that Mylyn uses your intelligence by remembering what materials you have referred to.

It’s time add some color to this article. Let say you have been assigned a task; to write your own collections API to mimic a java.util.ArrayList.

First thing we do is create a task using Mylyn’s task management system.

All you do is right click in the task list view and select New → Local Task and specify a name for the task and task particulars like its status, priority, an optional URL corresponding to a bug logged in a web based issue tracker, and your plan for the task, and your notes for the same.

The task content varies from issue tracker to issue tracker. Task definitions allow for adding your comments on a task, or attachments containing screenshots, or stack trace, etc.

All you do is click the purple ball at the top right.

And your workspace just vanishes.

Now all you do is go about your task creating, updating files and Mylyn remembers each of them.

If you take notice you would see that the outline for the class ICollections only shows capacity and size method, this is because these are the only methods that we have visited so far.

As more and more files are captured in the context, Mylyn intelligently filters out files that are less relevant. But that is not to say that they are out of the context, it’s only that the files are blurred from your vision. You can reopen the file easily using search feature of the IDE or open in from the context tab seen during the task creation.

All one need to do is move the slider left or right to control the filtering of the context.

All the while we have been chatting up on task Mylyn has actively kept track of the time spent on the task.

And saving the best for last is Repository synchronization.

Eclipse keeps track of change-sets. A change-set is a set of changes made during a session. Mylyn takes this a step further to keep track of a change-set relevant to a task. So you may refer to 100 files for a task but alter only 5 of them. So now while wanting to commit these changes to a version tracking system we need not explicitly select the altered files and say commit.

All a programmer needs to do is select synchronize with repository on your project.

Now you are moved to a team synchronize view showing all changes made to the selected project. Just for demonstration we have added a Constants.java file outside of a task i.e. while the task is inactive.

Now when you click show change-sets you get the view the change-set corresponding to the task. As you see above there are two changes listed; one made as a part of the Collections API task and other outside of the task.

If you recollect we had two files in our context, but we altered only one of them and added a file while the task was inactive, so the team synchronize view shows a number of change-sets; one change-set for each task and one change-set for files that were altered at the project level i.e. files that are not part of context of any task.

Not only does this feature make life easy for a programmer, but it makes is possible to rollback to a version without the committed changes. Real world task require working on hundreds of files, so if after committing a change-set one needs to rollback to a version without the change is move back one revision (incase of a version control with Atomic Commits).

In part II Mylyn Deep Dive we will explore task management using an issue tracker, and show some weakness in Mylyn’s implementation that becomes evident in real world situations.