Browse Prior Art Database

Security architecture for a GRID container

IP.com Disclosure Number: IPCOM000010761D
Original Publication Date: 2003-Jan-16
Included in the Prior Art Database: 2003-Jan-16
Document File: 2 page(s) / 43K

Publishing Venue

IBM

Abstract

Implementation of security in an environment designed to efficiently run code on behalf of remotely connected users.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 1 of 2

Security architecture for a GRID container

If we want to allow multiple users to have shared access to a Java* Virtual Machine, or JVM, and run their code remotely in it then we must devise some means of keeping track of the times when their code is active so that we can implement some means to check that the operations they are attempting are ones that they are authorized to perform. Within the J2SE implementation the architecture allows us to mark some code as 'trusted' but of course that only means that it will do what it claims and not that the caller is actually allowed to do it. This trust mechanism can be extremely powerful and allow code to be sent to a machine and verified as being written by a trusted entity (through its signature). It is hence a powerful piece of the Java story. However, in an untrusted and shared environment we need something else; the ability to associate individual threads with a named Principal; an entity on behalf of which the code is currently running. There are two pieces involved in this; ensuring that we know the Principal associated with all incoming data and keeping track of that Principal as it becomes associated with individual threads. We offer solutions to both problems which have characteristics which differentiate this security architecture from others.

    First we ensure that all data in the network is protected by some session key which is private to a given Principal. This ensures that malicious users cannot mount replay or man-in-the-middle attacks on the container or otherwise impersonate a Principal. The principles are well known here but the application is novel and based around the existence of a communications layer which implements Endpoint, Session and Conversation objects. Endpoints represent other containers, Sessions represent the communications to another container on behalf of a given user and Conversations further subdivide those communications into correlated request and response flows. On Endpoint, Session or Conversation creation we can optionally supply a secure token. This token is encrypted on a password known only to the Container and a trusted third party and must be obtained from that trusted third party by the session initiator. The decrypted contents of the token specify the session password and encryption method to be employed for data. A public key approach would be an alternative implementation of the session setup. Once we have the session key and encryption method we can build the necessary encryption engine (Cipher) and associate it with the Endpoint, Session or Conversation. If we choose to encrypt all three then we have the data triple encrypted on different keys. A key design point here is that the implementation allows the Cipher object to be passed along with the data during the sending procedure. The net is that we can avoid the creation of multiple intermediate work buffers which hold the encrypted data. The data must be copied once in order to reme...