Betriebsanleitung DFN-AAI Anbindung an sciebo
Sync&Share NRW Service Provider
Die EntityID des Sync&Share NRW ServiceProviders (SP) ist https://sns-sp.sciebo.de/shibboleth-sp
.
Zur Teilnahme am Dienst müssen von Ihrem IdentityProvider (IdP) spezifische Attribute an den SP übertragen werden. Diese werden benutzt um nötige Datenstrukturen, die von OwnCloud benötigt werden, zu erzeugen.
Was wir von ihnen vorab benötigen
Vor Anbindung an den SP ist es zwingend notwendig das Sie uns ihre Rahmenparameter mitteilen, damit Sie für den Dienst freigeschaltet werden können. Diese sind:
EntityID
ihres Produktions-IdPs- Gültige Nutzergruppen (Affiliation), die von ihnen als teilnahmeberechtigt vorgesehen sind
Hinweise hierzu:
Der SNS-SP weist alle EntityIDs ab, die nicht explizit erlaubt sind, um so unberechtigte Einrichtungen vom Dienst auszuschließen. Wir tragen dort erst gültige EntityID-Strings ein, wenn dieser von ihnen mitgeteilt wurde. Daraus folgt z.B. auch, dass sie uns informieren sollten, wenn sich ihre EntityID ändert.
Ähnliche Einschränkungen gelten für gültige Benutzergruppen. Diese sind zwischen den teilnehmenden Einrichtungen durchaus unterschiedlich und ggf. vertraglich festgelegt. Auch wenn es auf IdP-Seite ihrerseits bereits möglich ist, möchten wir auch auf SP-Seite gerne darauf passend filtern. Dafür müssen sie uns mitteilen, welche Benutzergruppen sie für den Dienst zulassen wollen. Mögliche Gruppen sind employee, staff, faculty, student oder member.
Bitte teilen sie uns also mit, welche Gruppen sie für den Dienst vorgesehen haben. Erst wenn wir ihre Gruppen-Parameter eingestellt haben, wird die EntityID von uns freigeschaltet.
Nötige Attribute
Zwingend nötige Attribute um sich am Sync&Share NRW Dienst zu registrieren sind:
eduPersonPrincipalName
(EPPN)eduPersonScopedAffiliation
givenName
sn
mail
displayName
Optionaler Parameter:
eduPersonEntitlement
Diese Attribute müssen von Ihrem IdP an den Sync&Share SP übertragen werden. Ohne diese Parameter ist es nicht möglich, ein Konto für den Sync&Share Dienst einzurichten.
Sciebo-seitige Verwendung der Attribute
Oben genannte Attribute werden auf folgende Weise weiter verarbeitet:
Aus der EPPN wird die Owncloud Account-ID gebildet. Mit dieser ID kann der Nutzer sich am Dienst einloggen und kann Dateien mit anderen Nutzern teilen. Dafür muss er die Account-ID des zu Teilenden wissen.
Aus givenName, sn und EPPN wird der interne Display Name des Owncloud-Systems gebildet. Dieser Display Name hat dabei immer die Form "Nachname, Vorname (Account-ID)". Er wird beim Benutzer selber sichtbar sein, aber auch bei allen Dateien die mit oder von anderen Teilnehmern geteilt werden. Da Teilen von Dateien auch einrichtungsübergreifend möglich sein wird, ist diese Form nötig, um eindeutig identifizieren zu können, dass Dateien auch mit dem korrekten Ziel-Teilnehmer geteilt werden und es nicht zu Namensgleichheiten oder -Verwechslungen kommen kann.
Die eduPersonScopedAffiliation wird nur zur Überprüfung der Teilnahmeberechtigung benutzt und bisher nicht vom Owncloud-System verwendet. Sie wird jedoch mitgespeichert, um daraus ggf. zu einem späteren Zeitpunkt Owncloud-interne Gruppen bauen zu können und ggf. Nutzergruppenspezifische Berechtigungen abzuleiten.
Das mail Attribut wird nur intern vom Owncloud-System verwendet, um Benachrichtigungen zu verschicken. Die enthaltene Mail-Adresse ist danach von Benutzer nicht mehr konfigurierbar und im Owncloud-System auch nicht sichtbar.
Der displayName wird nicht vom Owncloud-System verwendet, sondern nur als zwingend nötiger Parameter im LDAP mitgespeichert. Er kann ggf. später z.B. in Anschreiben verwendet werden.
Sonderfall EPPN
Das Owncloud-System benötigt pro Nutzer eine unbegrenzt eindeutige Nutzer-ID. Es wurde deshalb die EPPN als Account-ID ausgewählt, um eine eindeutige ID zu erhalten, die an die Gepflogenheiten der teilnehmenden Einrichtungen angelehnt ist und mit Absicht einen passenden Erinnerungswert hat und um den Nutzern -- sowohl beim Login als auch beim Teilen -- das Leben zu erleichtern.
Für den Großteil der Teilnehmer ist dies die praktikabelste Lösung. Bei manchen Einrichtungen wird jedoch die lokale Benutzerkennung in einem Format gebildet, die Datenschutzbedenken aufwerfen kann. In diesem Fall ist zu prüfen, ob es zulässig ist, diese lokale Benutzerkennung auch für den Sync&Share NRW Dienst zu benutzen. Bitte behalten sie dabei im Hinterkopf, dass Sync&Share NRW ein vertraglich abgesichertes und geschlossenes System der teilnehmenden Einrichtungen untereinander ist und der Betrieb der Systeme dem Sinne nach einer Auftragsdatenverarbeitung entspricht.
Für den Betrieb der IdPs und des SPs untereinander, gilt für das übertragene EPPN-Attibut folgende, nur im Sync&Share NRW Kontext gültige Ausnahmeregelung:
Sollten sie nicht damit einverstanden sein, dass ihre lokalen Benutzerkennungen im Sync&Share Dienst weiterverwendet werden, ist es ihnen frei gestellt die EPPN, die sie an den SNS-SP übertragen, ihren Wünschen entsprechend anzupassen. Die sehr wichtige Nebenbedingung dabei ist, dass die EPPN die sie an den SNS-SP schicken, trotzdem immer noch unbegrenzt eindeutig sein muss!
Als Beispiel wäre es z.B. möglich von Ihrem IdP aus das mail-Attribut (falls dies unbedenklicher ist als die lokale Benutzerkennung) als EPPN maskiert zu übertragen. Dies ginge natürlich auch mit beliebigen anderen Attributen, etwa wenn sie in ihrem Identity Management eigene Kennungen mit eigenem Format für den Sync&Share Dienst erzeugen und bei ihren lokalen Benutzerattributen hinterlegen. Aufwand und Ideenreichtum ist an dieser Stelle ihnen überlassen. Und um es noch mal zu wiederholen und zu betonen: Die Verantwortung, dass diese IDs dann eindeutig und persistent sind, liegt dann bei Ihnen!
Sonderfall eduPersonEntitlement
Im sciebo-System gibt es einige Berechtigungen, die sich nicht immer aus den übertragenen Attributen ableiten lassen. Daher gibt es in der ein paar spezielle eduPersonEntitlement
-Strings, die von den lokalen IdPs mit übertragen werden können, um einem Benutzer bestimmte Berechtigungen zu geben.
Allgemeine Teilnahmeberechtigung
Hin und wieder kommt es vor, dass die Gruppenattribute, die bei den Einrichtungen lokal im IdentityManagement vorliegen, sich nicht auf passende Gruppen der Berechtigten für den Sync&Share Dienst abbilden lassen. So kann z. B. die lokal vorhandene Gruppe member
machmal zu viele oder zu wenige Identitäten enthalten, die dann z.B. nicht alle berechtigten Teilnehmer umfasst. Beispiele die im Vorfeld oft genannt wurden sind z.B. Alumni (die nicht teilnehmen dürfen) oder Lehrbeauftragte (die zwar teilnehmen sollen, aber z. B. nicht immer member
sind).
Um ihnen die Möglichkeit zu geben, an dieser Stelle ein wenig feingranularer die Berechtigten zu bestimmen als nur member
/employee
/staff
/faculty
/student
, haben wir ein eduPersonEntitlement
definiert, welches -- wenn es bei der Registrierung mit übertragen wird -- ganz unabhängig von der Affiliation-Zugehörigkeit trotzdem eine Registrierung des Nutzer zulässt.
Dieser spezielle eduPersonEntitlement
-String lautet:
https://www.sciebo.de/entitlements/registration/AllowedUser
Die Methode, wie und wem sie diesen Parameter ihren berechtigten Nutzern zuordnen, falls diese nicht durch eine Gruppenzugehörigkeit erfasst werden, bleibt ihnen überlassen. Dies sollte jedoch die Ausnahme sein. Primäres Mittel der Wahl ist es, die Affiliation-Gruppen passend zu befüllen.
Quota-Erhöhung
Das Standard-Quota, welches sciebo-Nutzer hochladen dürfen, liegt derzeit bei 30GB. Für Mitarbeiter der Hochschuleinrichtung, sowohl für Angestellte als auch für den Lehrkörper, ist jedoch eine Erhöhung des Quotas auf 500GB gestattet.
Sciebo-seitig ist nicht immer ohne weiteres ersichtlich, welcher Benutzer nun Mitarbeiter und welcher nur Student ist. Nutzer, welche die eduPersonAffilliation
employee
, staff
oder faculty
besitzen, erhalten automatisch die Berechtigung ihr Quota zu erhöhen. Diese Attribute werden allerdings nicht von allen Hochschulen mit übertragen. Manchmal wird nur das member
Attribut mitgeschickt, welches definitionsgemäß die genannten Gruppen zwar enthält, aber außerdem auch alle Studierenden umfasst.
Wir haben ein eduPersonEntitlement
definiert, dass -- wenn es gesetzt ist -- ebenso einem einzelnen Benutzer die Rechte gibt, sein Quota zu erhöhen. Hochschuleinrichtungen können so selber eruieren, ob eine bestimmte NutzerID zu einem Angestellten gehört, und diesem so die Berechtigung zur Quotaerhöhung erteilen.
Der eduPersonEntitlement
-String für die Quotaerhöhung lautet:
https://www.sciebo.de/entitlements/properties/Allow500GBQuota
Endnutzerformular zur Beantragung von Projektboxen
Die Einrichtung von Projektboxen erfolgt ausschließlich über den 1st Level Support der zugehörigen Einrichtung. Auf Wunsch kann jedoch jede Einrichtung bestimmten Endnutzern erlauben, einen Projektbox-Antrag über ein Webform versenden zu können. Das Webform wird im my.sciebo Portal für die berechtigten Endnutzer sichtbar. Die Berechtigung wird über ein Entitlement oder für bestimmte Affiliations gesetzt.
Mit dem Webform wird ein Projektbox-Antrag per E-Mail an den 1st Level Support der Einrichtung versendet. Der Vorteil besteht darin, dass die notwendigen Informationen zum Anlegen der Projektbox nicht nochmals explizit vom Support rückgefragt werden müssen und dass zusätzlich Informationen über Projektboxen des Antragstellers zur Verfügung stehen. Alternativ zu dem Entitlement kann das Webform für bestimmte Nutzergruppen/Affiliation (beliebige Kombination aus student
, employee
, faculty
oder staff
) freigeschaltet werden.
Der eduPersonEntitlement
-String für das Endnutzerformular zur Beantragung von Projektboxen lautet:
https://www.sciebo.de/entitlements/properties/AllowPboxRequest
Administrative Rechte
In der Sciebo-Verwaltung mySciebo können auch administrative Tätigkeiten durchgeführt werden, wie zum Beispiel Nutzer Sperren oder löschen, oder Projektboxen anlegen und verwalten. Hierfür muss man berechtigt sein. Wir unterscheiden zwischen lesenden und schreibenden administrativen Tätigkeiten. So ist z. B. der Sciebo-1st-Level Support eher an Informationen zum Status eines Accounts interessiert, sollte aber ggf. nicht gleich die Rechte haben, diesen auch zu löschen oder zu sperren.
Um einem lokalen Benutzeraccount entsprechende Rechte auf mySciebo zu geben, müssen diese eduPersonEntitlements zusammen mit den Benutzer-Attributen vom IdP übertragen werden. Zugriff auf administrative Tools wird durch folgende eduPersonEntitlement
-Strings an einen Benutzer gebunden:
Lesende administrative Tatigkeiten:
https://www.sciebo.de/entitlements/permissions/AdminRead
Schreibende bzw. Statusverändernde administrative Tätigkeiten:
https://www.sciebo.de/entitlements/permissions/AdminWrite
Berechtigung um Projektboxen anzulegen:
https://www.sciebo.de/entitlements/permissions/CreatePbox