You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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;
The text was updated successfully, but these errors were encountered:
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).
In KNAW HuC Structured Data we're busy to document/develop 3 scenarios:
regular service behind Satosa browser login
delegated service receiving a Sotasa token
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.
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;
The text was updated successfully, but these errors were encountered: