Choose timezone
Your profile timezone:
Powered by Indico
v3.3.5
participants:
- Kilian Schwarz
- Sander Apweiler
- Alexander Dubowik
- Daniel Mallmann
- Anastasia Galkin
- Olaf Michaelis
- Christopher Huhn
Agenda
TOP1: AAI Requirements Document
Part 1: High Level Requirements
Items under second bullet
"we want to define access rights on different levels for PUNCH services"
are service provider issues.
Should they be removed from the document ?
For the time being they will just marked as such.
To query information about users is against the DSGVO. This is only allowed
in case the user agrees or when the user has registered already before.
Actually the API
"the system should provide a web interface or APIs to get
information about individual members or groups"
is intended as API for AAI administrators and not for service providers.
This should be clarified in the document.
Here basically information about membership in AAI groups is intended.
Other user related information are to be found in the IdPs.
Another topic which has been discussed is how an administrator will be
able to know when users do not exist anymore ?
One possibility is to create a refresh token. In case the token is not
created the user does not exist.
This should be added as requirement to the document:
"it is required to get information when users left the project."
But this is something where the AAI experts already work on.
Token for read access have been discussed.
Such rights can be interconnected with access or OIDC tokens.
But even when such rights will be added by the AAI it
still depends on the resource capabilities.
Do we need such tokens only for one time access or is it
required to have a time dependency ?
On point is that such tokens are always interconnected to individual persons.
A time limitation is not always included, but maybe this should be the
case under certain circumstances.
Such tokens have to be distinguished from tokens used for sharing files.
This may be then an application specific item.
What happens when the membership of a user in a VO (virtual organistaion)
comes to an end ?
Would an access token become invalid in such a case ?
Service providers should be able to block access rights immediately.
To provide access rights and shares to users bypassing AAI roles would
be in the responsibility of individual persons and should be out of scope.
Project and group specific rights should not be interconnected with
individual accounts.
Part 2: Technical AAI requirements
Entitlements of PUNCH and Helmholtz AAI are not different in their structure.
The difference is only in the values.
This should be changed in the document.
Related to "the following features should be implemented in Unity IAM":
- 2 factor authorisation already exists in the Unity implementation but
has not yet been activated.
This will come and can be optionally activated by the users.
A question came up:
is it sufficient if the 2 factor authorisation is done by the resource
provider, e.g. a storage provider or should that be done always via AAI ?
Concerning the remaining missing features in Unity: it just is like that.
There are requirements to having small tokens by certain software
(e.g. by ssh-oidc to have tokens < 1 kB)
If more information is added to the tokens they will become larger.
But currently discussions are going on if both can be possible.
It is also not clear how path based authorisation and authorisation claims can
be implemented.
With respect to authorisation claims:
tokens could be enriched with claims and then this can be built in.
With respect to token delegation:
values of the entitlements can be reduced already now.
Handover to services is possible with subsequent validation against the AAI.
Concerning group length:
the service has to solve how the mapping can be accomplished.
The group length is also related to EOSC compatibility issues.
When the group names are shortened too much they would become too generic
and users may be mapped to the same groups at service provider level.
general remarks:
The document is formulated in an understandable way.
The various items can be understood, especially the Unity specific remarks.
High - Level remarks: they are valid for all NFDI consortia and are
basically all addressed already.
Technical remarks: they are more PUNCH specific and might not be that
interesting for the general NFDI community.
It has been discussed to whom PUNCH4NFDI should submit the document.
Should it go to the IAM related NFDI groups ?
No, it should be first given to the PUNCH representatives in these groups.
To Base4NFDI the document might be valueable input.
S. Apweiler will try to include the document in the next TF meeting.
The meeting will be December 8, 2022.
It is currently in discussion how tokens can be utilised across AAI
boundaries, which means that Indico IAM tokens could be usable in
Unity IAM and vice versa.
TOP2: AOB
Indico IAM:
the contact person to the NFDI IAM group should also operate the service.
A technical partner for discussion and expertise as well as a partner for
operating an Indigo based service within the NFDI realm is required.
AAI in Base4NFDI:
currently documentation is being provided.
Due to reduced funding not everything might be realised.
One example will be extra training which will be cancelled.
New application in order to get funding is being prepared.
The document has been updated accordingly:
https://gitlab-p4n.aip.de/punch/intra-docs-content/-/blob/master/docs/TA6/WP2/aai-requirements.md