Proposed Delegated Client Credential Support
in the OPeNDAP Back-End Server (BES)
Problem
From the Wikipedia Grid Security Infrastructure page, Delegation section:
“Authentication introduces a problem: often a service will have to
retrieve data form a source independent of the user; in order to do this,
it must be supplied with appropriate privileges. GSI allows for the
creation of delegated privileges: a new key is created, marked as a
delegated credential and signed by the user; it is then possible for a
service to act on behalf of the user to fetch data from the resource.”
The BES supports a simple authentication mechanism, but has no support for
delegated client credentials/privileges. The only way to send delegated privileges
to a BES data handler would be over the non-secure data channel - which would not
conform to proper security practices.
Without delegated client credential support the BES must rely on a front-end for
user authentication or access authorization and cannot perform jobs on behalf of the
user that require authorization or authentication. The BES is also unable to pass the
delegated client credential to another service as part of a secure grid.
Desired Behavior
It would be beneficial for the BES to support a secure mechanism whereby a client
can push delegated client credentials to BES data handlers, among other things.
This transaction must be secure and the credential representation should not be
tied to any specific credential system.
The data handler should use a BES interface to query and retrieve delegated client
credentials pushed to it over a secure data channel. The client credential object
retrieved by the data handler should be a generic object containing the serialized
credential and type information so the handler can determine the credential type
and instantiate the appropriate credential handle. It is the data handler’s
responsibility to build and use the specific credential handle from the generic
wrapper the BES provides.
Credential support of this kind will enable BES data handlers to act on behalf of the
user in a variety of tasks; including, but not limited to, secure data fetch, resource
authorization, and external service authentication. By keeping our credential
representation generic we do not tie the BES into a specific security infrastructure
and keep our dependency count low.
1 of 4
Proposed Architecture
PPT/SSL Protocol
In the PPT scheme the server is the software that is listening for a connection,
accepting commands, and providing responses. The client is the software that
initiates a connection, issues commands, and receives responses.
The BES client will connect to a BES server using the current handshake method,
and the server will request SSL authentication. This functionality is currently
available in the BES.
In the current implementation, once the session has been authenticated, the BES
client and the BES server drop the secure SSL connection. Instead of dropping the
SSL connection after authentication the BES client and the BES server will maintain
the secure connection. The BES server will listen on both the secure and the nonsecure connections. The BES client will have the ability to send requests to the BES
either over the secure connection, or the non-secure connection.
Certain requests can only be sent over a secure channel. The BES client will be
required to insure that any requests that require being sent over a secure channel
are done in that way. For example, the sending of client credentials to the BES
server will be sent over the secure channel.
The server will not care what commands are sent over a secure channel versus what
is sent over the non-secure channel. It will simply listen on both sockets and handle
requests from either. Responses to any given request will be transmitted over the
connection in which the request was made. So, for example, the sending of a
credential over the secure connection will have a response that goes over that same
secure connection. Another request that goes over the non-secure channel will have
the response sent over that same non-secure connection.
Passing the Credential to the BES
In order to get the client credential from the client to the server, there will be a new
command created. This command must be sent over a secure connection. The
command does not need to be the only command in the XML request document
passed to the BES, but considering that any responses to the XML request will also
be over the secure channel, it is recommended that no data requests be passed in
the same XML request document. The new command will have the following XML
representation:
<setCredential label=”credential_label”>
credential blob with escaped characers
</setCredential>
Where label is the type of the credential to be stored on the server. The value of the
2 of 4
setCredential tag will be the credential itself. Seeing that it is a binary blob, the
credential will need to be converted so no illegal characters are present in the XML
document. The BES client will be responsible for doing this conversion, and the BES
server will be responsible for converting the value back.
This new command will be provided as a part of the basic command set, along with
<showVersion/>, <setContainer>, and so on.
The response to the <setCredential> request will be a token that will be used by the
client for any future requests for data. The client will pass this token in future
requests to the server, the server using this token to look up the credential.
Passing the Credential in the Client
The BES will provide a new function to allow clients to easily pass a credential to the
server. There will be multiple implementations of this function in the different
languages providing BES support, specifically c, c++, and java. The basic signature of
the function will be:
int setCredential( char *label, size_t length, char *value, char **token ) ;
The parameter label is a character buffer which is used to specify the credential
type. This member is intended to be used like an enum, but has no restrictions on
types; it is up to the client to specify a type that the correct BES module will
recognize. The purpose of the label member is to allow the BES handler to check
that the serialized contents of the value member are of the expected type. A possible
scenario for this behavior would be if the structure of the extended header
attributes for ESG authorization changed, a new label would be used with the
updated scheme and a handler not expecting the new scheme would be able to
determine that there is a credential type mismatch.
The length parameter specifies the size of the character buffer specified by the value
member.
The value parameter is a character array that is used to contain the credential.
The token parameter is an out parameter and is assigned by the server. This value
will be used by future calls from the client to the server.
It is the implementation’s job to serialize and send the credential to the server.
Remember, the value of the credential is basically a binary blob. The
implementation will take that binary blob and serialize it in a way that is allowed
within an XML document.
Server side processing
Within the BES a globally available instance will be available for applications to
query for credentials. The BESCredentialList class will provide a singleton that will
3 of 4
provide methods for storing and accessing credentials. The list class will store
BESCredential instances. The BESCredential class will contain the credential label,
the token that is used by the server to access the credential, the size of the
credential value, and the credential value.
The credential value will be unserialized by the setCredential response handler and
stored in the credential list. The response handler for the setCredential request will
generate the token using a hash algorithm on the credential. This token will be
returned in the response document to be used in future requests requiring
authorization.
By unserialized the credential value we mean that the value will be converted back
into a binary blob that will be read by the requesting module. It will not be up to the
BES to make sense of the credential by determining type and extracting the
credential information.
Future requests using the token
We will add the token to requests for data.
<get type=”dods” definition=”def” returnAs=”nc” token=”token”/>
If available and authorization is required, then this token can be used to look up the
credential from the credential list, and use the credential for authorization.
Reference Material

Current OPeNDAP PPT Documentation
Questions
4 of 4