(:redirect 'http://docs.studip.de/admin/Admins/Nutzerdomaenen':)

Analog zu den anderen Data-Mappings können AuthPlugins die Domänenzugehörigkeit eines Nutzers bei der Authentifizierung setzen. Dazu ist in dem abgeleiteten AuthPlugin die Methode getUserDomains() zu definieren, die eine Liste von Userdomain-IDs liefert. Ein Beispiel für die Verwendung kann aus dem Shibboleth-AuthPlugin ersehen werden.

Viele Stud.IPs (Zugang über LDAP-Authentifizierung) sind "eigentlich" zu abgeschottet; Gäste und Nutzer anderer Hochschulen kommen - wenn überhaupt erwünscht - nur mit zusätzlichem manuellen Adminstrationsaufwand in das System hinein. Eine generelle Öffnung ist für viele Betreiber keine Option, ebenso kann die Einbindung in eine Authentifizierungslösung, die über die eigene Hochschule hinausgeht, problematisch sein. Denn nicht alle Veranstaltungen sollen für Studierende anderer Hochschulen zugänglich sein und personenbezogene Daten dürfen nicht ohne explizite Zustimmung sichtbar werden.

Gleichzeitig gibt es aber viele Szenarien, in denen externe Nutzer das System nutzen können sollten. Um eine weitere Öffnung einer Stud.IP-Installation zu ermöglichen, steht seit der Version 1.8 das Nutzerdomänenkonzept zur Verfügung. Damit kann ein Nutzer zu einer oder mehrer so genannter "Domänen" gehören, z.B.:

Zielzustand: Nach Abarbeitung der Schritte können Studierende der FH sich einloggen, alle Veranstaltungen sehen, sich aber nur für die freigegebenen Veranstaltungen anmelden. Weitere Zugangsbeschränkungen und Anmeldeverfahren werden dabei berücksichtigt. Der Datenschutz ist gewährleistet: Sie selbst können unsichtbar werden und sehen die bereits im System vorhandenen Studierenden der Universität nur, wenn diese explizit zugestimmt haben, auch für "Gäste" sichtbar zu sein.

Viele Stud.IPs (Zugang über LDAP-Authentifizierung) sind "eigentlich" zu abgeschottet; Gäste und Nutzer anderer Hochschulen kommen nur mit zusätzlichem manuellen Adminstrationsaufwand in das System hinein. Eine generelle Öffnung ist für viele Betreiber keine Option. Ebenso kann die Einbindung in eine Authentifizierungslösung, die über die eigene Hochschule hinausgeht, problematisch sein. Nicht alle Veranstaltungen sollen für Studierende anderer Hochschulen zugänglich sein und personenbezogene Daten dürfen nicht ohne explizite Zustimmung sichtbar werden.

1. Ein (evtl. abzuleitendes) Shibboleth-AuthPlugin erstellen, mit dessen Hilfe sich die FH-Studierenden über eine Shibboleth-Förderation anmelden können. Das AuthPlugin muss als Resultat der Methode getUserDomains() die ID der in Schritt 1 definierten Domäne liefern.\\

Zielzustand: Nach Abarbeitung der Schritte können Studierende der FH sich einloggen, alle Veranstaltungen sehen, sich aber nur für die freigegebenen Veranstaltungen anmelden. Weitere Zugangsbeschränkungen und Anmeldeverfahren werden dabei berücksichtigt. Der Datenschutz wird berücksichtigt: Sie selbst können unsichtbar werden und sehen die bereits im System vorhandenen Studierenden der Universität nur, wenn diese explizit zugestimmt haben, auch für "Gäste" sichtbar zu sein.

In der Regel dürfen Dozenten, Admins und Root der Veranstaltung Nutzerdomänen zuordnen und existierende Zuordnungen ändern. Der Sperrregel-Mechanismus kann Nutzerdomänenzuordnungen berücksichtigen, so dass die Zuordnungsmöglichkeiten für Dozenten und Admins über diesen Mechanismus eingeschränkt werden können.

In Veranstaltungen, die einer oder mehreren Nutzerdomänen zugewiesen sind, können sich nur Nutzer eintragen, die ebenfalls mindestens einer dieser Nutzerdomänen angehören.

Alle Nutzer können, unabhängig von Domänenzuordnungen, alle sichtbaren Veranstaltungen finden und ihre Beschreibung/Detailseite einsehen. Nach Nutzerdomänen differenzierte Sichtbarkeitseinstellungen für Veranstaltungen gibt es (bislang) nicht.

Im Beispiel oben wird eine neue Nutzerdomäne mit dem Namen "Alumni der Universität Osnabrück" angelegt. Jede Nutzerdomäne hat neben dem (möglichst sprechenden) Namen eine interne ID. Interne IDs dürfen nur aus Buchstaben, Ziffern, Unter- und Bindestrichen sowie Punkten bestehen. IDs können nachträglich nicht mehr verändert werden.

Um die Nutzersichtbarkeit feiner steuern zu können, ist der zusätzliche Status global eingeführt worden. Nutzer mit diesem Status sind für alle Nutzer aller Domänen sichtbar. Die alten Sichtbarkeitszustände existieren weiterhin, beziehen sich aber nur noch auf Nutzer der eigenen Domäne(n).

Viele Stud.IPs (Zugang über LDAP-Authentifizierung) sind "eigentlich" zu abgeschottet, Gäste und Nutzer anderer Hochschulen kommen nur mit zusätzlichem manuellen Adminstrationsaufwand in das System hinein. Eine generelle Öffnung ist für viele Betreiber keine Option. Ebenso kann die Einbindung in eine Authentifizierungslösung, die über die eigene Hochschule hinausgeht, problematisch sein. Nicht alle Veranstaltungen sollen für Studierende anderer Hochschulen zugänglich sein und personenbezogene Daten dürfen nicht ohne explizite Zustimmung sichtbar werden.

Viele Stud.IPs (Zugang über LDAP-Authentifizierung) sind "eigentlich" zu abgeschottet, Gäste und Nutzer anderer Hochschulen kommen nur mit zusätzlichem manuellen Adminstrationsaufwand in das System hinein. Eine generelle Öffnung ist für viele Betreiber keine Option. Ebenso kann die Einbindung in eine Authentifizierungslösung, die über die eigene Hochschule hinausgeht, problematisch sein, weil nicht alle Veranstaltungen für Studierende anderer Hochschulen zugänglich und personenbezogene Daten für Nichtangehörige der Hochschule ohne Zustimmung sichtbar sein sollen.

Nutzer, die keiner Nutzerdomäne zugeordnet sind, werden anderen gegenüber bevorzugt. Sie haben grundsätzlich Zugang zu allen Veranstaltungen (von Zugangsbeschränkungen abgesehen). Hintergrund dieser Regelung sind zwei Überlegungen. Zum einen sollten vorhandene Stud.IP-Installationen ohne eingerichtete Nutzerdomänen unverändert weiter funktionieren und beim Einrichten einer Domäne nicht alle vorhandenen Accounts modifiziert werden müssen. Zum anderen bedeutet somit keiner Nutzerdomäne zugeordnet: "Der Nutzer ist hier zuhause".

Um eine weitere Öffnung einer Stud.IP-Installation zu ermöglichen, steht seit der Version 1.8 das Nutzerdomänenkonzept zur Verfügung. Damit kann ein Nutzer zu einer oder mehrer so genannter "Domänen" gehören, z.B.:

Bei den unverändert vorhandenen Zugangsberechtigungseinstellungen ist es (bislang) nicht möglich, auf Nutzerdomänen Bezug zu nehmen. Denkbar wäre dies z.B. bei der Kontingentierung. Hilfsweise könnte aber die Zuweisung zu (speziellen) Studiengängen ebenfalls vom AuthPlugin übernommen werden.

Nutzerdomänen können nur gelöscht werden, wenn ihnen keine Nutzer (mehr) zugeordnet sind.

1. Falls die Accounts manuell angelegt werden müssen, sind sie direkt nach dem Anlegen der Nutzerdomäne zuzuweisen. Das gilt analog für schon vorhandene Accounts.\\

Zielzustand: Nach Abarbeitung der Schritte können Studierende der FH sich einloggen, alle Veranstaltungen sehen, sich aber nur für die freigegebenen Veranstaltungen anmelden. Weitere Zugangsbeschränkungen und Anmeldeverfahren werden dabei berücksichtigt. Sie sehen allerdings nur personenbezogene Daten derjenigen Nutzer, die explizit eingewilligt haben, für Nutzer anderer Domänen sichtbar zu sein.

Veranstaltungen zuordnen

verfügbar ab Stud.IP-Version 1.8.0

verfügbar ab Stud.IP Version 1.8.0

Zielzustand: Nach Abarbeitung der Schritte können Studierende der FH sich einloggen, alle Veranstaltungen sehen, sich aber nur für die freigegebenen Veranstaltungen anmelden. Weitere Zugangsbeschränkungen und Anmeldeverfahren werden dabei berücksichtigt. Sie sehen allerdings nur personenbezogene Daten derjenigen Nutzer, die explizit eingewilligt haben, für Nutzern anderer Domänen sichtbar zu sein.

1. Eine Nutzerdomäne definieren, die später den FH-Studierenden zugewiesen wird. Die ID dieser Domäne kann frei gewählt werden.
   (Root => Globale Einstellungen -> Nutzerdomänen -> Anlegen)
2. Alle betroffenen Veranstaltungen der neuen Nutzerdomäne zuweisen. Bereits im System vorhandene Studierende ohne Nutzerdomäne können sich immer für alle Veranstaltungen anmelden, werden von der Aktion also nicht betroffen.
   (Root/Admin/Dozent => Veranstaltung aufrufen -> Administration der Veranstaltung -> Zugangsberechtigungen -> zugelassene Nutzerdomänen)

1. Ein neues AuthPlugin definieren, über das sich Studierende der FH einloggen können, z.B. durch Direktzugriff auf den zuständigen LDAP-Server. Das AuthPlugin muss als Resultat der Methode getUserDomains() die ID der in Schritt 1 definierten Domäne liefern.
   (Erweiterung der Codebasis notwendig. AuthPlugins liegen unter lib/classes/auth_plugins)
2. Ein abgeleitetes Shibboleth-AuthPlugin erstellen, mit dessen Hilfe sich die FH-Studierenden über eine Shibboleth-Förderation anmelden können. Das AuthPlugin muss als Resultat der Methode getUserDomains() die ID der in Schritt 1 definierten Domäne liefern.
   (Erweiterung der Codebasis notwendig. AuthPlugins liegen unter lib/classes/auth_plugins)
3. Falls die Account manuell angelegt werden müssen, muss darauf geachtet werden, dass sie direkt nach dem Anlegen der Nutzerdomäne zugewiesen werden. Das gilt analog für schon vorhandene Accounts.
   (Root/Admin => globale Einstellungen -> Neuen Nutzer anlegen -> persönliche Homepage -> Nutzerdaten -> Nutzerdomänen)

1. Alle betroffenen Veranstaltungen der neuen Nutzerdomäne zuweisen. Bereits im System vorhandene Studierende ohne Nutzerdomäne können sich immer für alle Veranstaltungen anmelden, werden von der Aktion also nicht betroffen. (Root/Admin/Dozent => Veranstaltung aufrufen -> Administration der Veranstaltung -> Zugangsberechtigungen -> zugelassene Nutzerdomänen)

1. Ein neues AuthPlugin definieren, über das sich Studierende der FH einloggen können, z.B. durch Direktzugriff auf den zuständigen LDAP-Server. Das AuthPlugin muss als Resultat der Methode getUserDomains() die ID der in Schritt 1 definierten Domäne liefern. (Erweiterung der Codebasis notwendig. AuthPlugins liegen unter lib/classes/auth_plugins)
2. Ein abgeleitetes Shibboleth-AuthPlugin erstellen, mit dessen Hilfe sich die FH-Studierenden über eine Shibboleth-Förderation anmelden können. Das AuthPlugin muss als Resultat der Methode getUserDomains() die ID der in Schritt 1 definierten Domäne liefern. (Erweiterung der Codebasis notwendig. AuthPlugins liegen unter lib/classes/auth_plugins)
3. Falls die Account manuell angelegt werden müssen, muss darauf geachtet werden, dass sie direkt nach dem Anlegen der Nutzerdomäne zugewiesen werden. (Root/Admin => globale Einstellungen -> Neuen Nutzer anlegen -> persönliche Homepage -> Nutzerdaten -> Nutzerdomänen)

1. Falls bislang keine Nutzerdomänen im System genutzt wurden, sollten die Nutzer auf die nun erweiterten Sichtbarkeitseinstellungen hingewiesen werden. Nutzer können nun ihren Sichtbarkeitsstatus auf global ändern und sind damit auch für FH-Studierende sichtbar. Per Default finden und sehen FH-Studierende nur andere FH-Studierende. (Die Sichtbarkeitsregeln in den Veranstaltungen gelten unverändert.)

Zuordnung von Veranstaltungen zu Nutzerdomänen

Bislang ist keine Möglichkeit vorgesehen, die Nutzerdomänenzuordnungen mehrerer Veranstaltungen mit einer einzelnen Aktion vorzunehmen. Automatismen für die Zuordnung sind ebenfalls nicht vorhanden.

Anwendungsbeispiel

Szenario: Die Sprachkurse der Universität Osnabrück sollen auch für Studierende der FH Osnabrück zugänglich sein. Die Studierenden der FH sollen sich aber nicht in andere reguläre Veranstaltungen der Universität eintragen können.

Abzuarbeitende Schritte:

1. Eine Nutzerdomäne definieren, die später den FH-Studierenden zugewiesen wird. Die ID dieser Domäne kann frei gewählt werden. (Root => Globale Einstellungen -> Nutzerdomänen -> Anlegen)
2. Alle betroffenen Veranstaltungen der neuen Nutzerdomäne zuweisen. Bereits im System vorhandene Studierende ohne Nutzerdomäne können sich immer für alle Veranstaltungen anmelden, werden von der Aktion also nicht betroffen.
3. Abhängig von der gewünschten Methode, wie die FH-Studierenden an einen Account gelangen:
   1. Ein neues AuthPlugin definieren, über das sich Studierende der FH einloggen können, z.B. durch Direktzugriff auf den zuständigen LDAP-Server. Das AuthPlugin muss als Resultat der Methode getUserDomains() die ID der in Schritt 1 definierten Domäne liefern.
   2. Ein abgeleitetes Shibboleth-AuthPlugin erstellen, mit dessen Hilfe sich die FH-Studierenden über eine Shibboleth-Förderation anmelden können. Das AuthPlugin muss als Resultat der Methode getUserDomains() die ID der in Schritt 1 definierten Domäne liefern.
   3. Falls die Account manuell angelegt werden müssen, muss darauf geachtet werden, dass sie direkt nach dem Anlegen der Nutzerdomäne zugewiesen werden.

In der Regel dürfen Dozenten, Admins und Root die Veranstaltung Nutzerdomänen zuordnen und existierende Zuordnungen ändern. Der Sperr-Regel-Mechanismus kann Nutzerdomänenzuordnungen berücksichtigen, so dass die Zuordnungsmöglichkeiten für Dozenten und Admins über diesen Mechanismus eingeschränkt werden können.

Die Zuordnung von Veranstaltungen zu Nutzerdomänen ist in der Veranstaltungsadministration unter "Zugangsberechtigungen" vorzunehmen.

Alle Nutzer können, unabhängig von Domänenzuordnungen alle sichtbaren Veranstaltungen finden und ihre Beschreibung/Detailseite einsehen. Nach Nutzerdomänen differenzierte Sichtbarkeitseinstellungen für Veranstaltungen gibt es (bislang) nicht.

Unterschiede ergeben sich lediglich bei der Frage, in welche Veranstaltungen sich Nutzer eintragen können. Bei unpassenden Domäneneinstellungen ist eine Eintragung grundsätzlich nicht möglich, unabhängig von eventuell aktivierten Zugangsbeschränkungen.

Für Veranstaltungen, die keiner Nutzerdomäne zugewiesen sind, können sich (vorbehaltlich anderer Zugangsbeschränkungen) nur Nutzer eintragen, die ebenfalls keiner Nutzerdomäne zugewiesen sind.

In Veranstaltungen, die einer oder mehrerer Nutzerdomänen zugewiesen sind, können sich nur Nutzer eintragen, die ebenfalls mindestens einer dieser Nutzerdomänen zugewiesen sind.

Bei den unverändert vorhandenen Zugangsberechtigungseinstellungen ist es (bislang) nicht möglich, auf Nutzerdomänen Bezug zu nehmen. Denkbar wäre dies z.B. bei der Kontingentierung. Hilfsweise könnte aber die Zuweisung zu (speziellen) Studiengängen ebenfalls vom AuthPlugin übernommen weden.

Die Domänenzugehörigkeit kann analog zur Zuordnung zu Studiengängen bei den Nutzerdaten des betreffenden Nutzers von Admins geändert werden, wenn die dem Nutzer zugeordnete Authentifizierungsmethode dies nicht automatisch übernimmt.

Analog den anderen Data-Mappings können AuthPlugins die Domänenzugehörigkeit eines Nutzers bei der Authentifizierung setzen. Dazu ist in dem abgeleiteten AuthPlugin die Methode getUserDomains() zu definieren, die eine Liste von Userdomain-IDs liefert. Ein Beispiel für die Verwendung kann aus dem Shibboleth-AuthPlugin ersehen werden.

Nutzer können sich selbst keinen Domänen zuweisen und keine Domänenzuordnung entfernen. Sie erhalten über ihre Nutzerdatenverwaltung allerdings Einblick in die Liste der zugeordneten Domänen.

Wie gehabt sind alle Nutzer für Root immer sichtbar.

Die Domänenzugehörigkeit kann analog zur Zuordnung zu Studiengängen bei den Nutzerdaten des betreffenden Nutzers von Root geändert werden.

Um die Nutzersichtbarkeit feiner steuern zu können, ist der zusätzliche Status global eingeführt worden. Nutzer mit diesem Status sind für alle Nutzer aller Domänen sichtbar. Die alten Sichtbarkeits-Zustände existieren weiterhin, beziehen sich aber nur noch auf Nutzer der eigenen Domäne(n).

Insgesamt gibt es folgende Sichtbarkeitszustände: |Sichtbarkeit|Bedeutung|Vom Nutzer selbst änderbar?| |global |sichtbar für alle Nutzer aller Domänen|ja| |immer |sichtbar für alle Nutzer der eigenen Domäne(n)|nein| |ja |sichtbar für alle Nutzer der eigenen Domäne(n)|ja| |unknown|Abhängig von lokaler Konfiguration|ja| |nein|für keine Nutzer sichtbar|ja| |nie|für keine Nutzer sichtbar|nein|

Nutzer, die keiner Nutzerdomäne zugeordnet sind, werden anderen gegenüber bevorzugt. Sie haben grundsätzlich Zugang zu allen Veranstaltungen (von Zugangsbeschränkungen abgesehen).

Nutzer, die mindestens einer Nutzerdomäne zugeordnet sind, können sich nur in Veranstaltungen eintragen, die für mindestens eine ihrer Nutzerdomänen freigegeben sind.

Erweiterte Sichtbarkeitseinstellungen

Um die Nutzersichtbarkeit feiner steuern zu können, ist der zusätzliche Status global eingeführt worden.

Zuordnung von Nutzern zu Nutzerdomänen

Auswirkungen

Zuordnung von Veranstaltungen zu Nutzerdomänen

Auswirkungen

Manuelle Zuordnung von Veranstaltungen zu Nutzerdomänen

Technische Details

Manuelle Verwaltung der Domänenzugehörigkeit

Automatische Domänenzuweisung mit AuthPlugins

Nutzerdomänen können von Root in der Nutzerdomänenverwaltung angelegt werden (zu finden unter "globale Einstellungen").

Im Beispiel oben wird eine neue Nutzerdomäne mit dem Namen "Almuni der Universität Osnabrück" angelegt. Jede Nutzerdomäne hat neben dem (möglichst sprechenden) Namen eine interne ID. Interne IDs dürfen nur aus Buchstaben, Ziffern, Unter- und Bindestrichen sowie Punkten bestehen. IDs können nachträglich nicht mehr verändert werden.

Nutzerdomänen können nur gelöscht werden, wenn Ihnen keine Nutzer (mehr) zugeordnet sind.

Im Beispiel oben wird eine neue Nutzerdomäne mit dem Namen "Gäste" angelegt. Jede Nutzerdomäne hat neben dem (möglichst sprechenden) Namen eine interne ID. Interne IDs dürfen nur aus Buchstaben, Ziffern, Unter- und Bindestrichen sowie Punkten bestehen. IDs können nachträglich nicht mehr verändert werden.

In der Nutzerdomänenverwaltung können Namen vorhandener Domänen verändert und Domänen komplett gelöscht werden. Achtung!

Verwaltung von Nutzerdomänen

Im Beispiel oben wird eine neue Nutzerdomäne mit dem Namen "Gäste" angelegt. Jede Nutzerdomäne hat neben dem (möglichst sprechenden) Namen eine interne ID. Interne IDs dürfen nur aus Buchstaben, Ziffern, Unter- und Bindestrichen sowie Punkten bestehen.

Im Beispiel oben wird eine neue Nutzerdomäne mit dem Namen "Gäste" angelegt. Jede Nutzerdomäne hat neben dem (möglichst sprechenden) Namen eine interne ID.

Nutzerdomänen können von Root in der Nutzerdomänenverwaltung angelegt werden (zu finden unter "globale Einstellungen").

Solange keine Nutzerdomänen eingerichtet sind, verhält sich das System an allen betroffenen Stellen wie vor der Einführung von Nutzerdomänen. Mit Anlegen der ersten Nutzerdomäne werden die erweiterten Möglichkeiten aktiviert.

Administration

Aktivierung

Nutzerdomänen müssen nicht explizit aktiviert werden.

Solange keine Nutzerdomänen eingerichtet sind, verhält sich das System an allen betroffenen Stellen wie vor der Einführung von Nutzerdomänen.

Einrichtung von Nutzerdomänen

Nutzerdomänen können von Root in der Nutzerdomänenverwaltung angelegt werden (zu finden unter Tools).

Grundlagen

Die Zuordnung eines Nutzers zu einer solchen Domäne kann manuell über die Nutzerverwaltung erfolgen, für den breiteren Einsatz ist allerdings die Zuordnung im Rahmen eines entsprechend konfigurierten AuthPlugins zweckmäßig. Somit werden dann z.B. alle über Shibboleth-Authentifizierung in das System gelangende Nutzer einer entsprechenden Domäne zugewiesen.

Nutzer, die einer Nutzerdomäne zugewiesen sind, können:

• sich nur in Veranstaltungen eintragen, die für ihre Nutzerdomäne freigegeben sind,
• nur solche Nutzer sehen (Aufruf persönlicher Homepages, Wer-ist-Online-Liste, Auffinden über Suchfunktion), die der gleichen Domäne angehören oder explizit erklärt haben, für Nutzer aller Domänen sichtbar sein zu wollen.

Um eine weitere Öffnung einer Stud.IP-Installation zu ermöglich, wurde mit der Version 1.8 das Nutzerdomänenkonzept entwickelt. Damit kann ein Nutzer zu einer oder mehrer so genannter "Domänen" gehören, z.B.:

(:toc:)

(:pagetoc:)

Viele Stud.IPs (Zugang über LDAP-Authentifizierung) sind "eigentlich" zu abgeschottet, Gäste und Nutzer anderer Hochschulen kommen nur mit zusätzlichem manuellen Adminstrationsaufwand in das System hinein. Eine generelle Öffnung ist für viele Betreiber keine Option, ebenso kann die Einbindung in eine Authentifizierungslösung, die über die eigene Hochschule hinaus problematisch sein, weil nicht alle Veranstaltungen für Studierende anderer Hochschulen zugänglich und nicht alle personenbezogenen Informationen sollen für Nichtangehörige der Hochschule sichtbar sein sollen.

Im Zusammenhang mit Shibboleth-Initiativen (DFN-AAI, NDS-AAI) wird das Problem besonders virulent: Will man z.B. vollen Zugriff für alle niedersächsischen Studierenden auf das eigene System??

Einrichtung und Verwendung von Nutzerdomänen

Idee

Problem

• Viele Stud.IPs (Zugang über LDAP-Authentifizierung) sind "eigentlich" zu abgeschottet, Gäste und Nutzer anderer Hochschulen kommen nur mit zusätzlichem manuellen Adminstrationsaufwand in das System hinein
• Eine generelle Öffnung ist für viele Betreiber keine Option, ebenso kann die Einbindung in eine Authentifizierungslösung, die über die eigene Hochschule hinaus problematisch sein, weil
  • nicht alle Veranstaltungen sollen für Studierende anderer Hochschulen zugänglich sein
  • nicht alle personenbezogenen Informationen sollen für Nichtangehörige der Hochschule sichtbar sein
• Im Zusammenhang mit der niedersächsischen Shibboleth-Initiative wird das Problem virulent: Will man vollen Zugriff für alle niedersächsischen Studierenden auf das eigene System??

Idee

• Einführung von "Nutzerdomänen", d.h. einer Zuordnung eines Nutzers zu einer (oder mehreren) Domänen, Statusgruppen o.ä. Beispiele:
  • Studierende der Uni Osnabrück
  • Studierende der FH Osnabrück
  • Alumni der Uni Osnabrück
  • Gäste
  • …
• Die Zuordnung zu einer solchen Domäne kann z.B. problemlos über die AuthPlugins(?) erfolgen
• Zu jeder Veranstaltung wird eine Liste der "zugelassenen" Domänen gepflegt
• Persönliche Homepages müssen (bis auf rudimentäre Informationen) für Nutzer anderer Domänen sichtbar gemacht werden

Vorteile:

• Die Stud.IP-Installation kann weiter geöffnet werden, sogar für Gäste, interessierte Schüler, … und gleichzeitig ist sichergestellt, dass bestimmte Bereiche nur für tatsächlich eingeschriebene Studenten zugänglich sind

Nachteile:

• Bei der Verwaltung von Veranstaltungen entsteht weiterer Aufwand und Sorgfaltsbedarf, evtl. kann hier mit brauchbaren Defaults gearbeitet werden, z.B. bei Veranstaltungstypen

Technische Umsetzung

• Einführung einer Domänenverwaltung ähnlich der jetzigen Studiengänge
• Erweiterung von Auth-Plugins
• Einführung einer Tabelle seminar_domain in der Positiv-Zuordnungen von Veranstaltungen zu Domänen verwaltet werden
• Entscheidung: Sollen nicht zugelassene Veranstaltungen für einen Nutzer: a) unsichtbar oder b) lediglich nicht abonnierbar sein?
• Einigung über den Sichtbarkeitsmechanismus für Homepages

Einrichtung und Verwendung von Nutzerdomänen