fed: AAI

[damb]

This is a proposal of @damb and @kaestli from the ETC meeting at Grenoble (09/2018). Comments are welcome.

• Two new methods
• fdsnws/dataselect/auth (HTTPS):
  • Token based authentication (e.g. OAuth2)
  • Store the token locally and return username:password to the client
  • eida-federator token context specific credentials
• fdsnws/dataselect/queryauth (HTTPS):
  • HTTP Digest authentication
  • Fetch routes from stationlite (restriction=closed):
    • Check if credentials are eida-federator token specific
    • credentials matching eida-federator token:
      • Use token for the endpoints fdsnws/dataselect/auth method -> temporary credentials for fdsnws/dataselect/queryauth are created (at endpoints)
      • eida-federator stores credentials (endpoint specific)
      • request data from endpoint’s fdsnws/dataselect/queryauth method with corresponding credentials
    • credentials not matching:
      • request data from endpoint's fdsnws/dataselect/queryauth method with credentials passed
      • return either HTTP status code 200 or 204 (depending if there is data available); returning HTTP status code 403 would only be possible if a) no matching token is available and b) only restricted data was requested; status codes are specified by the FDSNWS specs
  • Fetch routes from stationlite (restriction=open):
    • request data from endpoint’s fdsnws/dataselect/query method
  • Best effort approach: Return accessible data (if available)

[damb]

Some additional points we should think about:

• Should we allow passing one and the same token multiple
  times to eida-federator/auth? IMO, yes.
• In case a client passes multiple times his/her token to
  eida-federator/auth: How to proceed regarding the credentials to be
  returned (we exclusively store e.g. an hash at our auth-DB such that the
  credentials issued previously cannot be restored anymore):
  • We might reset the credentials issued previously in order to keep
    exclusively the latest credentials issued
  • We might store multiple credentials mapping to one and the same token

When I'm talking about credentials I mean credentials within a eida-federator context.

[kaestli]

Consider that somebody could implement a script which does auth authentication at each start, and then use the temporary queryauth authentication while running.
(this is probably not a bad idea, as like that, the user does not have to care about configuring valid queryauth temporary credentials)
Then he / she will run multiple instances of this script in parallel. The second instance should not prematurely invalidate the temporary federator queryauth credentials still in use with the first instance.

Thus: yes, I think you should be able to have multiple valid federator queryauth credential sets for the same token.

[andres-h]

In case of SC3 FDSNWS implementation, "username" is a hash of the token, so the same token always returns the same username. If there is valid password (not expired), the same password is returned. It is less secure, but avoids having multiple credential sets for the same token. Otherwise the number of credential sets per token can get huge if un-optimized scripts are used.

[damb]

The SC3 FDSNWS implement an in-memory user DB. I'd prefer a solution using a real DB in order to have the possibility to share one and the same user DB between multiple (e.g. containerized) eida-federator instances more easily. However, this would require storing hashes (due to security reasons).

The multi-credentials approach would imply to limit the number of credentials issued reasonably / or rather make it configurable.

[damb]

I'd like to implement token based authentication for eida-federator. In order to do it properly I need the following information:

• What token standard is currently in use? The token attached seems to be a ASCII file containing a GPG clearsigned JSON object. However, it does not agree with the JWT standard (RFC7519). If so, is the format provided somehow standardized? (SC3 FDSNWS AAI claims to be based on eduGAIN. Again, eduGAIN is based on a SAML2 token infrastructure.)

• Related to the previous question. What authentication infrastructure is currently in use or rather which standard is implemented? B2ACCESS provides AAI both SAML2 and OAuth2 (RFC6749). Is there any standard implemented by the SC3 FDSNWS? To me, it seems to be based on GPG signatures (AFAIK from reading the code).
  In addition there is https://snf-738070.vm.okeanos.grnet.gr/ and http://rz-vm258.gfz-potsdam.de/eas.html. (The latter one redirects to the first one.)

• Using B2ACCESS both SAML2 and OAuth2 are implemented to be used for SSO. However, the current SC3 FDSNWS implementation AFAIK currently does not implement real SSO. Though, for a federated FDSNWS environment this would be a big plus. Is it planned within the near future to extend SC3 FDSNWS with SSO facilities?

• The proposal above was based on the current SC3 FDSNWS implementation. Tokens are transmitted by means of HTTP POST. Authorization is implemented using a two-stage approach.
  Since OAuth2 is based on Bearer Access Tokens (RFC6750) from a client's perspective accessing restricted data would be simplified. Only a single request would be necessary. Would a OAuth2 SSO based authentication be an option within EIDA?
  (I'm aware that fully implementing an OAuth2 SSO approach would have a big impact on the current FDSNWS implementations for restricted data access.)

Attachments:

• eidatoken.txt

[andres-h]

What token standard is currently in use? The token attached seems to be a ASCII file containing a GPG clearsigned JSON object. However, it does not agree with the JWT standard (RFC7519). If so, is the format provided somehow standardized?

The format is non-standard or "EIDA standard".

The token is PGP ASCII-armored, digitally signed JSON object. Only required attribute is "valid_until", the remaining attibutes (typically "mail", "memberof") are used by web services to grant access to data.

Federator does not need to parse the token, just store it and pass to web services as needed.

Maybe a standard like JWT can be implemented if needed.

B2ACCESS (eduGAIN, SAML) is not used directly by web services, only to obtain a token. Maybe B2ACCESS could be directly integrated into a portal like WebDC. Most SSO mechanisms are interactive and not suitable for scripts. Web services must support scripting.

I am aware of webisoget, but it is a hack that requires storing SSO credentials in plain text file. The whole idea of SSO is using single credentials for everything, so saving those credentials in a file is very dangerous.

The problem with eduGAIN is that it requires a formal and strict procedure to join. Many institutions are not able to join at all.

Another requirement was compatibility with FDSNWS (HTTP digest). If the FDSNWS standard is changed, there are better options.

[damb]

@andres-h, thanks for your clarifications.

Federator does not need to parse the token, just store it and pass to web services as needed.

On a public available service I would check the token format. Simply storing and accepting any content IMO isn't a good idea.

Maybe a standard like JWT can be implemented if needed.

👍