OPeNDAP/HTTP Security Issues

John Caron/Unidata

Ash Wednesday, 2007

Goals

• Add ability to restrict access to specified datasets” to THREDDS Data Server– Allow CDP to run TDS

• Explore possible security mechanism for TDS’ OPeNDAP server

• Want it to work with any OPeNDAP client by using standard HTTP protocols

Overview

• HTTP Basic, Digest Authentication

• TLS/SSL/HTTPS Authentication

• CAS Single Sign On – Form based authentication

• HTTPS Redirect / Sessions

• Summary

Client Server

GET http://server:8080/thredds/dodsC/request.dds

HTTP/1.x 401 UnauthorizedWWW-Authenticate: Basic realm=“TDS"

GET http://server:8080/thredds/dodsC/request.ddsAuthorization: Basic username:password

HTTP/1.x 200 OKData

HTTP BASIC Authentication

Obtain password

challenge

BASIC Authentication

• When challenged, Client must be able to respond with username/password

• 2x messages (2x latency). Can preemptively authenticate:– Protection space (aka authentication scope):

all paths at or below current URI– Client tracks (server:port/path/*, Realm,

authentication scheme, user/password)

• Problem: password is clear text

Client ServerGET http://server:8080/thredds/dodsC/request.dds

HTTP/1.x 401 UnauthorizedWWW-Authenticate: Digest realm=“TDS", qop="auth", nonce="6a7bdac5def00457ab6654ac333ad7dc", opaque="2aeea813b88a52a2fed10653f8346b88"

GET http://server:8080/thredds/dodsC/request.ddsAuthorization: Digest username="tigge", realm=“TDS", nonce="6a7bdac5def00457ab6654ac333ad7dc", uri="/thredds/dodsC/request.dds", response="5b76b64babb0ca64b62a3282a8693202", opaque="2aeea813b88a52a2fed10653f8346b88", qop=auth, nc=00000001, cnonce="082c875dcb2ca740"

HTTP/1.x 200 OKData

HTTP Digest Authentication

Obtain password Calculate digest

challenge

DIGEST Authentication

• Response is a digest of (user, password, realm, nonce). Nonce prevents replay attacks.

• Client must be able to calculate digests– Handled by network libraries

• Nonce complicates preemptive authorization– Unique nonce: doubles the messages– Timeout nonce: “window of vulnerability”– Next nonce sent with previous response: can’t

pipeline • Protection space: all URIs on the server, or

specify explicitly with WWW-Authenticate header

Digest Authentication

• Cryptographically not as strong as public key encryption

• Need careful nonce handling for pre-emptive authorization without vulnerability

• Vulnerable to “Man-in-the-Middle” attacks– inability for client to validate the server

• Storing passwords on the server, even encrypted, is a problem if server is compromised

• Message not encrypted (no confidentiality)

Client Server

GET https://server:8443/thredds/dodsC/request.dds

HTTP/1.x 401 UnauthorizedWWW-Authenticate: Basic realm=“TDS"

GET https:server:8080/thredds/dodsC/request.ddsAuthorization: Basic username:password

HTTP/1.x 200 OKData

HTTPS Authentication

Obtain password

challenge

HTTPS Authentication

• Client must be able to use TLS (Transport Layer Security), aka SSL:– Certificates: server (required), client (optional)– Encryption (CPU intensive)– But handled by network libraries

• No replay, no Man-in-middle, content is confidential

• Problem: cost– SSL socket setup = 2 extra roundtrips (?)– Data is encrypted

HTTPS/TLS cost

Performance Analysis of TLS Web ServersCRISTIAN COARFA, PETER DRUSCHEL, and DAN S. WALLACH, Rice UniversityACM Transactions on Computer Systems, Vol. 24, No. 1, February 2006.

Fig. 10. Throughput in hits/sec. Percentages show the throughput relative to non-TLS Apache on the same platform. Average file size: 46KB.

“TLS imposes a factor of 3.4 to 9 overhead.”

“Faster CPUs will eventually bridge the gap”

Central Authentication Service Single Sign On (SSO)

• Open source, Yale/JA-SIG• Server: Java Servlet, pluggable Authentication • Clients in Java, Ageci/Spring, Perl, php,

Ruby, .NET, Zope, etc

Client Server

GET http://server:8080/data/request.nc.dds

HTTP/1.x 302 Moved TemporarilyLocation: https://server:8443/cas/login?orgURLSet-Cookie: TDS Path=/thredds

GET https://server:8443/cas/login?orgURLHTTP/1.x 201 OK

POST /cas/login?service=orgURLusername=test&password=test&lt=LT-0-rFsBI72KV4A9bXbhVwcA

HTTP/1.x 302 Moved TemporarilyLocation:http://server:8080/data/request.nc.dds?ticket=<id>Set-Cookie: CAS; Path=/cas

GET http://server:8080/data/request.nc.dds?ticket=<ticket> Cookie=TDS

CAS SSO

Login Page

HTTP/1.x 201 OK

CAS SSO

Client Server

GET http://server:8080/data/request.nc.dds

HTTP/1.x 302 Moved TemporarilyLocation: https://server:8443/cas/login?orgURLSet-Cookie: <sessionID>; Path=/thredds

GET https://server:8443/cas/login?orgURLCookie=CAS

HTTP/1.x 302 Moved TemporarilyLocation:http://server:8080/data/request.nc.dds?ticket=<id>

GET http://server:8080/data/request.nc.dds?ticket=<ticket> Cookie=<sessionID>

CAS SSO – logged in

HTTP/1.x 201 OK

Client Server

GET http://server:8080/data/request.nc.dds

HTTP/1.x 302 Moved TemporarilyLocation: https://server:8443/cas/login?orgURLSet-Cookie: TDS Path=/thredds

GET https://server:8443/cas/login?orgURLHTTP/1.x 201 OK

POST /cas/login?service=orgURLusername=test&password=test&lt=LT-0-rFsBI72KV4A9bXbhVwcA

HTTP/1.x 302 Moved TemporarilyLocation:http://server:8080/data/request.nc.dds?ticket=<id>Set-Cookie: CAS; Path=/cas

GET http://server:8080/data/request.nc.dds?ticket=<ticket> Cookie=TDS

CAS SSO

Login Page

HTTP/1.x 201 OK

Form based authentication

• Login page requires human intervention– Or perhaps can figure out how to respond

automatically

• May be a burden even for a GUI application to process the form

• Really appropriate only for portals.• Want software (web service) to fetch the

resource without human intervention– Acting as a proxy for an authorized human

Client Server

GET http://server:8080/data/request.nc.dds

HTTP/1.x 302 Moved TemporarilyLocation: https://server:8443/loginSet-Cookie: jsession=76fddf33a34675fsf

GET https://server:8443/login/roleCookie= jsession=76fddf33a34675fsf

HTTP/1.x 302 Moved TemporarilyLocation:http://server:8080/data/request.nc.dds

GET http://server:8080/data/request.nc.dds Cookie= jsession=76fddf33a34675fsf

HTTPS Redirect

HTTP/1.x 201 OK

HTTP/1.x 401 UnauthorizedWWW-Authenticate: Basic realm=“TDS"

GET https:server:8443/loginAuthorization: Basic username:passwordCookie= jsession=76fddf33a34675fsf

Obtain password

challenge

Client Server

GET http://server:8080/data/request.nc.ddsCookie= jsession=76fddf33a34675fsf

Logged in – Session based

HTTP/1.x 201 OK

Session Cookies

• Vulnerable to replay attack= session hijack

• Change cookie each time – back button may not work

• Keep track of user’s IP: hard to get responses back if IP is spoofed– users with variable IP addresses (use

FF.FF.FF.00 or FF.FF.00.00)

• No longer stateless – “logged in”

HTTPS Redirect

• Client must – follow redirects– return cookies– Support SSL

• Cost– 4x messages for login– No extra messages after logging in

• Vulnerable to session hijacking

Software stacks

Application

OPeNDAP library

HTTP libraryHTTP library

Web server/Servlet container

OPeNDAP server

Client Server

Password

Follow redirectsCalculate digestsSSL encryption

Session trackingBasic, Digest AuthenticationSSL

DB

GUI

Summary: Servers

• Digest authentication may be good enough– Probably Basic may be good enough!

• Full HTTPS is perhaps 2-3X slower.

• HTTPS-Redirect with sessions may be a good compromise– Session must check IP address

• Avoid Form authentication “human in the loop” unless some standard is agreed on.– Exceptions ? CAS ?

How much security needed?

• Protect access to scientific data

• No $$ or secrets are probably involved

• No Grid computations are being spawned

• Why are these being restricted?– Really resource control?

• Answer: only the data provider can decide

Summary: Client libraries

• To allow full range of server options, client libraries should support:– Basic and Digest Authentication– SSL – Follow redirects– Return cookies– Hooks for applications to provide username/

password based on URL and Realm.

• Should be a written OPeNDAP standard

The END

Community Data Portal (NCAR) Authorization

TDS/Tomcat Filter

http://cdp.ucar.edu:9080/thredds/dodsC/request.dds?authorize=3482090293840

authorize=3482090293840

Central Authorization

ok

CDPClient Data request

CAS Authorization

TDS/Tomcat Filter

http://cdp.ucar.edu:9080/thredds/dodsC/request.dds

authorize=3482090293840

CDP Authorization

ok

Client

Data request

http://cdp.ucar.edu:9080/thredds/dodsC/request.dds?authorize=3482090293840

TDS: Pluggable Authorization

TDSClient Data request

Redirect URL= Auth request

Validate ticket

Central AuthorizationClient Auth request

Redirect URL = Data?ticket

TDSClient Data?ticket

Return Data

Step 1

Step 2

Step 3

Client Server

GET http://server:8080/data/request.nc.ddsCookie=TDS

TDS – logged in

HTTP/1.x 201 OKSet-Cookie=TDS-2

CDP TBD

TDS Restricted Datasets

Add roles in tomcat-users.xml <role rolename="restrictedDatasetUser"/><user username=“johnny" password=“boy” roles="restrictedDatasetUser"/>

Specify in catalog.xml<dataset name="Test Restricted Dataset" serviceName=“dods" urlPath=“myData/testData.nc" restrictAccess="restrictedDatasetUser”/>

Standard TDS web.xml <filter-mapping> <filter-name>RestrictedAccessFilter</filter-name> <url-pattern>/restrictedAccess/*</url-pattern> </filter-mapping> … <security-constraint> <web-resource-collection> <web-resource-name>restricted access datasets</web-resource-name> <url-pattern>/restrictedAccess/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <role-name>restrictedDatasetUser</role-name> </auth-constraint> </security-constraint>

Tomcat / TDS Authorization

TDS/Tomcat Realm

GET http://cdp.ucar.edu:9080/data/request.nc.dds

HTTP/1.x 302 Moved TemporarilyLocation: https://cdp.ucar.edu:9080/restrict/role

GET https://cdp.ucar.edu:9080/restrict/role

HTTP/1.x 401 UnauthorizedWWW-Authenticate: Basic realm=" THREDDS Data Server "

GET https://cdp.ucar.edu:9080/restrict/roleAuthorization: Basic Y2Fyb246Y2FybyQ=

HTTP/1.x 302 Moved TemporarilyLocation: http://cdp.ucar.edu:9080/data/request.nc.ddsCookie: jsession=76fddf33alsf

GET http://cdp.ucar.edu:9080/data/request.nc.ddsCookie: jsession=76fddf33alsf

HTTPS Redirect - 2

Client Server

GET http://server:8080/data/request.nc.dds

HTTP/1.x 302 Moved TemporarilyLocation: http://server:8080/restrictedAccess/tiggeDataSet-Cookie: jsession=76fddf33a34675fsf

GET http://server:8080/restrictedAccess/tiggeData Cookie= jsession=76fddf33a34675fsf

HTTP/1.x 302 Moved TemporarilyLocation:http://server:8080/data/request.nc.dds

GET http://server:8080/data/request.nc.dds Cookie= jsession=76fddf33a34675fsf

Digest Redirect

HTTP/1.x 201 OK

HTTP/1.x 401 UnauthorizedWWW-Authenticate: Digest realm=“TDS"

GET http://server:8080/restrictedAccess/tiggeData Authorization: Digest username:passwordCookie= jsession=76fddf33a34675fsf

Obtain password

challenge

GET http://cdp.ucar.edu:9080/data/request.nc.dds

HTTP/1.x 401 UnauthorizedWWW-Authenticate: Digest realm=" THREDDS Data Server “

GET http://cdp.ucar.edu:9080/data/request.nc.ddsAuthorization: Digest blah-blah

HTTP/1.x 200 okCookie: jsession=76fddf33alsfData

Digest with Sessions