Division of HEI’s APIs among nodes

[janinamincer-daszkiewicz]

Generally concern and discussion is about trust and responsibilities.

In all cases listed below HEI X invokes API of HEI Y from node A with client key 1 but does not implement it at node A - may be it does not implement it at all or implements at it at node B with client key 2. A and B may be run by the same provider (e.g. in-house) or two different providers who signed an agreement with HEI X.

Who should decide about the scope of the client key (is the request legitimate)?

1. HEI X sending the request?
2. HEI Y getting the request?
3. The specification which should regulate the responsibilities?

Many examples of rejected API requests can be found in the Stats portal, search for server_message=You+do+not+have+permission+to+access+this+data.

1. Factsheet.
2. Organizational units.
3. Institutions.

Comments to 1-3: none of these APIs carry private data.

4. IIAs.

Comment to 4: IIAs could be public, they do not carry strictly private data.

5. Omobility LAs.
6. Omobility LA CNR.

Comments to 5-6: There are legitimate use cases in the network where Omobility LAs and Omobility LA CNR are supported by two different nodes, by one provider or by two different providers. See also https://github.com/erasmus-without-paper/ewp-specs-api-omobility-la-cnr/issues/6.

7. Omobility.
8. Imobility.
9. Omobility CNR.
10. Imobility CNR.

Comments to 7-10: Sending HEI should implement Omobility and Imobility CNR, receiving HEI should implement Omobility CNR and Imobility. Should the sending part of the process be located at the same node as the receiving part of the process? See also: https://github.com/erasmus-without-paper/ewp-specs-api-omobility-cnr/issues/4.

Please, share your comments.

[umesh-qs]

"Many examples of rejected APIscan be found in the Stats portal". How can a provider reject such calls? The caller is using a legitimate certificate defined in the manifest to make such calls and hence must be respected. If any provider is rejecting such calls then it is against the current specification.

[georgschermann]

We mainly see this with the Dashboard, where one node e.g. receives the CNR but the GET request afterwards is rejected. We currently resolved these scenarios with a proxy node, combining manifests of all nodes and redirecting/duplicating requests accordingly.

[demilatof]

Who should decide about the scope of the client key (is the request legitimate)?

1. HEI X sending the request?

2. HEI Y getting the request?

3. The specification which should regulate the responsibilities?

The specification already copes this, the access is per HEI, not per provider:

Question 4: I have received a request signed with HTTP Signature with keyId equal to X. I have already validated the signature (as described in question 3), so I know that the sender is in possession of the private part of the key-pair. How do I retrieve the list of HEIs who's data is this client privileged to access?

You can use an XPath expression similar to this one:

//r:client-credentials-in-use/r:rsa-public-key[@sha-256="X"]/../../r:institutions-covered/r:hei-id

Note, that the IDs returned by this query are not necessarily unique.

https://github.com/erasmus-without-paper/ewp-specs-api-registry

What has changed from then, is that now the query should return only one ID (or the same, anyway)
There are no differences due to the API set implemented by a provider or another.

It should be the HEI that wants to use more than one provider, the one in charge to set agreements with its providers to limit what they can or they cannot do.

Otherwise, it could be really cumbersome for the other HEI providers to distinguish between API universally accessible and API with limited access.

E.g.: we can consider auth.gr that has three hosts and therefore three manifest, with three different keys:

1. https://ewp.auth.gr/rest/manifest for general purpose APIs, including Institutions, Ounits, Factsheet and Courses
2. https://unizoneewp.it.auth.gr/rest/manifest/auth.gr for mobilities
3. https://mobisis-ewp.it.auth.gr/rest/manifest/auth.gr for agreements

If I cannot provide my oUnits to the host 3, because it doesn't implement oUnits API (implemented by host 1), how can I provide my organizational units to them?

To introduce any limits only for a set of APIs, we have to modify the registry structure; adding only a comment to say this API yes, but that API not, it would be really dangerous.

[lsanchezpe]

As @demilatof said:

The specification already copes this, the access is per HEI, not per provider

In my case my system will accept the request because the registry sais that this HEI is covered by this certificate, even if this node doesn't implements this API and other node do it fot this HEI

[georgschermann]

Before switching to the proxy node with one manifest we experimented with multiple nodes using the same key pair, which didn't work because hosts are not summarized in the catalogue and some providers only recognized one of the hosts using the key, ignoring all APIs hosted by the other host.