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-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-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
Top Related