Eine Person.
Mehrere Rollen an der Hochschule.

Eine Person kann einer Universität auf mehrere Arten angehören

Promovierende können zusätzlich lehren und eine bezahlte Stelle an der Universität haben. Studierende können Beschäftigte werden, ohne die Hochschulgemeinschaft zu verlassen. Gastwissenschaftlerinnen und Gastwissenschaftler können auch nach dem Ende eines Lehrauftrags eine Forschungsbeziehung behalten. Diese sich überschneidenden Beziehungen machen Identity Governance anspruchsvoller als einen einzelnen Datensatz mit dem Status aktiv oder inaktiv.

easyIGA bietet den Beteiligten einen fachlich verständlichen Weg, Anwendungszugriffe zu beantragen, zu genehmigen und zu überprüfen. Darunter liefert midPoint die konfigurierten Identitätsdaten, Richtlinien und Änderungen in Zielsystemen. So können Entscheidungstragende aus Wissenschaft und Verwaltung an der Steuerung der Zugriffsrechte mitwirken, während IAM-Fachleute das technische Modell pflegen.

Ein sinnvoller Ausgangspunkt ist eine Beziehung, die die Einrichtung steuern muss. Ermitteln Sie den maßgeblichen Datensatz, die damit verbundenen Anwendungszugriffe und die Person, die über eine Ausnahme entscheiden kann. Untersuchen Sie dann, was geschehen soll, wenn eine Beziehung endet, eine andere aber bestehen bleibt.

Für Serviceverantwortliche lautet die entscheidende Frage, welche aktuelle Beziehung eine Berechtigung rechtfertigt. Forschende brauchen nach dem Ende ihres Lehrauftrags vielleicht weiterhin eine Projektanwendung, während Zugriffe, die nur mit der Lehre verbunden sind, eine neue Entscheidung erfordern. easyIGA gibt den verantwortlichen Personen eine verständliche Möglichkeit, diesen Bedarf zu bewerten. Die folgenden Beispielszenarien verfolgen überlappende Zugehörigkeiten, Gastzugriffe und Semesterwechsel auf ihrem Weg durch die Identitätsquellen, die fachlichen Entscheidungen und die Ergebnisse in den Anwendungen, die die Einrichtung steuern muss.

Zugehörigkeit vor automatisierten Kontoänderungen modellieren

Eine Universität kann Identitätsdaten aus einem Studierendenverwaltungssystem, aus dem HR-System und aus lokalen Gästeverzeichnissen erhalten. Jede Quelle beschreibt eine andere Beziehung. Die Implementierung muss festlegen, welche Angaben maßgeblich sind und wie Datensätze, die sich auf dieselbe Person beziehen, miteinander verknüpft werden.

Beginnen Sie mit einer kleinen Zahl von Zugehörigkeitsfällen. Eine Person, die ausschließlich studiert, ist ein anderer Fall als eine studierende Person, die zusätzlich angestellt ist. Für eine Zugehörigkeit ehrenhalber kann eine andere Zugriffsrichtlinie gelten. Die fachliche Bedeutung jedes Falls sollte vereinbart sein, bevor das Identitätsteam die zugehörigen Berechtigungen konfiguriert.

midPoint unterstützt ein konfiguriertes Identitätsmodell und die Synchronisation mit angebundenen Quellen. Die Organisation muss dennoch entscheiden, wie sich ein Attribut auf Zugriffsrechte auswirkt. Ein brauchbares Modell behandelt das Ende einer Beziehung nicht als Beleg dafür, dass alle Beziehungen beendet sind.

Verwenden Sie für eine Evaluierung eine synthetische Person mit zwei gleichzeitigen Zugehörigkeiten. Beenden Sie eine davon und prüfen Sie die vorgesehenen Berechtigungen. Welche Zugriffe folgen der verbleibenden Beziehung? Welche Zugriffe müssen entzogen werden? Welche Ausnahmeberechtigung erfordert eine ausdrückliche Entscheidung der verantwortlichen Person?

Testen Sie auch eine Abweichung zwischen Quellen. Ähnliche Namen oder wechselnde E-Mail-Adressen sollten nicht als ausreichender Beleg gelten, um zwei Personen zusammenzuführen. Vereinbaren Sie, wie unsichere Zuordnungen untersucht werden. Die Qualität der Quellen und die Identitätskorrelation sind technische Verantwortlichkeiten, die den fachlichen Workflow unterstützen; eine verständliche Oberfläche kann eine falsche Personenzuordnung nicht ausgleichen.

Den Semesterbeginn für Menschen und Systeme beherrschbar machen

Ein Semesterwechsel kann viele erwartbare Identitätsänderungen auf einmal mit sich bringen. Manche Personen sind neu, manche kehren zurück, und manche haben eine andere Beziehung als im Vorjahr. Die Einrichtung braucht einen Prozess, der diese Änderungen für die Betroffenen verständlich und für das Identitätsteam im Betrieb beherrschbar macht.

Vereinbaren Sie zuerst, ab wann ein Datensatz in der Quelle für Zugriffsrechte maßgeblich wird. Eine Bewerbung um Zulassung, ein angenommener Studienplatz und eine Einschreibung können unterschiedliche Bedeutungen haben. Die Implementierung sollte die tatsächlichen Regeln der Einrichtung verwenden, statt anzunehmen, dass jeder Datensatz im Studierendensystem dieselbe Zugriffsberechtigung darstellt.

Testen Sie bei Berechtigungen, die über konfigurierte Lebenszyklusregeln vergeben werden, das Ereignis in der Quelle und die Operation im Zielsystem. Für Zugriffe, die eine Anfrage erfordern, bietet easyIGA einen fachlich verständlichen Katalog und einen Entscheidungs-Workflow. Beide Wege sollten klar erklärt werden, damit Studierende und Beschäftigte wissen, wann sie etwas beantragen müssen.

Arbeiten Sie mit einer Pilotgruppe und repräsentativen Anwendungen. Bestätigen Sie das Verhalten für eine neue und für eine zurückkehrende Person. Nehmen Sie einen Datensatz auf, der unvollständig ist oder nach dem erwarteten Termin eintrifft. Das Betriebsverfahren sollte festlegen, wer ihn korrigiert und wie die betroffene Person eine hilfreiche Antwort erhält.

Schließen Sie nicht von einer kleinen Demo auf die Leistungsfähigkeit. Ein Rollout in der Größenordnung eines Semesterbeginns muss mit der vorgeschlagenen Konfiguration und Last getestet werden. Erfassen Sie die Nachweise für Entscheidungen zu Kapazität und Wiederherstellung getrennt von der Bewertung der Anfrageoberfläche durch die Fachbereiche. Beides ist wichtig, beantwortet aber unterschiedliche Fragen.

Zugriffsanfragen der Wissenschaft am Zweck ausrichten

Wissenschaftliches Personal braucht unter Umständen eine Lehranwendung, einen gemeinsamen Forschungsarbeitsbereich oder eine Verwaltungsrolle. Ein Katalog, der nur technische Gruppennamen zeigt, lässt die antragstellende Person raten. Er erschwert auch die Arbeit der genehmigenden Person, weil die Anfrage nicht erklärt, was der Zugriff bedeutet.

easyIGA gibt Mitarbeitenden und Führungskräften einen verständlichen Ausgangspunkt für eine Zugriffsanfrage. Die Einrichtung ordnet jede fachliche Beschreibung einer konfigurierten Rolle zu und entscheidet, wer sie genehmigen darf. IAM-Fachleute bleiben für die zugrunde liegende Konfiguration von midPoint und die Anbindung der Zielsysteme verantwortlich.

Nehmen Sie als Beispiel eine Anfrage, die Lehranwendung eines Instituts zu administrieren. Die Beschreibung sollte die normale Nutzung von der Administration unterscheiden. Der Genehmigungsweg sollte die Person erreichen, die diese Verantwortung trägt; das kann eine andere Person sein als die direkte Führungskraft der antragstellenden Person.

Bitten Sie bei der Demo die Person aus der Wissenschaft, die benötigte Rolle ohne Anleitung durch das Identitätsteam zu finden. Bitten Sie dann die genehmigende Person, die Entscheidung anhand der angezeigten Informationen zu erklären. So prüfen Sie direkt, ob Katalog und Workflow zur Sprache der Einrichtung passen.

Das Ergebnis sollte über die Genehmigung hinaus verfolgt werden. Eine erfolgreiche Entscheidung beweist nicht, dass eine Zielanwendung die Änderung angenommen hat. easyIGA unterscheidet die Ergebnisse verifiziert, ausstehend, fehlgeschlagen und unbekannt und gibt den Beteiligten so ein aussagekräftigeres Bild vom Fortschritt. Vereinbaren Sie, welches Team eine Operation untersucht, die kein bestätigtes Ergebnis erreicht hat.

Gastforschenden einen Sponsor und eine definierte Beziehung geben

Ein Gast kann einem Institut bekannt sein, ohne im zentralen HR-System der Einrichtung aufzutauchen. Eine informelle Vereinbarung kann völlig legitim sein und trotzdem einen verantwortlichen Zugriffsprozess erfordern. Entscheidend ist, einen genehmigten Identitätsdatensatz und einen verantwortlichen internen Sponsor festzulegen.

Der Sponsor sollte verstehen, warum der Gast Zugriff braucht und welche Anwendungen betroffen sind. Der Name eines Instituts allein reicht nicht, wenn niemand dafür verantwortlich ist, die Beziehung später zu überprüfen. Legen Sie fest, wer den Datensatz pflegt und was geschieht, wenn der Sponsor ausscheidet oder die Rolle wechselt.

Nutzen Sie den konfigurierten Anfrageprozess für die Anwendungen, die eine Entscheidung erfordern. easyIGA kann diese Anfragen für den Sponsor und die für die Anwendung verantwortliche Person verständlich machen. Die Implementierung bestimmt den unterstützten Genehmigungsweg und die Nachweise, die im vorgeschlagenen Release verfügbar sind.

Eine Evaluierung sollte eine Verlängerung des Aufenthalts und einen Wechsel des gastgebenden Instituts einschließen. Der richtige Zugriff kann sich ändern, obwohl Name und E-Mail-Adresse der Person gleich bleiben. Testen Sie das Lebenszyklusereignis, statt anzunehmen, dass ein fortbestehendes Konto beweist, dass jede Berechtigung weiterhin gerechtfertigt ist.

Unterscheiden Sie am Ende der Beziehung zwischen den Zugriffen, die enden sollen, und einer gesondert genehmigten Fortsetzung. Eine Zusammenarbeit kann nach einem Aufenthalt weitergehen, ohne dass jede administrative Berechtigung bestehen bleiben muss. Die Einrichtung braucht für diesen Übergang eine ausdrückliche Richtlinie und eine überprüfbare Entscheidung, wobei die daraus folgenden Änderungen in den Zielsystemen geprüft werden.

Forschungszugriffe mit den richtigen Verantwortlichen überprüfen

Ein zentrales IT-Team kann wissen, dass ein Konto existiert, ohne zu wissen, ob die Person noch zu einem Forschungsprojekt gehört. Die für das Projekt verantwortliche Person kennt diese Beziehung vielleicht, hat aber keine klare Liste der betroffenen Anwendungsberechtigungen. Zugriffsüberprüfungen bringen diese Perspektiven zusammen.

easyIGA zeigt Zugriffsrechte in der Überprüfung mit dem verfügbaren Kontext an. „Letzte Nutzung“, „Gewährt von“ und „Genehmigt von“ hängen von den angebundenen Quellen und der erfassten Genehmigungshistorie ab. Die Informationen sollen der prüfenden Person helfen, die Berechtigung zu bewerten, während fehlende Nachweise sichtbar bleiben.

easyIGA protokolliert bei Anfragen, die über das Produkt gestellt werden, die antragstellende Person und die erfassten Genehmigungsschritte. Zugriffsrechte, die außerhalb von easyIGA vergeben wurden, werden anhand der von midPoint erfassten Erstellungsangaben gesondert gekennzeichnet. Historischen Einträgen kann eine genehmigende oder vergebende Person fehlen; fehlende Informationen werden ausdrücklich angezeigt.

Benennen Sie für ein Beispiel aus der Forschung das Projekt und die zu überprüfenden Anwendungszugriffe. Eine Person kann nach dem Ausscheiden aus dem Projekt in der Einrichtung bleiben. Fragen Sie die prüfende Person anhand der tatsächlich verfügbaren Nachweise, ob die aktuelle Beziehung die Berechtigung noch rechtfertigt.

Jüngste Aktivität und fachlicher Bedarf sind unterschiedliche Fragen. Manche Forschungszugriffe werden selten genutzt, sind aber weiterhin autorisiert. Ein Feld zur letzten Nutzung sollte in die Entscheidung einfließen, sie aber nicht vorgeben. Protokollieren Sie das Ergebnis der prüfenden Person über den unterstützten Workflow und verfolgen Sie jede Entzugsoperation bis zu ihrem Ergebnis im Zielsystem. So führt die Überprüfung zu Maßnahmen, statt eine periodische Pflichtübung zu bleiben.

Alumni und frühere Beschäftigte per Richtlinie regeln

Das Ende von Studium oder Beschäftigung bedeutet nicht unbedingt, dass alle Beziehungen zu einzelnen Diensten im selben Moment enden. Eine Einrichtung bietet vielleicht ausgewählte Dienste für Alumni an oder hat einen vorübergehenden administrativen Bedarf. Das sind Richtlinienentscheidungen, die genau festgelegt werden sollten.

Listen Sie zuerst die betroffenen Dienste und ihre Verantwortlichen auf. Legen Sie fest, welche Zugriffe einer fortbestehenden Beziehung folgen und welche eine gesonderte Entscheidung erfordern. Verwenden Sie keinen einzigen, weit gefassten Status für ehemalige Beschäftigte und Alumni zugleich, wenn ihre Zugriffsregeln voneinander abweichen.

Die Konfiguration von midPoint kann maßgebliche Ereignisse mit den vorgesehenen Rollen und Änderungen in Zielsystemen verbinden. easyIGA stellt rund um die unterstützten Workflows die Oberfläche für Anfragen und Überprüfungen bereit. Die Einrichtung muss die Richtlinie festlegen und die Operationen validieren, die sie umsetzen.

Ein sinnvoller Test begleitet eine synthetische Person vom Studium zum Alumni-Status, während eine weitere Beschäftigungsbeziehung aktiv bleibt. Prüfen Sie jede Anwendung einzeln, statt den Erfolg am Fortbestehen der zentralen Identität zu messen. Manche Berechtigungen bleiben vielleicht bestehen, während andere enden sollten.

Legen Sie auch den Prozess für Fehler und späte Korrekturen fest. Ein zurückgenommenes Ausscheiden oder ein korrigierter Studiendatensatz kann erfordern, dass einige Zugriffe wiederhergestellt werden. Die Implementierung sollte das vereinbarte Verhalten zeigen, ohne anzunehmen, dass jede frühere Berechtigung automatisch zurückkehren sollte. Die Richtlinie sollte das Ergebnis beschreiben, das die Organisation erreichen will, und die Einträge sollten zeigen, was tatsächlich geschehen ist.

Anwendungsintegration von Single Sign-on unterscheiden

Eine erfolgreiche Anmeldung belegt nicht, dass die Berechtigungen einer Person angemessen sind. Authentifizierung und Identity Governance behandeln verwandte, aber unterschiedliche Fragen. Die Campus-Architektur sollte erklären, wie Identity Provider, Zielanwendungen und Governance-Plattform zusammenarbeiten.

midPoint liefert die konfigurierte Grundlage für Identitätsmanagement und Provisionierung. Eine Integration kann eine Verzeichnisgruppe verwalten, die eine Anwendung nutzt, oder Konten direkt über eine Anwendungsschnittstelle ändern. Die Implementierung muss festlegen, welcher Mechanismus jede Berechtigung im Umfang steuert.

Die Übersicht der midPoint-Konnektoren bietet technischen Teams einen Ausgangspunkt. Validieren Sie die tatsächliche Version und die Operationen des Studierendensystems, des Verzeichnisses oder des Cloud-Dienstes, die Sie anbinden wollen. Ein bekanntes Produktlogo ist kein Beleg dafür, dass jeder benötigte Workflow auf dem Campus ohne Konfiguration unterstützt wird.

easyIGA ergänzt midPoint um fachliche Zugriffsentscheidungen. Es ersetzt weder den Identity Provider der Einrichtung, noch macht es jede Administrationsfunktion von midPoint über eine identische easyIGA-Oberfläche verfügbar. Vergleichen Sie das vorgeschlagene Release anhand einer echten Anwendungsrolle und der Menschen, die damit arbeiten müssen.

Wenn eine Integration eingeschränkt ist, dokumentieren Sie diese Einschränkung. Ein Zielsystem liefert vielleicht Kontodaten, aber keine detaillierte Nutzungshistorie. Der Überprüfungsprozess sollte keinen Wert für die letzte Nutzung erfinden, damit der Eintrag vollständig aussieht. Zu wissen, welche Angaben verfügbar sind, hilft prüfenden Personen, sorgfältiger zu entscheiden, und hilft dem Team, die Integrationsarbeit zu priorisieren.

Technischen Konten einen eigenen Lebenszyklus geben

Forschung und Verwaltung können von Konten abhängen, die von Anwendungen oder geplanten Prozessen genutzt werden. Ein solches Konto kann die Person überdauern, die es angelegt hat. Es sollte einen dokumentierten Zweck und eine verantwortliche Person haben, statt automatisch wie eine gewöhnliche Identität von Beschäftigten behandelt zu werden.

Wählen Sie ein repräsentatives Konto in einer nicht sensiblen Umgebung. Ermitteln Sie den Dienst, der davon abhängt, die benötigten Berechtigungen und das Team, das über Änderungen entscheiden darf. Die Zuordnung zu einer Person und die Verantwortung für einen Dienst können unterschiedliche Beziehungen sein, und das Identitätsmodell sollte die beabsichtigte Bedeutung klar machen.

Prüfen Sie bei einer Evaluierung von easyIGA, welcher Workflow im vorgeschlagenen Release für diesen Kontotyp verfügbar ist. Klären Sie, was die angebundene Quelle liefert und was ein organisatorischer Eintrag bleibt. Schließen Sie nicht aus dem Vorhandensein einer Kontenliste auf eine flächendeckende Erkennung nicht-menschlicher Identitäten.

Testen Sie einen Wechsel des verantwortlichen Teams. Der technische Dienst kann weiterlaufen, auch wenn Forschende oder Verwaltungspersonal ausscheiden. Die richtige Maßnahme ist vielleicht ein Wechsel der Verantwortung statt einer sofortigen Entfernung des Kontos. Diese Entscheidung sollte jemand treffen, der die Abhängigkeit versteht.

Die Seite zu verwaisten Konten und nicht-menschlichen Identitäten erläutert den Umfang, über den Sie sprechen sollten. Zugangsdaten, privilegierte Sitzungen und Maschinenauthentifizierung erfordern vielleicht andere Kontrollen. Identity Governance sollte Verantwortung und Überprüfungsentscheidungen mit diesen Kontrollen verbinden, ohne zu behaupten, jeden Teil der Sicherheitsarchitektur zu ersetzen.

Kosten und Betriebsverantwortung sichtbar machen

Für midPoint fällt keine Softwarelizenzgebühr an. Einige Funktionen von midPoint, etwa Simulationen, Hochverfügbarkeits-Clustering oder eine andere Datenbank als PostgreSQL, erfordern ein Evolveum-Abonnement, das wir organisieren und in Ihr Angebot aufnehmen. easyIGA ist ein kommerzielles Produkt mit einem veröffentlichten jährlichen Abonnementmodell pro verwalteter Identität; die Einführung in einem vereinbarten Umfang ist enthalten. Holen Sie die aktuellen Konditionen für die Personengruppen und Funktionen ein, die die Einrichtung nutzen will.

Definieren Sie im Hochschulbereich die Zahl der Identitäten sorgfältig. Datensätze von Studierenden, Beschäftigten und Gästen können sich überschneiden. Fragen Sie, wie das vorgeschlagene kommerzielle Modell eine Person mit mehreren Beziehungen behandelt und welche Servicekonten verwaltet werden. Die Zählregel sollte vereinbart und nicht aus der Zahl der Datensätze in einem einzelnen Quellsystem abgeleitet werden.

Berücksichtigen Sie den tatsächlichen Implementierungsaufwand. Bereinigung der Quellen, Rollenbeschreibungen und Anwendungstests können das Projekt beeinflussen, auch wenn ein Konnektor vorhanden ist. Ein Angebot sollte die ersten Systeme, die Verantwortung für die Migration und die Abnahmekriterien benennen. Es sollte außerdem spätere Phasen gesondert ausweisen.

Selbst gehosteter Betrieb ist das Standardmodell für die Bereitstellung. Für Organisationen ohne geeignete Infrastruktur ist auf Anfrage eine in der EU gehostete Bereitstellung verfügbar, die unser Team betreibt. Vergleichen Sie den internen Betriebsaufwand mit dem vorgeschlagenen Leistungsumfang, einschließlich der Verantwortung für Wartung und Wiederherstellung. Der Standort allein klärt nicht alle Bedingungen, die eine Einrichtung für ihre Due-Diligence-Prüfung braucht.

Nutzen Sie die Preisinformationen und die Seite zu den Bereitstellungsoptionen, um ein Gespräch mit klar abgegrenztem Umfang vorzubereiten. Übernehmen Sie keinen Hochschulrabatt und keine Abonnementvereinbarung aus dem midPoint-Angebot eines anderen Anbieters in der Annahme, dass sie für easyIGA gelten. Kommerzielle Bedingungen müssen eigens bestätigt werden.

Zugriffsrechte von akademischen Entscheidungen unterscheiden

Der Identitätsprozess sollte die autorisierten Entscheidungen der Einrichtung umsetzen, ohne einen akademischen Status zu erfinden. Einschreibung, Beschäftigung und Mitwirkung an der Forschung haben jeweils eine verantwortliche Stelle. Die Governance-Konfiguration braucht eine verlässliche Abbildung dieser Entscheidungen, bevor sie diese Anwendungszugriffen zuordnen kann.

Ein korrigierter Studiendatensatz kann zum Beispiel eine Änderung am Zugriff auf eine Lernanwendung rechtfertigen. Das Identitätsteam sollte wissen, welches Quellereignis maßgeblich ist und wie die Korrektur verifiziert wird. Es sollte den akademischen Status der studierenden Person nicht daraus ableiten, ob ein Anwendungskonto vorhanden ist oder nicht.

Nutzen Sie diese Grenze, wenn Sie Supportverfahren festlegen. Wenn Studierende fehlende Zugriffe melden, kann eine Korrektur der Identität oder eine Entscheidung der akademischen Verwaltung nötig sein. Eine klare Übergabe hilft dem Supportteam, das Anliegen an die Stelle weiterzuleiten, die es lösen kann, während das protokollierte Ergebnis im Zielsystem zeigt, wann die Änderung in der Anwendung tatsächlich abgeschlossen ist.

Den Workflow mit den Menschen bewerten, die ihn nutzen werden

Ein Pilotprojekt auf dem Campus sollte eine Person einbeziehen, die Zugriff beantragt, eine Person, die ihn genehmigt, und eine Fachperson, die die Integration betreibt. Jede dieser Personen sieht einen anderen Teil des Prozesses. Ihre gemeinsamen Beobachtungen sind nützlicher als eine Demo, die sich auf die technische Administration beschränkt.

Wählen Sie eine kleine Zahl repräsentativer Fälle. Eine gewöhnliche Anwendungsanfrage zeigt die grundlegende Nutzung. Eine Person mit sich überschneidenden Zugehörigkeiten testet das Identitätsmodell. Ein Gast, der den Sponsor wechselt, testet die fachliche Verantwortung. Ein Zielsystem, das eine Operation nicht bestätigen kann, testet den Ausnahmeweg.

Verwenden Sie zu Beginn synthetische Datensätze. Legen Sie vor jedem Fall fest, wie ein korrektes Ergebnis aussieht. Dokumentieren Sie das tatsächliche Release, den konfigurierten Umfang und die vorgeführten Nachweisfelder. Halten Sie geplante Funktionen getrennt von den Funktionen, die abgenommen werden.

Die Seite von Evolveum zum Hochschulbereich liefert Branchenkontext für die zugrunde liegende Plattform. Die mindestens 14 midPoint-Einführungen unseres Teams sind Erfahrung als Anbieter, keine Hochschulreferenzen für easyIGA. Das Produkt sollte anhand des aktuellen Workflows und der für Ihre Einrichtung relevanten Nachweise bewertet werden.

30-minütige Demo anfragen. Bringen Sie zum Gespräch mit unserem Team eine geänderte Zugehörigkeit oder eine Frage zur Zugriffsüberprüfung mit, die Ihre Einrichtung heute nur schwer erklären kann. Das gibt dem Gespräch einen konkreten Zweck und eine klare Grundlage für die Entscheidung, ob sich eine Evaluierung von easyIGA mit festgelegtem Umfang lohnt.