Choose timezone
Your profile timezone:
Powered by Indico
v3.3.2
second extended PUNCH AAI meeting after initial discussion on December 15, 2021.
Teilnehmer
- Thomas Schoerner
- Sander Apweiler
- Kilian Schwarz
- Hubert Simma
- Manuel Giffels
- Thomas Kuhr
- Christian Voss
- Marcus Hardt
- Oliver Freyermuth
- Christoph Wissing
- Anastasia Galkin
- Harry Enke
- Peter Wienemann
Indico & AAI
Siehe Folien CW
kein Support fuer AAI Gruppen
CERN Indico Team Kontakt ==> Manuel
Auch Anton Barty / DAPHNE sollte kontaktiert werden
Aktuell einloggen moeglich, aber keine Unterorganisation
kein Plan dran zu arbeiten von DESY Seite
AAI & Tokens:
Oliver Freyermuth
Unterschiede zwischen WLCG Access Tokens (Indigo IAM) und
von Helmholtz AAI verwendeten Tokens
Die grade gezeigte commandline ist insgesamt in "flaat-userinfo" (pip install flaat) ingetriert.
Authorisation Claims gibt es in den einen Tokens, aber nicht in den anderen, damit nicht zentral nachgefragt werden muss
standardisiert in RFC9068, daher WLCG ==> Standard
Mit Unity aktuell nicht moeglich
Sander:
Unity: folgt dem aktuellen Standard, aber Kontakt zu entwicklern besteht. Es wird geprueft, ob das anpassbar ist.
OIDC und Dienst Info via Claims
Konflikt: je mehr Info in tokens desto groesser der Token
Scitokenlibrary wird von mehreren verwendet, erweiterung von oid connect, z.B. HTcondor
alte software kann mit token umgehen
frei benutzbar mit definierter api
Muessen wir offline die Rechte bestimmen koennen oder skaliert es wenn jeder Provider zentral anfragt ?
Gruppen sind jetzt schon moeglich
Auch Rechtedelegierung waere jetzt schon moeglich
mit Tokens kann man auch woanders als bei Unity abfragen, z.B. koennte ein Rechte-Servive von PUNCH extern und mit anderen Methoden gebaut werden.
AAI und Compute 4 PUNCH (Manuel)
2 Faktor Autorisierung am KIT gewuenscht
z.B. PAM-OATH benutzen
Kommunikation mit Marcus erfolgt
wie das am geschicktesten in die Wege geleitet werden kann.
Sander:
2- Faktor ist in H-AAI nicht aktiviert
Einrichtungsworkflow muss ueberarbeitet werden.
Das Thema ist auf der Roadmap
ueber eine bezahlten Feature-Request ginge es schneller
Entwickler haben nur begrenzte Ressourcen
Open Source Projekt-Beteiligung an Entwicklung ist grundsaetzlich moeglich
Ist das harte Bedingug fuer KIT, um Ressourcen zur Verfuegung stellen zu koennen ?
kann erst mal so in Betrieb genommen werden
Es handelt sich um ein Entwicklungsprojekt
Bisher kann jeder PUNCH User auf Ressourcen zugreifen
Gruppe (Compute), die Zugriffsrestrikiterung erlaubt
kann nun erstellt werden.
Das waere ein konkreter Use Case fuer Gruppen !!!
aktuell Access token via PW von ssh, token darf nicht laenger sein als KB
viele Gruppen ==> Token zu lang
Es wird draan gearbeitet.
Ging eher in Richtung von dem, was waerend der Session von OF diskutiert wurde.
wie funktioniert 2-Faktor ?
Storage for PUNCH:
dCache kann OIDC und SciTokens via Plugin validieren
weiss welcher User und welche Gruppe
entitlements von PUNCH koennen verwendet werden
Dokumentation existiert
KeyCloak Service dazwischen wird quasi vorausgesetzt
Frage: PUNCH-weiter KeyCloak Service sinnvoll ?
HIFIS getrieben, sollten nicht an HEP vorbei operieren, grundsaetzlich aber ok
DESY kann AAI info in user management system einarbeiten
speziell fuer Resource provider
Group mapping fuer punch ok
role mapping noch nicht ?
Gruende fuer Keycloak ?Gibt es noch andere Software ?
Subject wird gemapped ==> gefaehrlich ist das, was auf Folie steht
in dCache muessen Endpunkte noch manuell konfiguriert werden
in OIDC nimmt man Sub and @ wie bei E-Mail dann vollstaendiger Name
Wird nochmal geprueft
Gruppe fuer dCache anlegen oder lieber lassen ?
Gruppen sollten inhaltlich, projektbasiert angelegt werden, nicht dCache-spezifisch
Die Themen "Services" und "international context" werden beim naechsten Meeting besprochen