Account Typen

Vorschläge:

keine Verwendung des Begriffs Lightweight Account mehr, führt nur zur Verwirrung,
besser sinngemäß von minimal gefordertem Set an Attributen sprechen
Umbenennung des Account Typen Functional in der neuen Registry 2.0 in Shared,
es besteht eine zu große Gefahr der permanenten Verwechslung zwischen Functional und Service
Einführung eines weiteren Account Typen für Maschinen oder Experimente Kontrollen,
die Abbildung über Blueprints halte ich für ungeeignet

Account Typen Registry 1	Account Typen Registry 2	Account shared	Private Data	Account never expires	Password never expires	Login von außerhalb (ssh, vpn)	Zugang Intranet → Internet	Compromised Account will be blocked without discussion	Compromised Account will be blocked only after discussion	Approval required (D4)	Intended Purposes Examples
Primary		no	allowed	no	no	allowed	yes	yes	no	no
	Primary	no	allowed	no	no	allowed	yes	yes	no	no	always first account for a person
Personal		no	allowed	no	no	allowed	yes	yes	no	no
	Personal	no	allowed	no	no	allowed	yes	yes	no	no	admin accounts
Functional		yes	no	allowed	allowed	not allowed	?	?	?	no
	Functional	yes	no	no	no	not allowed	yes	yes	no	no	temporary guests, students, temporary services, e.g. conferences, group accounts
	Shared	yes	no	allowed (default yes)	allowed (default no)	not allowed	yes	yes	no	no	shared data, email addresses, lab operation, e.g. measurements, automation solutions
	Service	yes	no	yes	yes	not allowed	no	no	yes	yes	accelerator and experiment controls, services for important infrastructure

zur Diskussion:

Approval für Service Accounts für ganze Namespaces wie MCA möglich
Es gibt sehr viele Gruppen Accounts, häufig auch für kurzzeitige Gäste (< 1 Woche) eingesetzt, hier scheint der Migrationspfad nicht klar
- zu welchem Account Typen sollen diese gehören? Sie benötigen ANE (das Ablaufdatum ist das des NS selber) aber keinesfalls PNE
- kann man Accounts auch an die Namespace Supervisoren bzw. den Namespace binden, d.h. nicht an Einzelpersonen? Würde m.E. Sinn machen
Was bedeutet, dass ein Account geblockt werden kann? Werden zukünftig auch Automaten aktiv, die blockieren? Wie sieht das dahinterliegende Konzept aus?
Wie kann man zuverlässig verhindern, dass irgendein Account der Maschinenkontrollen ohne Rückfrage und einem ok aus dem M-Bereich geblockt werden kann?
Aus meiner Sicht muss man evtl. ganze Namespaces davon ausnehmen können, ein Flag (mittels Blueprint) reicht m.E. nicht aus, das scheint mir im Betrieb zu unsicher, wird leicht übersehen,
insbesondere, wenn es manuell vergeben werden muss, sollte man dafür nicht einen extra Account Typen spendieren?
Warum soll es account never expires und cannot be disabled für alle Account Typen geben, worin liegt da der Sinn? Das lädt doch zu Mißbrauch geradezu ein.
Kann man einen Account gleichzeitig mehr als einem Blueprint zuordnen?