| • |
|
|
|
|||
|
||||
The Netcdf-Java library uses the Apache HttpClient library to access OPeNDAP datasets, and to read files served by HTTP. When dataset access must be restricted to authorized users, the server will issue an HTTP authentication challenge. We call these restricted datasets. The HttpClient library handles the details of the HTTP protocol, but the application layer must be responsible for supplying the credentials that authenticate the user. If you want to access restricted datasets with the Netcdf-Java library, you must plug-in a CredentialsProvider object (see below).
Authentication means establishing the identity of a user. In most cases, this is done with a user name and password. A stronger way to do this is to use digital signatures with client certificates, but generally this is a lot of work. The Netcdf-Java library supports HTTP Basic and Digest Authentication, with or without Secure Socket Layer (SSL) encryption. Its up to the server to decide which kind of HTTP authentication is needed.
If you are writing an interactive client application, you might prompt the user for the user name and password. A non-interactive application needs to have some kind of a lookup table or database to supply the information.
Having established a user's identity, authorization is the process of deciding if that user has the right to access a particular dataset. Most servers, including the THREDDS Data Server (TDS), use role-based authorization. When a user is logged into a particular server, access is granted based on what roles the user has been given by that server. The practical effect of this is that if the user doesnt have access rights to a dataset, they are not prompted to enter a different username/password. They have to logout and login as a different user.
Typically a user makes several or many requests to get data from a particular dataset. Some servers (like the TDS) establish a session that keeps track of a user, so that the user doesn't have to send the username/password with each request. A session is enabled by sending a Session Cookie between the server and client. The session remains established based on the rules of Cookie processing and HTTP Protection Spaces. This means that every time a restricted dataset is opened, the application layer may be asked for user credentials for that dataset. Once authentication and authorization is established, no further prompting is made while the dataset is open, as long as the session doesnt time out. Typically a session times out if there is no activity on it for some time, e.g. 30 minutes.
Servers that dont use sessions or other methods may require that the username/password be sent with every request.
In order to access restricted datasets with the Netcdf-Java library, you must plug-in a CredentialsProvider that implements the org.apache.commons.httpclient.auth.CredentialsProvider interface, which has one method:
public Credentials getCredentials(AuthScheme scheme,
String host,
int port,
boolean proxy)
throws CredentialsNotAvailableException
You can write your own, or, for GUI programs, use the thredds.ui.UrlAuthenticatorDialog class, which pops up a Dialog Box, similar to how FireFox and other browsers work. Register your CredentialsProvider for both HTTP and OPeNDAP access, using ucar.nc2.dataset.HttpClientManager.init():
CredentialsProvider provider = new thredds.ui.UrlAuthenticatorDialog(frame);
ucar.nc2.dataset.HttpClientManager.init(provider, userAgent);
The userAgent should be the name of your Application, which is added to the HTTP User-Agent header, and allows servers to track which applications are accessing it.
This document is maintained by John Caron and was last updated on April 20, 2007
| Contact Us • Site Map • Search • Terms and Conditions • Privacy Policy • Participation Policy | ||||||
|
||||||
