1 / 40

OPeNDAP/HTTP Security Issues

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

eugenia-parsons
Download Presentation

OPeNDAP/HTTP Security Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Client Server HTTP BASIC Authentication GET http://server:8080/thredds/dodsC/request.dds challenge HTTP/1.x 401 Unauthorized WWW-Authenticate: Basic realm=“TDS" Obtain password GET http://server:8080/thredds/dodsC/request.dds Authorization: Basicusername: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. Client Server HTTP Digest Authentication GET http://server:8080/thredds/dodsC/request.dds challenge HTTP/1.x 401 Unauthorized WWW-Authenticate: Digest realm=“TDS", qop="auth", nonce="6a7bdac5def00457ab6654ac333ad7dc", opaque="2aeea813b88a52a2fed10653f8346b88" Obtain password Calculate digest GET http://server:8080/thredds/dodsC/request.dds Authorization: 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 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. Client Server HTTPS Authentication GET https://server:8443/thredds/dodsC/request.dds challenge HTTP/1.x 401 Unauthorized WWW-Authenticate: Basic realm=“TDS" Obtain password GET https:server:8080/thredds/dodsC/request.dds Authorization: Basicusername: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 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. Client Server CAS SSO GET http://server:8080/data/request.nc.dds HTTP/1.x 302 Moved Temporarily Location: https://server:8443/cas/login?orgURL Set-Cookie: TDS Path=/thredds GET https://server:8443/cas/login?orgURL 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: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 HTTP/1.x 201 OK

  14. CAS SSO

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

  16. Client Server CAS SSO GET http://server:8080/data/request.nc.dds HTTP/1.x 302 Moved Temporarily Location: https://server:8443/cas/login?orgURL Set-Cookie: TDS Path=/thredds GET https://server:8443/cas/login?orgURL 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: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 HTTP/1.x 201 OK

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

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

  19. Client Server Logged in – Session based GET http://server:8080/data/request.nc.dds Cookie= jsession=76fddf33a34675fsf HTTP/1.x 201 OK

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

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

  22. Client Server Software stacks 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

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

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

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

  26. The END

  27. Community Data Portal (NCAR) Authorization Data request Central Authorization Client CDP http://cdp.ucar.edu:9080/thredds/dodsC/request.dds?authorize=3482090293840 authorize=3482090293840 TDS/Tomcat Filter ok

  28. CAS Authorization CDP Authorization Client Data request http://cdp.ucar.edu:9080/thredds/dodsC/request.dds http://cdp.ucar.edu:9080/thredds/dodsC/request.dds?authorize=3482090293840 authorize=3482090293840 TDS/Tomcat Filter ok

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

  30. Client Server TDS – logged in GET http://server:8080/data/request.nc.dds Cookie=TDS HTTP/1.x 201 OK Set-Cookie=TDS-2

  31. CDP TBD

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

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

  34. Tomcat / TDS Authorization TDS/Tomcat Realm

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

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

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

More Related