1. OPeNDAP/HTTP Security Issues
John Caron/Unidata
Ash Wednesday, 2007

2. 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

3. Overview HTTP Basic, Digest Authentication
TLS/SSL/HTTPS Authentication
CAS Single Sign On
Form based authentication
HTTPS Redirect / Sessions
Summary

4. HTTP BASIC Authentication
Client
Server
GET
challenge
HTTP/1.x 401 Unauthorized
WWW-Authenticate: Basic realm=“TDS"
Obtain password
GET
Authorization: Basic username:password
HTTP/1.x 200 OK
Data

5. 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

6. HTTP Digest Authentication
Client
Server
GET
challenge
HTTP/1.x 401 Unauthorized
WWW-Authenticate: Digest realm=“TDS", qop="auth",
nonce="6a7bdac5def00457ab6654ac333ad7dc",
opaque="2aeea813b88a52a2fed10653f8346b88"
Obtain password
Calculate digest
GET
Authorization: Digest username="tigge", realm=“TDS",
nonce="6a7bdac5def00457ab6654ac333ad7dc",
uri="/thredds/dodsC/request.dds",
response="5b76b64babb0ca64b62a3282a ",
opaque="2aeea813b88a52a2fed10653f8346b88",
qop=auth, nc= , cnonce="082c875dcb2ca740"
HTTP/1.x 200 OK
Data

7. 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

8. 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)

9. GET https://server:8443/thredds/dodsC/request.dds
HTTPS Authentication
Client
Server
GET
challenge
HTTP/1.x 401 Unauthorized
WWW-Authenticate: Basic realm=“TDS"
Obtain password
GET
Authorization: Basic username:password
HTTP/1.x 200 OK
Data

10. 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

11. HTTPS/TLS cost “Faster CPUs will eventually bridge the gap”
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”
Performance Analysis of TLS Web Servers
CRISTIAN COARFA, PETER DRUSCHEL, and DAN S. WALLACH, Rice University
ACM Transactions on Computer Systems, Vol. 24, No. 1, February 2006.

12. 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

13. GET http://server:8080/data/request.nc.dds
CAS SSO
Client
Server
GET
HTTP/1.x 302 Moved Temporarily
Location:
Set-Cookie: TDS Path=/thredds
GET
HTTP/1.x 201 OK
Login Page
POST /cas/login?service=orgURL
username=test&password=test&lt=LT-0-rFsBI72KV4A9bXbhVwcA
HTTP/1.x 302 Moved Temporarily
Location:
Set-Cookie: CAS; Path=/cas
GET
Cookie=TDS
HTTP/1.x 201 OK

14. CAS SSO

15. GET http://server:8080/data/request.nc.dds
CAS SSO – logged in
Client
Server
GET
HTTP/1.x 302 Moved Temporarily
Location:
Set-Cookie: <sessionID>; Path=/thredds
GET
Cookie=CAS
HTTP/1.x 302 Moved Temporarily
Location:
GET
Cookie=<sessionID>
HTTP/1.x 201 OK

16. GET http://server:8080/data/request.nc.dds
CAS SSO
Client
Server
GET
HTTP/1.x 302 Moved Temporarily
Location:
Set-Cookie: TDS Path=/thredds
GET
HTTP/1.x 201 OK
Login Page
POST /cas/login?service=orgURL
username=test&password=test&lt=LT-0-rFsBI72KV4A9bXbhVwcA
HTTP/1.x 302 Moved Temporarily
Location:
Set-Cookie: CAS; Path=/cas
GET
Cookie=TDS
HTTP/1.x 201 OK

19. 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

20. GET http://server:8080/data/request.nc.dds
HTTPS Redirect
Client
Server
GET
HTTP/1.x 302 Moved Temporarily
Location:
Set-Cookie: jsession=76fddf33a34675fsf
GET
Cookie= jsession=76fddf33a34675fsf
challenge
HTTP/1.x 401 Unauthorized
WWW-Authenticate: Basic realm=“TDS"
Obtain password
GET
Authorization: Basic username:password
Cookie= jsession=76fddf33a34675fsf
HTTP/1.x 302 Moved Temporarily
Location:
GET
Cookie= jsession=76fddf33a34675fsf
HTTP/1.x 201 OK

21. Logged in – Session based
Client
Server
GET
Cookie= jsession=76fddf33a34675fsf
HTTP/1.x 201 OK

22. 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”

23. HTTPS Redirect Client must Cost Vulnerable to session hijacking
follow redirects
return cookies
Support SSL
Cost
4x messages for login
No extra messages after logging in
Vulnerable to session hijacking

24. Software stacks Application OPeNDAP server Web server/
Client
Server
Application
GUI
OPeNDAP server DB
Password
Web server/
Servlet container
OPeNDAP library
HTTP library
HTTP library
Follow redirects
Calculate digests
SSL encryption
Session tracking
Basic, Digest Authentication
SSL

25. 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 ?

26. 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

27. 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

28. The END

29. Community Data Portal (NCAR) Authorization
Data request
Central Authorization
Client
CDP
authorize=
TDS/Tomcat
Filter ok

30. CAS Authorization CDP Authorization Client
Data request
authorize=
TDS/Tomcat
Filter ok

31. TDS: Pluggable Authorization
Step 1
Data request
Client
TDS
Redirect URL= Auth request
Step 2
Auth request
Client
Central Authorization
Redirect URL = Data?ticket
Validate ticket
Step 3
Data?ticket
Client
TDS
Return Data

32. TDS – logged in Client Server
GET
Cookie=TDS
HTTP/1.x 201 OK
Set-Cookie=TDS-2

33. CDP TBD

35. 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”/>

36. 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>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>restrictedDatasetUser</role-name>
</auth-constraint>
</security-constraint>

37. Tomcat / TDS Authorization
TDS/Tomcat
Realm

38. GET http://cdp.ucar.edu:9080/data/request.nc.dds
HTTPS Redirect - 2
GET
HTTP/1.x 302 Moved Temporarily
Location:
GET
HTTP/1.x 401 Unauthorized
WWW-Authenticate: Basic realm=" THREDDS Data Server "
GET
Authorization: Basic Y2Fyb246Y2FybyQ=
HTTP/1.x 302 Moved Temporarily
Location:
Cookie: jsession=76fddf33alsf
GET
Cookie: jsession=76fddf33alsf

39. GET http://server:8080/data/request.nc.dds
Digest Redirect
Client
Server
GET
HTTP/1.x 302 Moved Temporarily
Location:
Set-Cookie: jsession=76fddf33a34675fsf
GET
Cookie= jsession=76fddf33a34675fsf
challenge
HTTP/1.x 401 Unauthorized
WWW-Authenticate: Digest realm=“TDS"
Obtain password
GET
Authorization: Digest username:password
Cookie= jsession=76fddf33a34675fsf
HTTP/1.x 302 Moved Temporarily
Location:
GET
Cookie= jsession=76fddf33a34675fsf
HTTP/1.x 201 OK

40. GET http://cdp.ucar.edu:9080/data/request.nc.dds
Digest with Sessions
GET
HTTP/1.x 401 Unauthorized
WWW-Authenticate: Digest realm=" THREDDS Data Server “
GET
Authorization: Digest blah-blah
HTTP/1.x 200 ok
Cookie: jsession=76fddf33alsf
Data