Authentication concept

We distinguish between authentication (verifying that the user is who he claims to be) and authorization (verifying that the user is permitted to access certain data). In the original FDSNWS implementation, the user is authenticated with password.

This creates difficulties sharing credentials (user name and password) between EIDA nodes.

Our concept is that instead of entering a password, a user could merely provide an ID token (username, e-mail address, etc.), digitally signed by a trusted party. This way the authentication is delegated to a third party. This is similar to showing an ID card in real life.

An FDSNWS extension based on the above idea has been developed. It works as follows:

  • The user contacts an authentication service (based on eduGAIN AAI, e-mail, etc.) and receives a list of attributes (an ID token), signed by the authentication service. The validity of the token is up to 30 days.

  • The token is kept secret on the user’s side.

  • The user presents the token to the /auth method (using HTTPS) of the dataselect service. This new method is the only extension to standard FDSNWS.

  • If the digital signature is valid, a temporary account for /queryauth is created. The /auth method returns username and password of this account, separated by ‘:’. The account is typically valid for 24 hours.

  • The username and password are to be used with /queryauth as usual. These credentials are protected by digest access authentication.

Authorization in SeisComP is currently based on the user’s e-mail address or the groups to which the user belongs to (both of them in the token) and configuration settings in arclink-access bindings.

The /queryauth credentials are a 24-character user name and 16-character password (1024 bits).

Note

Neither the details of user requests (streams, time windows) nor the waveform data sent in response are encrypted when using digest authentication. This differs from the model used for restricted access in Arclink, which encrypts data on the server using the user’s secret key before delivery.

For EIDA node operators

See the EIDA Redmine wiki for how to correctly configure your server.

For developers of client software

Don’t save credentials on disk, but use the /auth method whenever needed. That is, first attempt to request data with /queryauth ; only when that fails, with a ‘’401 Unauthorized’’ response, use the /auth method to obtain new credentials. The credentials are typically valid for 24 hours, but the lifetime is not guaranteed.