OPeNDAP (Web) Services and Authentication
Creators: name: Gallagher, James
name: Potter, Nathan
name: Evans, Benjamin James Kingston
Publisher: name: Zenodo
Year: 2016

description: This presentation discusses the challenges and potential solutions for securing OPeNDAP web services with authentication mechanisms.

Key points:



HTTP and basic authentication:



Web services using HTTP can leverage its built-in security infrastructure for basic needs, even with browser-based UIs.

Adding authentication introduces complexities.



Single Sign-On (SSO):



Some SSO methods like OAuth2 utilize HTTP redirects and basic authentication, working well for browsers but potentially breaking programmatic clients.

Other SSO schemes like Shibboleth, while browser-friendly, require additional implementation for programmatic access.



Service chaining:



Chaining multiple OPeNDAP services creates authentication challenges as downstream services may need to authenticate on behalf of the user.

OAuth2 might offer a solution for this scenario.




Additional details:



The presentation compares different authentication methods, including Shibboleth and its ECP profile for programmatic clients.

It showcases various deployment scenarios with firewalls and different web server configurations.


Overall, the presentation emphasizes the need for careful consideration of authentication methods when securing OPeNDAP web services, especially when dealing with programmatic access and service chaining.
description: OPeNDAP, in conjunction with the Australian National University, documented the installation process needed to add authentication to OPeNDAP-enabled data servers (Hyrax, TDS, etc.) and examined 13 OPeNDAP clients to determine how best to add authentication using LDAP, Shibboleth and OAuth2 (we used NASA's URS).

We settled on a server configuration (architecture) that uses the Apache web server and a collection of open-source modules to perform the authentication and authorization actions. This is not the only way to accomplish those goals, but using Apache represents a good balance between functionality, leveraging existing work that has been well vetted and includes support for a wide variety of web services, include those that depend on a servlet engine such as tomcat (which both Hyrax and TDS do). Or work shows how LDAP, OAuth2 and Shibboleth can all be accommodated using this readily available software stack. Also important is that the Apache software is very widely used and is fairly robust – extremely important for security software components.

In order to make use of a server requiring authentication, clients must support the authentication process. Because HTTP has included authentication for well over a decade, and because HTTP/HTTPS can be used by simply linking programs with a library, both the LDAP and OAuth2/URS authentication schemes have almost universal support within the OPeNDAP client base. The clients, i.e. the HTTP client libraries they employ, understand how to submit the credentials to the correct server when confronted by an HTTP/S Unauthorized (401) response. Interestingly OAuth2 can achieve it’s SSO objectives while relying entirely on normative HTTP transport. All 13 of the clients examined worked.

The situation with Shibboleth is different. While Shibboleth does use HTTP, it also requires the client to either scrape a web page or support the SAML2.0 ECP profile, which, for programmatic clients, means using SOAP messages. Since working with SOAP is outside the scope of HTTP, support for Shibboleth must be added explicitly into the client software. Some of the potential burden of enabling OPeNDAP clients to work with Shibboleth may be mitigated by getting both NetCDF-C and NetCDF-Java libraries to use the Shibboleth ECP profile. If done, this would get 9 of the 13 clients we examined working.