Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
de:attributes [2019/02/25 10:04] – [E-Learning] Wolfgang Pempe | de:attributes [2019/08/28 10:29] – Wolfgang Pempe |
---|
* [[http://macedir.org/specs/eduperson/|Ausführliche Dokumentation der eduPerson-Attribute sowie der gängigsten Attribute aus weiteren Schemata bzw. Klassen]] | * [[http://macedir.org/specs/eduperson/|Ausführliche Dokumentation der eduPerson-Attribute sowie der gängigsten Attribute aus weiteren Schemata bzw. Klassen]] |
* [[https://spaces.internet2.edu/display/macedir/LDIFs|eduPerson Schema]] (LDIFs, optional) | * [[https://spaces.internet2.edu/display/macedir/LDIFs|eduPerson Schema]] (LDIFs, optional) |
* Kommentierte [[de:common_attributes|Liste der am häufigsten verwendeten Attribute]] | * Kommentierte [[de:common_attributes|Liste der am häufigsten verwendeten / empfohlenen Attribute]] |
| * **Neu (2019)** [[http://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.html|SAML V2.0 Subject Identifier Attributes]] |
| |
==== E-Learning ==== | ==== E-Learning ==== |
Um den Anforderungen virtueller Organisationen zu genügen, die z.B. eine Infrastruktur gemäß der [[https://aarc-project.eu/architecture/|AARC Blueprint Architecture]] betreiben, wurde 2018 das [[https://github.com/voperson/voperson/blob/master/voPerson.md|voPerson Schema]] definiert. | Um den Anforderungen virtueller Organisationen zu genügen, die z.B. eine Infrastruktur gemäß der [[https://aarc-project.eu/architecture/|AARC Blueprint Architecture]] betreiben, wurde 2018 das [[https://github.com/voperson/voperson/blob/master/voPerson.md|voPerson Schema]] definiert. |
| |
| <callout type="danger"> |
==== Hinweise zum Datenschutz ==== | ==== Hinweise zum Datenschutz ==== |
* Identity Provider sollten zwar grundsätzlich in der Lage sein, einen [[de:common_attributes|emfohlenen Mindestsatz an Attributen]] zu generieren und zu übertragen, was aber nicht heißt, dass diese Attribute ungefragt an jeden beliebigen Service Provider übertragen werden sollten! | * Identity Provider sollten zwar grundsätzlich in der Lage sein, einen [[de:common_attributes|emfohlenen Mindestsatz an Attributen]] zu generieren und zu übertragen, was aber nicht heißt, dass diese Attribute ungefragt an jeden beliebigen Service Provider übertragen werden sollten! |
* Attributfreigaben sollten nur gezielt und unter Beachtung der aktuell gültigen Datenschutzgesetze und -Bestimmungen erfolgen. Insbesondere gilt das Prinzip der Datensparsamkeit, d.h. es sollten nur die Attribute und Attributwerte übertragen werden, die zur Nutzung der jeweiligen Anwendung tatsächlich erforderlich sind. | * Attributfreigaben sollten nur unter Beachtung der aktuell gültigen Datenschutzgesetze und -Bestimmungen erfolgen. Insbesondere gilt das Prinzip der Datensparsamkeit, d.h. es sollten nur die Attribute und Attributwerte übertragen werden, die zur Nutzung der jeweiligen Anwendung bzw. Infrastruktur tatsächlich erforderlich sind. |
* Konsultieren Sie hierzu den/die Datenschutzbeauftragte(n) Ihrer Heimateinrichtung. | * Konsultieren Sie hierzu den/die Datenschutzbeauftragte(n) Ihrer Heimateinrichtung. |
* Außer in Ausnahmefällen (mit dem/der Datenschutzbeauftragten abzustimmen), sollte ein IdP-seitiges //User Consent// Modul zum Einsatz kommen, das es den Nutzern ermöglicht, die zu übertragenden Attribute und Attributwerte zu kontrollieren und die Übertragung ggf. zu unterbinden. | * Außer in Ausnahmefällen (mit dem/der Datenschutzbeauftragten abzustimmen), sollte ein IdP-seitiges //User Consent// Modul zum Einsatz kommen, das es den Nutzern ermöglicht, die zu übertragenden Attribute und Attributwerte zu kontrollieren und die Übertragung ggf. zu unterbinden. Siehe hierzu auch die Seite [[de:shibidp3consent_dsgvo|Beispiel für eine EU-DSGVO-konforme Konfiguration des User Consent Moduls]]. |
* Auf europäischer Ebene existiert seit 2013 der im eduGAIN-Kontext entwickelte [[https://www.aai.dfn.de/der-dienst/datenschutz/data-protection-code-of-conduct/|GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA]], eine Selbstverpflichtungserklärung für Service Provider, deren Umsetzung mit verschiedenen technischen Maßnahmen von eduGAIN- und Föderationsseite unterstützt wird. Zu technischen Details siehe unter [[https://wiki.aai.dfn.de/de:entity_attributes|Entity Attribute]] sowie unter [[de:shibidp3attrfilter|Attribut-Konfiguration für E-Research SPs]]. \\ Einige grundsätzliche Überlegungen zum Thema Attributfreigabe im Rahmen des //Code of Conduct// finden sich [[https://wiki.refeds.org/display/CODE/What+attributes+are+relevant+for+a+Service+Provider|REFEDS-Wiki]]. | * Auf europäischer Ebene existiert seit 2013 der im eduGAIN-Kontext entwickelte [[https://www.aai.dfn.de/der-dienst/datenschutz/data-protection-code-of-conduct/|GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA]], eine Selbstverpflichtungserklärung für Service Provider, deren Umsetzung mit verschiedenen technischen Maßnahmen von eduGAIN- und Föderationsseite unterstützt wird. Zu technischen Details siehe unter [[https://wiki.aai.dfn.de/de:entity_attributes|Entity Attribute]] sowie unter [[de:shibidp3attrfilter|Attribut-Konfiguration für E-Research SPs]]. \\ Einige grundsätzliche Überlegungen zum Thema Attributfreigabe im Rahmen des //Code of Conduct// finden sich [[https://wiki.refeds.org/display/CODE/What+attributes+are+relevant+for+a+Service+Provider|REFEDS-Wiki]]. |
| </callout> |