GAARDS Security implementation.

So, my next task for the coming months is to learn, tinker-with, and hopefully implement some cool bits of the GAARDS service as made by the folks up at Ohio State and their work with CaBIG and CaGrid. After a few preliminary readings of white papers and discussions with other people who have investigated various security models, I'm going to try and summarize things as I understand them, and invite people to correct my summarizations...

Globus works with X.509 certificates. To save a lot of complicated two-stepping, I'd say the easiest way to think of a certificate is as a licence with a special key embedded in them. Two nodes wanting to talk to each other have to present their certificates order to access services and establish secure communication, and the nodes have to "trust" each others certificates.

The way to get "automatic" trust without having to add keys into individual trust stores would be to have all the certificates issued by a trusted third party like Verisign or Thawte. This is like getting a passport or a drivers license as ID instead of having a business card with your name on it. It is also expensive, and to have to do it for every node on the grid beyond 5-node grids is pretty much unscalable.

Enter Dorian. Dorian is a GAARDS component and is essentially a Grid Service that allows other authentication methods to be used to access the grid. On one hand, it allows for someone to say "people authenticated by [method] at [node] are allowed to access these grid services". Thus, instead of having to have a certificate, one might just need to enter a username and password, or use their operating system credentials, or use a certificate issued by the Node itself instead of a larger third party.

The other critical component is Grid Trust Services (GTS) which allows for grids with different certificate sets to talk to each other and delegate which services on each grid are available to others. It also performs important syncing functions so that updates to access and authentication chains are propagated through the different grids.

There are other bits too, like GridGrouper which allows for simpler group paradigms (members of the group 'Gridviewer' would be able to access various gridviewers on different nodes... ) and Web Service Single Sign On which would allow an easy port for web applications to gain access to grid services... and you can read about it at the GAARDS website

Either way, I am at the periphery of understanding right now. I hope within a couple of days to have a really good grip on how security works now (and it's limitations) use cases for what we need, and a stronger correlation to how GAARDS will answer those use cases and which components are needed to do it.

Then, over the next couple of months, I'll need to implement those pieces and see what service modifications are needed to use them.

Service, method and input parameter authorization using GAARDS

At the Real-time Outbreak and Disease Surveillance Laboratory we've completed our first sprint to demonstrate input parameter authorization using the GAARDS infrastructure. In lieu of the security requirements of our Pennsylvania Ohio Biosurveillance Grid (PA-OH BiG) project when sharing notifiable disease data between health departments, we implemented input parameter authorization into our notifiable disease data grid application using Dorian, Grid Grouper and Introduce. This was motivated by our belief that it would be infeasible to create an additional service or service method (i.e., programming instead of configuring) every time a different set of valid input parameters for a different person/group were to be authorized.

GAARDS (i.e., Dorian and Grid Grouper) already provide authentication, service authorization and method level authorization but what we have done allows health departments to maintain extremely fine grained authorization using the same infrastructure. For example, we can now define a security group that is only allowed to make queries for data generated by bordering counties of a state. This group is defined by Grid Grouper and authentication is maintained using Dorian. Local mappings of user common names or groups to valid input parameters are maintained in the application using the RODS 6 data model.

We are really liking Dorian because local organizations need not maintain the credentials of foreign users if they have a trust relationship. Local nodes always know who (by common name) is accessing their services and the local nodes maintain local access control to their own data.

BTW: In the process of architecting this we spoke to the Justin Permar and the other caGrid folks over at Ohio State University who built Introduce. We thought we needed to modify the Introduce code but they were able to clearly explain why things are setup the way they are. Thanks to OSU.