Closed MartaJuzepczuk closed 2 years ago
pleys
commented
5 years ago Is it only for the Dashboard that we concluded that change was needed? Is the following scenario possible with the current structure of the manifest file for a given institution: Institution API & Organization Units API are developed inhouse, Incoming Mobilities API and Interinstitutional Agreements API are covered by SOP, Outgoing Mobilities APi is covered by Dashboard.
janinamincer-daszkiewicz
commented
5 years ago Yes, the following scenario is possible with the current structure of the manifest file. The solution - on the technical level - would be the following: a) SOP keeps the manifest file for this HEI. b) HEI keeps also its own manifest file with the client certificate for the Dashboard and its own client certificate. Still, this would work under the condition that all parties trust each other, that neither SOP nor Dashboard will act as a client on behalf of the HEI for the APIs they are not supposed to touch (SOP might also act as a server). We assume that SOP, who now keeps manifest files for its clients, prefers to do it that way, it might however behave as Dashboard in that respect.
pleys
commented
5 years ago Ok, so trust is not only an issue for the Dashboard. We should trust every node in the network that could potentially act for different institutions.
janinamincer-daszkiewicz
commented
5 years ago Yes.
vmeus
commented
5 years ago I still think this is an issue that we should leave with the providers, with an obligatory notification to the HEI if a change is made by the provider. If an HEI has a version of the manifest file that it can view, then it can also see discrepancies and deal with them. And in case of a double entry we can generate an error code. Or is this to simplistic?
janinamincer-daszkiewicz
commented
5 years ago And in case of a double entry we can generate an error code. What do you mean by that?
vmeus
commented
5 years ago When checking what APIs are being supported as implemented cannot we identify double entries, and if so generate an error message? We agreed that each API should be active in only one node, right?
janinamincer-daszkiewicz
commented
5 years ago In manifest files we list the APIs available from the server. We do not have the same option for the client. We can not say, that this node can act as a client for IIA but the other as a client for Outgoing Mobility. For that we would have to make changes in the structure of the file.
georgschermann
commented
5 years ago I think what @vmeus means is that the registry might check if two different HOSTS provide the same API for the same HEI and in that case notify the admin-emails of these HOSTs that their manifests are ambiguous. In this case the Entry which existed first should be the only one used in the catalogue.
This doesn't fix the issue that both HOSTs could act as a client for all APIs though. This may be checked by service implementers - that a requesting HOST covers the specific API for the requesting HEI which is already advised for IIAs API and mobilities API.
janinamincer-daszkiewicz
commented
5 years ago I think what @vmeus means is that the registry might check if two different HOSTS provide the same API for the same HEI and in that case notify the admin-emails of these HOSTs that their manifests are ambiguous.
This is true but only for the server.
In this case the Entry which existed first should be the only one used in the catalogue.
How can we say which one it is?
This doesn't fix the issue that both HOSTs could act as a client for all APIs though.
This is true.
This may be checked by service implementers - that a requesting HOST covers the specific API for the requesting HEI which is already advised for IIAs API and mobilities API.
This is not clear.If you put the client certificate in the manifest file that can only mean that you are allowed to behave as a client in all possible situations. We do not have yet the possibility to restrict the scope of the client certifiate. We can either rely on trust or change the structure of the manifest file to impose restrictions.
georgschermann
commented
5 years ago In this case the Entry which existed first should be the only one used in the catalogue.
How can we say which one it is?
When the registry fetches a manifest it could check for violations to the catalogue.
This may be checked by service implementers - that a requesting HOST covers the specific API for the requesting HEI which is already advised for IIAs API and mobilities API.
This is not clear.If you put the client certificate in the manifest file that can only mean that you are allowed to behave as a client in all possible situations. We do not have yet the possibility to restrict the scope of the client certifiate. We can either rely on trust or change the structure of the manifest file to impose restrictions.
The requester is trusted and it can make requests for all APIs but it is up to the serving host, if and which data it serves. As stated here. But yes, this is only possible to a certain extent.
janinamincer-daszkiewicz
commented
5 years ago When the registry fetches a manifest it could check for violations to the catalogue.
Still, it is more difficult to point the first one.
The requester is trusted and it can make requests for all APIs but it is up to the serving host, if and which data it serves. As stated here. But yes, this is only possible to a certain extent.
IIA is specific in a sense that HEI A may ask HEI C about agreements of HEI C, which is not a partner of HEI A. And - depending on the policy of C - may get the answer. The question we ask in this issue is different: if HEI A and HEI B are in possession of the certificate of HEI Z, can we trust that they will behave according to some agreement with HEI Z, for example that A will only ask for nominations and B will only ask for transcripts. This is based purely on trust.
vmeus
commented
5 years ago At least I got the discussion going, even if I am lost on all the implications :-)
janinamincer-daszkiewicz
commented
4 years ago What is your opinion on the following issue?
We want to disallow double entries. What is 'double entry'? For example are two different versions of the same API disallowed?
Let's assume that the developer wants to switch from version 2.0.0 of the API to version 3.0.0 of this API. If we disallow him to post both versions of this API, he will not be able to communicate with some of his partners (we may say that the network will be divided into two parts, from his point of view).
We opt for the following solution: we disallow using the same API in different installations, but we allow different versions of the same API in one installation.
georgschermann
commented
4 years ago Would be fine for us.
vmeus
commented
4 years ago I suppose this would be ok. But I also suppose that the same HEI should normally not use 2 different versions of the same IPA from the same provider at the same time. In that sense it would not be a double entry. What counts is that an HEI does not use the same API exposed by 2 different providers. That should not be allowed.
umesh-qs
commented
4 years ago Agree with the this restriction. HEI should not have same API service exposed by different providers
But in old comments I see Georg has mentioned.
"This may be checked by service implementers - that a requesting HOST covers the specific API for the requesting HEI which is already advised for IIAs API and mobilities API."
I don't think any partner should have this restriction. It might work for IIA but not for mobility. For mobility same HEI can have a different host A (urla.omobility.api) for publishing outgoing mobilities and different host B (urlb.imobility.api) for publishing incoming mobilities. In this case even if host A is not hosting incoming mobilities API, host A should be allowed to call partners incoming mobility API (urlb.imobility.api) to update their outgoing mobility status.
janinamincer-daszkiewicz
commented
4 years ago Georg's proposal has never been considered, so let's do not base our current discussion on that. Umesh, we agree that your example is reasonable and should be taken into account.
janinamincer-daszkiewicz
commented
4 years ago There is a new page with the overview of information gathered from the manifest files:
It shows, among others, two types of duplicates:
The registry will send emails to administrators of the installations creating duplicates. More detailed information later.
We want to propose the following solution which allows to keep the current structure of the manifest file.
The Dashboard does not host any manifest file. Every HEI that wants to use the Dashboard hosts the manifest itself. The Dashboard will expose an interface with which the HEI will be able to generate a manifest file (this would be a helpful feature and seems easy to implement).
The manifest generated by the Dashboard for a given HEI will contain, among others:
If the HEI does not implement any APIs by itself and does not intend to call them outside the Dashboard, it may host the manifest generated by the Dashboard without modification. If the HEI implements other APIs by itself or intends to call them from outside the Dashboard, it has several options to choose from. It seems most convenient to add a second element to the generated manifest file, containing the appropriate APIs and certificates.
Placing a certificate or a public key of the Dashboard as a client-credentials-in-use certificate technically allows the Dashboard to call each API, presenting itself as a client of the given HEI. It is a possible security risk. If it is considered unacceptable, we may change the structure of the manifest which would allow to declare that a given certificate entitles client to call only some APIs on behalf of the given HEI. For now, we assume that this change is not necessary, because the implementation of the Dashboard will not allow any unauthorized persons to read data from other APIs. This is however the issue which should be discussed.
If the HEI wants to replace the Dashboard implementation with its own implementation, it can remove the appropriate fragment from its manifest (the fragment corresponding to the removed API, if it intends to delete only some APIs implemented by the Dashboard and still use some of them, or all Dashboard certificates and API implementations, if it wants to stop using the Dashboard completely).
If the Dashboard changes the URL or version of any API, it must notify all HEIs that use the Dashboard. HEIs must make a proper change in their manifests, preferably re-generating a manifest from the Dashboard interface and replacing their manifest files (if they do not have any own API implementations) or a proper part of it. It is recommended that the Dashboard supports the previous versions for some time, giving all the HEIs time to change.