wiki:OpendapSecurity

OpendapSecurity

IS-ENES would like to support a secure option for interacting with remote datasets via OPeNDAP. Presently OPeNDAP has very limited security system.

  1. To simplify client APIs the username and password are commonly inserted into the OPeNDAP URL string. This encourages insecure password storage in clients.
  2. There is no standard for use of HTTP authn technologies within the OPeNDAP protocol. OPeNDAP inherits much of it's semantics from HTTP but the standard does not specify how clients and servers might use HTTP Basic Auth, Digest Auth, TLS/SSL or session cookies.

Client libraries and tools

Commonly used OPeNDAP libraries and tools that are built on them are:

Current libraries

Library Tool Notes Primary Target?
pydap pydap Reference OPeNDAP secure authn implementation being developed by CEDA YES
libnc-dap CDAT Many popular C/C++/FORTRAN NetCDF tools use this to support OPeNDAP. YES
libnetcdf-4.1 cdat_lite libnc-dap code merged into netcdf distribution. Intended to replace libnc-dap. YES
Java NetCDF library ncBrowse   YES
OPeNDAP C API ? Distributed from the OPeNDAP website NO
DAP++ ? Distributed from the OPeNDAP website NO
OPeNDAP Java API OPeNDAP Data Collector Distributed from the OPeNDAP website NO
OCAPI IDL Distributed from the OPeNDAP website. Superceded by OPeNDAP C API. NO?

Required client capabilities

  • HTTPS
  • HTTPS Basic Auth
  • Follow redirects
  • Remember cookies
  • Send client X509 certificate

Client capability matrix

:header-rows: 1 :class: wiki
Library HTTPS HTTPS Basic Auth Follow Redirects Remember Cookies Send client X509  
pydap ? ? ? ? ? ?
libnetcdf-4.1 ? ? ? ? ? ?
Java NetCDF ? ? ? ? ? ?
OPeNDAP C API ? ? ? ? ? ?
OPeNDAP Java API ? ? ? ? ? ?
OCAPI ? ? ? ? ? ?
libnc-dap ? ? ? ? ? ?

Client capability test cases

We could test the capabilities of each client using a pydap server configured to implement each of the required client capabilities. The server could report when a client has successfully passed a test.

It is assumed that a client's action upon "opening" an OPeNDAP URL is to request either the das response, the dds response or both in an unknown order. The client will then request a dods response to get a data subset.

In the descriptions below server responses are not explicitly itemised unless necessary. It is assumed the server responds to any client request with a standard OPeNDAP reponse unless stated otherwise.

HTTPS test

The server is configured to accept OPeNDAP requests over HTTPS.

  1. Client opens an OPeNDAP URL starting "https"
  2. Client requests das/dds responses -- Server logs success
  3. Client requests a dods response -- Server logs success
  4. Confirm client correctly interprets response

HTTPS Basic Auth test

The server is configured to accept OPeNDAP requests over HTTPS. The server asks the client to authenticate with Basic Auth before returning responses. Authorisation is required on every request

  1. Client opens HTTPS OPeNDAP URL
  2. Client requests URL.das/dds
  3. Server requests authorisation
  4. Client resends request with authorisation headers -- Server logs success
  5. Client requests URL.dods response
  6. Server requests authorisation
  7. Client resends request with authorisation headers -- Server logs success
  8. Confirm client correctly interprets response

note: OPeNDAP HTTP Basic Auth is in common use therefore if a client passes the HTTPS test it is likely to pass this test.

Redirect test

The server is configured to redirect published OPeNDAP requests to another URL that serves the responses. To preserve the independence of this test the redirect should not be to HTTPS.

  1. Client opens OPeNDAP URL1
  2. Client requests URL1.das/dds response
  3. Server redirects to URL2.das/dds
  4. Client requests URL2 -- Server logs success
  5. Client requests URL1.dods response
  6. Server redirects to URL3
  7. Client requests URL3 -- Server logs success
  8. Confirm client correctly interprets response

note: the URLs redirected to need not have the same DODS response suffix as the initial request

Cookie test

The server is configured to set a cookie on the first request. The test confirms that the client sends the cookie in subsequent requests.

  1. Client opens OPeNDAP URL
  2. Client requests URL.das/dds response
  3. Server responds, setting cookie
  4. Client requests URL.dods response with cookie -- Server logs success
  5. Confirm client correctly interprets response

X509 test

The server is configured to accept OPeNDAP requests over HTTPS and to verify the X509 certificate supplied by the client.

The expectation is that initially none of the clients will pass this test except pydap.

  1. Client is configured with an X509 user certificate
  2. Client opens OPeNDAP HTTPS URL
  3. Client requests das/dds response with X509 certificate
  4. Server verifies client's X509 certificate and logs success

Minimum OPeNDAP secure authn test

Passing all previous tests is only an indicator that a client could support OPeNDAP secure authn/authz because it is the combination of capabilities that is important. As a minimum a client would need to redirect between HTTP and HTTPS and back again, doing Basic Auth over HTTPS and retransmitting any cookies received.

The server is configured to redirect das/dds requests to an HTTPS URL, ask for Basic Auth and set a cookie in the HTTPS response. The server responds to dods requests by checking for a valid cookie.

  1. Client opens OPeNDAP URL1
  2. Client requests URL1.das/dds
  3. Server redirects to HTTPS URL2
  4. Client requests URL2
  5. Server requests Basic authorisation
  6. Client sends authorisation headers
  7. Server sets cookie and redirects to URL1.das/dds
  8. Client requests URL1.das/dds with cookie
  9. Client requests URL1.dods with cookie
  10. Server verifies cookie and responds -- server logs success
  11. Confirm client correctly interprets response

X509 OPeNDAP secure authn test

  1. Client opens OPeNDAP URL1
  2. Client requests URL1.das/dds
  3. Server redirects to HTTPS URL2
  4. Client requests URL2 with X509 certificate
  5. Server verifies client's X509 certificate and logs success
  6. Server sets cookie and redirects to URL1.das/dds
  7. Client requests URL1.das/dds with cookie
  8. Client requests URL1.dods with cookie
  9. Server verifies cookie and responds -- server logs success
  10. Confirm client correctly interprets response