DAP: Authentication Discussion

From OPeNDAP Documentation
Revision as of 21:39, 14 September 2011 by Ndp (talk | contribs) (→‎OAuth2)
⧼opendap2-jumptonavigation⧽

Overview

Here we discuss the various candidate technologies for authenticating and authorizing DAP client access to data held in Hyrax or other DAP servers.


SSL/TLS

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security for network transmissions. SSL was first publicly released in 1995. The technology is mature, proven secure, and is in widespread use through the internet. For the purposes of this DAP discussion we are solely in the versions TLS 1.2 (SSL 3.3) and higher. TLS/SSL relies on the "web of trust" concept wherein a Certificate Authority (CA) issues a signed certificate to a web service provider (in our case someone running Hyrax) and with this certificate the service provider can produce and sign client certificates. Recent events have shown that even this can be compromised.

This protocol uses an initial handshaking scheme in which the client and the server negotiate a secure connection "in the clear" using public/private key paris. At the end of this handshake both sides of the communication have the information required to compute a "master secret" which is then used to establish a secure communication pathway utilizing a block-cipher. This is a crucial point, as the use of public/private key encryption can very computationally expensive while the block cipher approach is much less so. Here is a sequence diagram describing the TLS handshaking process


When TLS is used with client certificates the server can easily ascertain the identity of the certificate holder. Thus in a DAP access model if the data service provider issues a client certificate to each user that requires authenticated access the server software can quickly discover who is requesting a particular data holding and pass that information to an authorization service to determine if the requested access is permitted. This authorization service may be as simple as configuring the server to demand authentication (via a known client certificate) to allow access to to some large segment of it's holdings, or it could be a more complex service that details which data granules a particular user may access.

DAP client access over SSL/TLS using client certificates.


One of the very attractive features of TLS is that it can easily be used for automated programmatic access to data. Once the client certificate has been issued to a user the user can pass that client certificate to multiple web browsers and different DAP client software implementations. The certificate can be used until it expires, or until the data service provider revokes it.

OpenID

OpenID is an open standard that describes how users can be authenticated in a decentralized manner. Using OpenID allows web/data services to unambiguously identify users without having to directly process their login credentials. The user always provides their login credentials to an OpenID authentication service. This keeps sensitive login information from "leaking" to various web services, yet allows these web services to identify their users. There are many OpenID authentication providers (Google, Yahoo, Verisign, MySpace, WordPress, etc.).

OpenID was developed for the web, and really, for web browsers. In the end every OpenID authentication is designed to happen in a browser with the human user filling out a form and pressing the "submit" button. Even an application with no particular GUI is pretty much required to pass the authentication step to a browser (example 1, example 2). This is possible because OpenID uses (a bunch of) redirect responses to route the application/browser from one place to another in order to authenticate and return session cookies to the initiating application.

Image courtesy of http://blogs.oracle.com/bblfish/entry/the_openid_sequence_diagram

OAuth2

OAuth2 (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.

OAuth2 uses tokens instead of credentials to permit access to data hosted by a given service provider. Each token grants access to a specific site (e.g. a video editing site) for specific resources (e.g. just videos from a specific album) and for a defined duration (e.g. the next 2 hours). This allows a user to grant a third party site access to their information stored with another service provider, without sharing their access permissions or the full extent of their data. This is a very important aspect of OAuth, because it places the OAuth service in the position of mediating the authorization to access data in addition to the authentication step.


OAuth2 is designed to allow native applications (like ncopen) to access restricted resources. For example Google has recently published this article about how to use their OAuth2 service from a native application.

The following sequence diagram is based on Google's description of their OAuth2 interface. It is very much abbreviated - the OAuth2 protocol involves many more redirects and intermediate tokens than shown here: OAuth2 sequence diagram

It is important to note

Discussion

All three of these technologies (at least claim to) provide secure authentication for service access. TLS/SSL is the oldest and most mature and is in many ways the simplest.


Why not OpenID??

Browser is required for all authentication. Returns session cookies


TLS vs OAuth2

something you have (cert or token) that you get from either a human or a web site.

  1. User goes and get an access thingy (cert or code)
  2. User install said thingy in their into their client (ncopen, loaddap, ODC, browser, etc)
  3. Client can now access data until the permission is revoked.


Authorization needs to be held close to the data. In OAuth the authentication service also provides authorization. This may not be practical for data site that contain tens of millions of granules unless the

Summary Table

Feature\Technolgy TLS/SSL OpenID OAuth2
Mature
true
true
not so much
Revocable Access
true
???
true
Credential Protection
true
true
true
Single Sign On
false
true
true
Authorization
false
false
true
Total $1.90

Conclusions