General authentication method for all services, enhancement for tokens

[filefolder]

Are there any future plans for implementing some type of use-authentication method (as in dataselect) for station data as well? There are practical reasons why one may want to not share restricted metadata, particularly the precise locations of active temporary deploys.

[chad-earthscope]

There are no current proposals to include authentication similar to fdsnws-dataselect in other FDSN services. If you wish to submit such a proposal please contact me.

In practice, it should be relatively straightforward and unobtrusive for any datacenter that wishes to add the authentication to their FDSN services in the style of fdsnws-dataselect.

[filefolder]

OK thanks,

We run FDSN via seiscomp so probably saner to implement there than here, but in a broader sense it would be nice to have more (easy) control over access in a future version (e.g. separate xml restricted tags for station and dataselect?). I take it that many don't mind if the station metadata is open so long as waveform data is not, but it often introduces quite a few headaches for us.

[chad-earthscope]

I'm moving this to the service commonalities for consideration to apply the fdsnws-dataselect authentication to all services as a general pattern, perhaps with enhancements. Offering these authentication mechanisms would be optional and up to the implementing organization.

[chad-earthscope]

Two suggestions for consideration:

1) Adopt the authentication method of fdsnws-dataselect for all services. As an optional feature, in principle this may be as easy as moving the description of this mechanism (queryauth) to the Commonalities specification.

2) Document a method for authentication using a token, as an alternative to the user/password method.

Regarding 2, ideally a method for token use can be specified that is flexible for multiple token usage with details determine by implementers.

[filefolder]

Thanks for bringing this back up,

FWIW I would lean towards just implementing option 1 across all services, at least for now. It already works very well and it's nice to just say "the password is banana" to someone in the hallway.

[fabienengels]

1. The main advantage, the basic auth doesn't even need to be part of FDSN specification as it's already part of the HTTP protocol and you can easily delegate this part to a reverse proxy for example and will be easier for users and won't ask much code on clients like Obspy
2. Tokens are nice in the way that you can invalidate user sessions but add quite complexity depending of the chosen implementation (looking at you, OAuth ;p) and allow users create programs querying the webservice without the need to know the user password adding stronger security. As suggestion, I know JWT is quite popular and have libraries in almost every existing language.

[jschaeff]

If authentication is realy needed, then OK to move the specification to the commonalities. I would prefer the requests to stay anonymous. As it has already been stated, the authentication step adds complication for data and metadata access. It should be reserved to special use cases.

I agree that basic auth is a HTTP level protocol, but the authentication method has to be clearly stated in the FDSN specification because otherwise, interoperability will break, or at best be more difficult (I guess the wadl description could tell what authentication mechanism is needed but then clients would need to switch mechanisms from one service provider to the other, I would rather avoid to slide into this branch of the multiverse).

Also note that with authentication based on JWT passed in the header, we don't need the queryauth endpoint anymore. I would suggest to just drop it.

I guess all my points are consistent with the suggestion 2 from @chad-earthscope.