Zoom Connection:
ID 620 2326 4069
Kenncode 283305
Einladungslink https://desy.zoom.us/j/62023264069
Participants:
- Kilian Schwarz
- Tamas Mako (unconventiona.dev)
- Hubert Simma
- Christoph Wissing
- Christiane Schneide
TOP1:
Introduction
introduction round
Kilian: SC, IT, lead of TA6 WP2
Christoph: TA2 lead
Hubert: theory group at DESY Zeuthen, metadata catalogue, access control service for fine grained storage access
Christiane: project manager PUNCH4NFDI
Tamas: unconventional.dev Indico developer
TOP2:
request was to connect keycloak and Indico
keycloak user groups in Indico
for this we used keycloak API
Test at DESY ? ==> Test environment has been set up
Keycloak user groups are seen from Indico
recent discussion points:
Indico expects that group names are unique
in Key cloak group names are not unique
Tamas demonstrates the problem
Indico group names need to be Unique that is why the full path is taken into account
this is the translation we have to do to get unique group names
in key cloak the group name is not unique
when assigning different permissions to the group name then from the whole name only the tip may appear
group name can be longer than displayed in Indico
this problem can be circumvented by assigning a uniqueness of group names in Indico based on ID instead of name
the other problem is:
Indico relies on group names and not ID
if you go to keycloak and fix the name of the group than the connection in the management system will be lost
this is how Indico works in the Indico Multipass
this can be fixed by updating the keycloak and the indico multipass plugin to listen to Id instead of names
this would be an additional development
Hubert:
in Indico you see the full hierarchy
how is this transmitted from keycloak ?
was this a change in multipass-keycloak-plugin, which provides connection to keycloak and Indico
this is a plugin to Indico
plugin just uses names from keycloak
Christoph:
this is a point
certain groups are auto created at DESY keycloak
if we add more groups to the AAI
first token with the group comes and group is auto created
CERN is bound on e group system which is based on group names
Kilian:
if we change to IDs then we may decouple from CERN
but everything will be based on the CERN repository and CERN will host everything
Tamas:
long term solution would be at CERN also to migrate to IDs
but needs more work
and it should work in a backward compatible way
additional development time is a matter of 30 hours
if CERN wants to do that, too, why do they not do that ?
but there is no real pressure to change this behaviour now
there should be migration path between both solutions
if there is a possibility to develop this new version right away then migration is not needed
Marcus question: meeting next week
TOP3:
Reduced Feature Request Document
https://docs.google.com/document/d/14NII7zyh5ytnicTPmcOtwx-Jr9fAoDTiUTkU4nXDun0/edit#heading=h.sc34ezl7ielq
1.
Hubert is wondering why this is only the case when doing a refresh-token
how oidc-agent is doing it internally
is oidc-agent handling it internally via refresh tokens ? ==> question to Oliver
is oidc-agent internally always keeping a refresh token alive ?
the whole thing keeps working even if we stop the agent
it goes with the credentials
Hubert looks currently into the code of oidc-agent, from these experiments he doubts
version a) has been removed because not wanted by IAM
the trend is anyway to go to former version b) or c)
this would be in line with former request b)
with respect to external policy engine:
is there an external product people are looking at ? They are looking into OPA
Switch to German, now:
IAM Leute haben das schon ausprobiert,
ist die Policy engine, die auch im kommerziellen Bereich verwendet wird, z.B. von Netflix
Von der Policy Engine ist OPA mehr das Backend
==> abgesehen von Frage an Oliver sind wir happy mit dem Reduced Feature Request Dokument
Bei Indigo ueberlegt man auch, ob man einen API ACS Call einbaut
So dass Nutzer Tokens direkt bei IAM holen kann
Das ging in vorherige Loesung b), also jetzt a)
Unterschied ist, ob Access Control zwischen Nutzer und AAI oder hinter AAI statt findet
beide Architekturmodelle waeren ok
ex b), neu a) waere dann vermutlich fast die schoenere Variante
erfordert Definition eines neuen Standards, neue APIs definieren
Aktuell b) Token Exchange waere ein existierender Standard
muss von AAI voll unterstuetzt werden
ist nicht einheitlich der Fall weder bei Unity noch Indigo
==> Text so ok, kann abgeschickt werden, Frage mit Refresh Token noch mit Oliver klaeren
Wenn Sander einverstanden, dann weitergeben
Dann ev. noch Bemerkungen von Unity Core Dev Team
==> abschicken
Danach naechsten Schritt
TOP4:
Round the table
TOP5:
AOB
TA2 Treffen:
mit Marcus und Sander diskutieren, wegen AAI-Konzepte fuer Storage
Naechsten Montag in TA2 erstmal intern klaeren welche Moeglichkeiten fuer Storage Authentifizierung existieren
An Hubs koppeln oder via Claims ?
dann nochmal mit Marcus und anderen reden ?
Was ist Sicht von AAI-Experten, wie wir foederierte Storage-Geschichten machen ?
Plan war eigentlich basierend auf Claims Entwicklungen in dCache und XrD zu machen und dann Testen
Im Lichte der Zwischenevaluierung
kurzfristige Loesungen in Claims ist gewollt
storage.read:/example/subdir/file
was groups angeht gibt es eine dCache spezifischen Zwischenloesung
das mappen von POSIX auf AAI-Gruppen
Claims: ?
wie kriegt man die Tokens mit den eingeschraenkten Claims ?
==> wie sicher stellen, dass auch nur der Nutzer, der darf, so ein Token bekommt. Da haben wir heute noch keine Loesung fuer.
man will das nicht nur freiwillig einschraenken durch Request 1, sondern das muss auch enforced werden ?
Das waere Request des Reduced Dev Request
wieviel Identitaetsinformationen benoetigen unsere Service-Provider ?
aktuell die gleiche Diskussion mit Paul Millar und Rucio
Haengt von Serviceprovidern ab, politische Geschichte
Autorisierung rein auf OAuth2-Ebene machbar und gesichert uebertragbar
ohne Ueberbau von OIDC
Gibt es im grossen Stil fuer wissenschaftliche Daten Storage-Provider, die Daten zur Verfuegung stellen ohne Autoriseriung ? ==> OpenData
Wen gibt es und wie viel ? DESY geht ein wenig in die Richtung
Ev. waeren OpenData erst mal ein Workaround
Lesezugriff minimal kontrolliert
Schreibzugriff benoetigt ev. noch eine andere Autorisierung
Schreiben ist ja koordinierter Prozess, wo sich Leute Gedanken drueber machen
Ganz freien Zugang auf Doors ware nicht moeglich ==> auf Door mit authentifizierten Zugaengen nicht konfigurierbar
mit gleicher URL fuer Subbranch frei war nicht konfigurierbar, dafuer extra public door, sonst Tigran fragen ?
Extra Entry Punkte ohne Authentifizierung ?
Aber das verkompkliziert, weil neue URL notwendig
Das war in Gespraechen mit Christian das Einfachste
==> Unity AAI dazu bringen Tokens storage read:/ auszugeben
dann sollten alle lesen koennen
wenn Du PUNCH hast kannst Du lesen und schreiben
grobe Zugangskontrolle fuer Lesezugriff
Kleine uebersichtliche Zahl von Gruppen
Fernziel definieren:
und welche Moeglichkeiten hat man fuer Zwischenloesungen ?
==> also Abkuerzungen bzw. Zwischenloesungen ?
==> als Zwischenschritt in Dokument Customs Scope definieren in AAI ?
Das ist in c) eigentlch schon drin
was sind zeitnahe Use-Cases ?
siehe auch User Stories von Oliver in Requirements Dokument
siehe spezifische Use-Cases aus Intra TA Meeting
was brauchen wir zum Demonstrieren
Da auch Experiment von Joern anschauen: 60k Metadaten von Cloe und Daten im Filekatalog und in HH abgelegt
das koennte ev. schon ein halboffener Use-Case sein
Wuerde mit XRD vermutlich genauso gehen
aktuelle xrd nur, wenn WLCG Token
Bonner schreiben Unity-Struktur Parser, so dass gruppenbasiertes Parsing moeglich
Mapping zwischen Identifizieren und Storage Location
mit Replikum in Bonn und Eintragen in Katalog
AAI Dokument erst nach Montag abschicken
Montag TA2 WP1 Meeting, da ueber AAI Themen diskutiert.
Ev. kommen noch Aenderungen in Requirements Dokument rein.
Unterscheiden zwischen Group und Capability Claims
Starten bei User-Identitaeten und wollen bei Files ankommen
Many Many Relationen
3 Schritte
USer ==> Gruppen
Gruppen ==> Capabilities
Capabilities ==> Resourcen
==> welche der Zwischenergebnisse in Tokens (Claims)
und wo man die Transformationsschritte macht
zentral oder SP ?
darueber nochmal reden, auch weil viele unterschiedlichen Stand
Indico:
4000 CHF ausgesprochen guenstig fuer erste und 2. Entwicklungsphase und 30 h
und sehr professionel
ID ist eigentlich die Richtung, in die wir gehen sollten