Secure traffic for rodsadai

Today we got Secure traffic for rodsadai working. Dan helped with several of the hostname issues (many thanks to him for that) and I got the client factory to pass the secure client instead of the generic sql client.

Tomorrow, I will be adjusting all of the tests to take into account proper spatial and time series formatting, and probably do a bit of re-architecting to turn secure access into a separate test (this will most likely involve passing the query client into the processor as opposed to having the processor call its own).

That and documenting, putting in descriptive errors, that sort of thing.

Teleconferences with collaborators

Tom, Ken and I talked with Ron Price from the University of Utah yesterday about the CoE activities. Ron has a non-secured service that we can start testing on Monday.

Utah is using many of the caBIG/caGrid grid components for security management and service development. Specifically they're using Introduce to speed up service development and GAARDS to work with security management.

Dan is starting to research GAARDS and how that can help with the security infrastructure of the PHIRG. We're going to start looking into Introduce for test/sample services.

Tom, Ken and I also spoke with the team at Ohio State that is responsible to the bulk of the caBIG infrastructure (including GAARDS and Introduce) and they were extremely helpful and open to collaboration. They also pointed us to a caGrid bulk data transfer service that uses web services and HTTPS to secure transfer large files and data sets.

So the PHIRG team has a lot of links to follow. Fortunately we have some deep expertise available to help with the tough questions.

Code of Conduct

Some may notice the new disclaimer posted to the wiki and blog. This disclaimer links to a Code of Conduct that has gone through the CDC clearance process to establish posting guidelines for CDC employees and contractors who contribute to the blog, wiki or sourceforge.

You can read the code of conduct for all the details, but basically it describes the rules as:

• Members will act with integrity and adhere to the highest standards of personal and professional ethics. As collaborations tend to be self-correcting, active participation means both offering suggestions and accepting them with a focus on product improvement. Personal attacks, hidden destructive code or other forms of harassment or intimidation will not be tolerated. Collaboration is highly encouraged, and although this may not always be positive, it should always be respectful and
  constructive.


• Only authorized committers are allowed to make changes to project related sites. Project leads determine authorized committers and assign permissions.


• Any sites not hosted by CDC or CDC resources should use separate authorization so as not to compromise existing CDC authentication and authorization procedures. This means that committers should not use an ID/ user name or password currently in use
  as their CDC ID / user name or password.


• No specific security related information should be shared. No information that would allow an unauthorized party to compromise CDC systems security shall be posted. This includes, but is not limited to: user names, user ids, passwords, IP addresses, private certificate information, specific system configuration.


• No restricted or privileged information should be posted that is limited in distribution rights. For example, there are US export controls for encryption routines and algorithms that cannot be shared with specific countries.


• No content in violation of US or international copyright shall be posted without explicit, written consent of the copyright holder.


• All content in draft form must be clearly marked with the words “DRAFT” both within the content itself and in any specific sites referencing the content.


• No personally identifiable health data shall be posted or stored on collaboration sites. This includes partially identifiable data containing fields such as age, race, sex, geolocation. Only sample, mock or test data shall be used.


• No posting of source code or unpublished materials relating to CDC or NCPHI developed production systems and applications.

Lots of stuff done, lots of stuff to do.

Things completed:

• Confirmed that secure Ogsa-dai was working on the new 205 box. Many thanks to Dan for his help and awesomeness.
• Have pulled the current RODSAdai files over to the 205 box, and linked the 205 box's maven to the repository, showing that I can recreate all the dev code and have it building in about 5 minutes in a new environment... and that is so cool.
• Got the HL7_ADTS table on the 205 box.

Things to be done now:

• Implement the secureClient for RODSAdai
• Document
• Expand tests to deal with time and spatial series data.
• Work with Jeremy on integrating with RODS and getting the security to work with tomcat.

Cheers, Things seems to be rolling along nicely, have a good 4th of July weekend!

Grid Messaging Test Cases

I worked on finishing up the first presentable draft of the Secure Reliable Grid Messaging PoC test cases. Its right now located at
http://sites.google.com/site/phgrid/active-projects
Please feel free to browse through the document and provide your feedback. Right now we have tried to explain the tests that we have performed so far, with others outlined in the document. After we created the first draft, Brian recommended some additions, which have been incorporated. If you think of a way where we can be more clear in explaining what has been tested so far, please let us know.

Public Health Case Reporting Use Case

As mentioned on the concall today, two of the AHIC use cases on the radar screen for this year of particular interest to PH are the case reporting (PHCR) use case, and the vaccine adverse event reporting (VAER) use case. The latter is still in development but the former was completed last spring. It may be useful to consider the biz processes and data elements in the PHCR use case document along with BSV use case.

Unknown CA Error: Fix

Globus was recently reinstalled on the Ubuntu node. Instead of installing the certificates in the /etc/grid-security directory, I choose to use the non-root install and install the certificates in the $GLOBUS_LOCATION/etc directory.

I received the following error in the $GLOBUS_LOCATION/var/container.log file when I tried to start the Globus container:

Remote exception was ;nested exception is: org.globus.common.ChainedIOException: Authentication failed [Caused by:Failure unspecified at GSS-API level [Caused by: Unknown CA]]

I knew the certificates were good, but it seemed like Globus was unable to locate the installed certificates. After researching the issue, I came across Globus Bug# 4303.
Link: http://bugzilla.globus.org/globus/show_bug.cgi?format=multiple&id=4303

Based on the information in the Bug Report, I discovered that Globus was looking for the certificates in the default, /etc/grid-security/certificates directory. To correct the problem I created two symbolic links. The first was a link from $GLOBUS_LOCATION/etc to /etc/grid-security. The second was a link from $GLOBUS_LOCATION/etc/certificates to $GLOBUS_LOCATION/TRUSTED_CA.

After creating the links, the Globus container started up.

Now time series is processing, and the ogsadai errors are gone

Yay for troubleshooting and debugging.

The cause for the OD errors was some transposed digits in the port number for Postgres.

Otherwise, I managed to code up the time-series and write a quick console test, and it passed!

Now, to move those tests into the automatic build testing, and then document it and work on secure data transport now that we have two securable nodes.

Also, I got to play with an OLPC (One Laptop Per Child) laptop today, it is really neat and there might be some cool grid computing aspects or data reporting to be made.

Harvard ESP activities

Dr. Lazarus from the Harvard CoE working on the ESP project posted some initial design comments on their ESP wiki.

Specifically, he is designing the stakeholders, data format, metadata, data entities and the sensitivity levels of data. This is a great start.

I've forwarded his comments on to the biosurveillance team (specifically Dr. Rhodes and Dr. Tokars) so they can provide their input/feedback.

Lab (Re)Engagement

Tom Savel, Dan and I met yesterday with the NCPHI Lab management team to review the resources needed for the three Proof of Concept projects. The lab management team approved the activities and are working on allocating and configuring the additional resources for the 3 PoCs.

This means that we can begin to reinvestigate using VM appliances for distribution as PHGrid nodes. In the past, an exception was made to allow a single VM appliance to be used, but now the lab team is able to support using VM appliances for additional nodes.

Related to the lab engagement is that the WS-RM portions of the Secure Reliable Grid Messaging PoC will not be posted directly to the blog/sourceforge/wiki until they are approved by the Gautam Kesarinath, the NCPHI project steward responsible for the WS-RM portion of the PoC.