Application of authentication methods to all FDSN web services
Chad Trabant
In 2021 a request was submitted to add an authentication mechanism to the
fdsnws-station service, similar to fdsnws-dataselect via this issue:
https://github.com/FDSN/WebServiceSpecificationCommonalities/issues/6
This resulted in a proposal at the 2021 meeting to apply the same
fdsnws-dataselect mechanism, aka the *queryauth* endpoint, to all FDSN web
service specifications, as an optional mechanism for data centers to
implement if they wish. A consensus on the topic was not reached at the
meeting. An excerpt from meeting minutes is below for convenience.
*I call for a discussion to determine the appropriate response to the
proposal to include queryauth method in all FDSN web service
specifications, or alternate solutions.* Please respond to this email, or
responses, if possible, to keep the discussion in a single thread.
The *discussion period will end on 27 August* and will be followed by a
vote to adopt a solution, potentially for a small variety of options.
regards,
Chad Trabant
Working Group 3 Chair
Relevant discussion from draft 2021 WG meeting minutes
<https://fdsn.org/media/wg/III/2021/WGIII_Meeting_Minutes_-_India_2021.pdf>:
------------- Start of excerpt
Authentication for all FDSN web service specifications
Chad presents a proposal to generalize authentication for all web service
specifications.
Peter suggests that there is coordination with Javier in their work to
support federated identity management within EIDA.
Tim expressed concern that a center with 100% authentication requirement at
a data center opens the door to exclusion of data being exposed to the
public, even as it helps the CTBTO to make its data available.
Javier indicates that authentication and authorization are different, and
currently the primary goal is to monitor usage patterns through user IDs
and generate usage statistics for funding agencies. First question, do we
want to see authentication for all data access methods at a data center?
Philip asks whether data that is to be freely available should require any
kind of authentication. Marcelo wonders if the “queryauth” method is being
misused for open data requiring login, instead attach authentication for
the query method for open data.
Tim indicates that it is very important for schools that a login
requirement to access data is not complicated and does not impede access to
data repositories.
Peter comments that this proposal to expand the use of queryauth should not
encourage all centers to begin requiring logins, but instead let this open
the door for CTBTO to expose their data using authentication.
Philip indicates the complication of machine to machine connectivity to
information when harvesting from other data centers.
Nick proposed that if "queryauth" is optional, perhaps the standard "query"
can be made mandatory. Chad responded that a datacenter can implement
query, but return nothing.
------------- End of excerpt
Stephan Herrnkind
On Tue, 04 Jul 2023 23:11:00 -0000 "Chad Trabant (via FDSN)"
<fdsn-wg3-pro...@lists.fdsn.org> wrote:
> [..] I call for a discussion to determine the appropriate response to the
> proposal to include queryauth method in all FDSN web service specifications,
> or alternate solutions.
I suggest to drop HTTP Digest Authentication in favor of HTTP Basic
Authentication over HTTPS.
- Digest Auth is based on the outdated and insure MD5 algorithm, strong hash
algorithms may not be used.
- Digest Auth is valuable to Man-in-the-middle attacks. SSL allows the client to
verify the server's identity.
- Basic Auth is easier to implement on the server side and supported by more
clients.
- HTTPS is the default web protocol. Certificates are easy to obtain. The SSL
part may be handled by a reverse proxy (e.g., NGINX). A reverse proxy setup
is typically deployed anyway to
- use one public IP for multiple services
- implement load balancing, caching, traffic shaping
Best regards,
Stephan Herrnkind
--
Stephan Herrnkind phone: +49 [0]331 288 1696
gempa GmbH fax : +49 [0]331 288 2831
Heinrich-Mann-Allee 18/19 email: herr...@gempa.de
14473 Potsdam web : http://www.gempa.de
Philip Crotwell
In general I find the trend towards data access requiring login to be
troubling both for moral and efficiency reasons. Any barrier, however
small, to data access reduces the usefulness of that data.
It is still not clear to me why the addition of queryauth for station
metadata is needed. Can CTBO provide more explanation of why? The issue
says "There are practical reasons why one may want to not share restricted
metadata, particularly the precise locations of active temporary deploys."
but I don't see the distinction between an unauthenticated user seeing a
precise location for a temporary vs. permanent station. What is the concern?
This may be a good opportunity to change the common specification to allow
implementations to support HTTP, HTTPS or both. There are already cases
where FDSN web services are only available via HTTPS (NCEDC for example)
and the general requirement to restrict web connection to HTTPS-only for
institutional web servers is only likely to increase in the future. Also I
feel that any type of authentication/authorization such as queryauth should
only be done over HTTPS. Doing security correctly is really hard, and
trying to do it over an unencrypted protocol is just asking for trouble.
Lastly, at a more basic level, I wonder if authentication should even be
part of the specification? Not that it isn't important, but it feels quite
orthogonal to the "seismic" part of the protocol. There is nothing to
prevent a client from calling /fdsnws/station/1/query and passing a HTTP
Authorization header and nothing preventing the server from making use of
it to restrict or allow access to some data. The current spec would also
seem to prevent the use of alternatives that may be easier and/or more
secure in certain cases, bearer tokens instead of digest for example. And
of course the current spec does not allow HTTPS, and so to be secure a
server currently must be at least somewhat non-compliant.
All that said, simply moving queryauth to commonalities and having it
optional may be the easiest way to address this, so if authentication
really is needed, I guess I would not oppose that as long as use of HTTPS
was added to the specification as well.
This is a useful resource I think:
https://stackoverflow.blog/2021/10/06/best-practices-for-authentication-and-authorization-for-rest-apis/
Philip Crotwell
South Carolina Seismic Network
> ----------------------
> FDSN Working Group III
> Topic home: http://www.fdsn.org/message-center/topic/fdsn-wg3-products/ |
> Unsubscribe: fdsn-wg3-produ...@lists.fdsn.org
>
> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
> Update subscription preferences at http://www.fdsn.org/account/profile/
>
Fabien Engels
I directly answered on the issue given by Chad
(https://github.com/FDSN/WebServiceSpecificationCommonalities/issues/6)
From my point of view, usage of http or https shouldn't be part of the
specification of the webservices as it's already part of the HTTP/HTTPS
protocol and you may want to use your webservice with or without HTTPS
depending your usage (for example, only http in an internal network not
exposed). The only issue I met using HTTPS with dataselect is client not
supporting it by hardcoding http protocol or client not allowing to
specify credentials to use BasicAuth.
Once you have basic auth header in the query, it can be easy to
implement some form of authorization and waited return code in case of
denied authorization are already defined by the HTTP protocol.
So, I follow Stephan Hernkind's position as most of the time, you will
use a reverse proxy providing HTTPS support and BasicAuth support so
it'll keep the specification simple and won't ask any change on the
current dataselect implementation and very few on the clients side. The
main advantage of basic auth is simple and won't ask much work.
But one caveat, it's you won't be able to manage users session like
invalidate them or being able to create program or script without
knowing the user credentials (one way to bypass this limitation is to
create a specific account for that usage).
It's here where tokens come into play to solve that kind of problems but
they come with complexity, for example, OAuth can be quite difficult to
implement correctly and can be hard to use by regular users (part of it
can be hidden by the clients but will make more difficult to use simple
tools like wget).
I think we have to think how much we need that overhead in our community
usage.
Have a good day
Fabien
BCSF-RENASS / EPOS-France