Skip to content
This repository has been archived by the owner on Apr 9, 2021. It is now read-only.

fed: AAI #46

Open
damb opened this issue Sep 24, 2018 · 7 comments
Open

fed: AAI #46

damb opened this issue Sep 24, 2018 · 7 comments

Comments

@damb
Copy link
Contributor

damb commented Sep 24, 2018

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 damb added the question label Sep 24, 2018
@damb damb added this to the AAI (dataselect) milestone Sep 24, 2018
@damb damb added the federator label Sep 28, 2018
@damb
Copy link
Contributor Author

damb commented Nov 20, 2018

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
Copy link
Contributor

kaestli commented Nov 20, 2018

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
Copy link

andres-h commented Nov 20, 2018 via email

@damb
Copy link
Contributor Author

damb commented Nov 21, 2018

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
Copy link
Contributor Author

damb commented Dec 18, 2018

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:

@damb damb pinned this issue Dec 18, 2018
@andres-h
Copy link

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
Copy link
Contributor Author

damb commented Dec 19, 2018

@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.

👍

@damb damb added rfc and removed question labels Jan 18, 2019
@Jollyfant Jollyfant unpinned this issue Jan 23, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants