search

CLARIAH / clariah-plus

This is the project planning repository for the CLARIAH-PLUS project. It groups all technical documents and discussions pertaining to CLARIAH-PLUS in a central place and should facilitate findability, transparency and project planning, for the project as a whole.
9 stars 6 forks source link

Authentication & Authorization: Ability to request API key #134

Open proycon opened 1 year ago

proycon commented 1 year ago

In order for automated clients to connect to the CLARIAH authentication backend (satosa), we need a well-established and documented mechanism for developers to request an API/authorization key. For instance via a simple web front-end.

This also relates to the issue of user delegation #65 , though I can imagine authorization keys themselves may be independent of any actual users and tied to particular clients;

proycon commented 1 year ago

As @hayco commented in a KNAW HuC Team Text meeting recently, the way I wrote this may be a bit too narrowly defined as it gives the impression it's just about a front-end, which is not the case: the whole authentication backend must be able to accommodate access from automated tools (some may not act on behalf of any particular user).

menzowindhouwer commented 1 year ago

In KNAW HuC Structured Data we're busy to document/develop 3 scenarios:

  1. regular service behind Satosa browser login
  2. delegated service receiving a Sotasa token
  3. service receiving an API ky

In all these cases Authentication must be valid and Authorization decisions can be based on the same info, i.e. regardless of the scenario authentication has happened. Authorization info is a fallback chain of (salted & hashed) EPPN or EPTID.