Open damb opened 5 years ago
Some additional points we should think about:
eida-federator/auth
? IMO, yes.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):
When I'm talking about credentials I mean credentials within a eida-federator
context.
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.
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.
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.
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:
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.
@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.
:+1:
This is a proposal of @damb and @kaestli from the ETC meeting at Grenoble (09/2018). Comments are welcome.
fdsnws/dataselect/auth
(HTTPS):username:password
to the clienteida-federator
token context specific credentialsfdsnws/dataselect/queryauth
(HTTPS):stationlite
(restriction=closed
):eida-federator
token specificeida-federator
token:fdsnws/dataselect/auth
method -> temporary credentials forfdsnws/dataselect/queryauth
are created (at endpoints)eida-federator
stores credentials (endpoint specific)fdsnws/dataselect/queryauth
method with corresponding credentialsrequest data from endpoint'sfdsnws/dataselect/queryauth
method with credentials passedstationlite
(restriction=open
):fdsnws/dataselect/query
method