Dokumentation DFN-AAI, DFN-PKI und eduroam - de:aai

about

Anonymous (anonymous@undisclosed.example.com) — 2023-01-12T16:04:59+00:00

2022/10/14 15:35		aktuell
Zeile 40:		Zeile 40:
	* Der Ressourcenanbieter (Service Provider) kann sich darauf verlassen, dass alle Änderungen zeitnah ausgeführt werden.		* Der Ressourcenanbieter (Service Provider) kann sich darauf verlassen, dass alle Änderungen zeitnah ausgeführt werden.
	* Die Prozesse müssen soweit schriftlich dokumentiert werden, dass das Sicherheitsniveau aus der Dokumentation ableitbar ist.		* Die Prozesse müssen soweit schriftlich dokumentiert werden, dass das Sicherheitsniveau aus der Dokumentation ableitbar ist.
-	Siehe hierzu auch die Beschreibung der [[de:degrees_of_reliance\|Verlässlichkeitsklassen in der DFN-AAI]].	+	Siehe hierzu auch unter [[de:aai:assurance\|Identity Assurance]].

	===== Geschichte der DFN-AAI =====		===== Geschichte der DFN-AAI =====

assurance

Anonymous (anonymous@undisclosed.example.com) — 2024-07-08T08:10:52+00:00

2023/01/12 19:21		aktuell
Zeile 7:		Zeile 7:
	Das [[https://refeds.org/assurance\|REFEDS Assurance Framework]] definiert, wie Informationen zur Verlässlichkeit von Identitäten über Werte des Attributs [[de:common_attributes#a14\|eduPersonAssurance]] transportiert werden. Somit versetzt es Dienstanbieter bzw. Service Provider in die Lage, je nach individuellem Schutzbedarf besonders relevante Verlässlichkeits-Kriterien ggf. separat zu adressieren. Beim REFEDS Assurance Framework handelt es sich um eine international anerkannten Standard, der die Anschlussfähigkeit der DFN-AAI im internationalen Kontext sicherstellt. Dies betrifft in besonderem Maße die Unterstützung von Forschungscommunities, die auf föderationsübergreifende Zusammenarbeit im Rahmen von [[de:edugain\|eduGAIN]] angewiesen sind.		Das [[https://refeds.org/assurance\|REFEDS Assurance Framework]] definiert, wie Informationen zur Verlässlichkeit von Identitäten über Werte des Attributs [[de:common_attributes#a14\|eduPersonAssurance]] transportiert werden. Somit versetzt es Dienstanbieter bzw. Service Provider in die Lage, je nach individuellem Schutzbedarf besonders relevante Verlässlichkeits-Kriterien ggf. separat zu adressieren. Beim REFEDS Assurance Framework handelt es sich um eine international anerkannten Standard, der die Anschlussfähigkeit der DFN-AAI im internationalen Kontext sicherstellt. Dies betrifft in besonderem Maße die Unterstützung von Forschungscommunities, die auf föderationsübergreifende Zusammenarbeit im Rahmen von [[de:edugain\|eduGAIN]] angewiesen sind.

-	Eine ausführlichere Darstellung des Sachverhalts findet sich in den [[https://www2.dfn.de/fileadmin/5Presse/DFNMitteilungen/DFN_Mitteilungen_100.pdf\|DFN-Mitteilungen Nr. 100]] ab Seite 42 und in dieser [[https://download.aai.dfn.de/ws/2022/refeds_assurance_suite.pdf\|Präsentation]].	+	Eine ausführlichere Darstellung des Sachverhalts findet sich in den [[https://download.aai.dfn.de/publikationen/dfn-mitteilungen/DFN-Mitteilungen-100.pdf\|DFN-Mitteilungen Nr. 100]] ab Seite 42 und in dieser [[https://download.aai.dfn.de/ws/2022/refeds_assurance_suite.pdf\|Präsentation]].

	===== Informationen für Identity Provider =====		===== Informationen für Identity Provider =====

assurance_idp

Anonymous (anonymous@undisclosed.example.com) — 2025-01-17T12:47:12+00:00

2024/11/28 10:19		aktuell
Zeile 5:		Zeile 5:
	Lesen Sie bitte die aktuelle Version der [[https://refeds.org/assurance\|Spezifikation]]! \\ Bei Fragen wenden Sie sich bitte an das [[hotline@aai.dfn.de\|DFN-AAI Team]].		Lesen Sie bitte die aktuelle Version der [[https://refeds.org/assurance\|Spezifikation]]! \\ Bei Fragen wenden Sie sich bitte an das [[hotline@aai.dfn.de\|DFN-AAI Team]].

-	Um als Identity Provider bzw. Heimateinrichtung grundsätzliche Konformität mit dem REFEDS Assurance Framework zu signalisieren und entsprechende Attributwerte zu übertragen, müssen vier sog. Conformance Criteria erfüllt sein:	+	Um als Identity Provider bzw. Heimateinrichtung grundsätzliche Konformität mit dem REFEDS Assurance Framework zu signalisieren und entsprechende Attributwerte zu übertragen, müssen die sog. Conformance Criteria erfüllt sein:
	- The Identity Provider is operated with organizational-level authority \\ Kommentar: IdPs müssen auch vertragstechnisch im Namen der jeweiligen Einrichtung betrieben werden, einzelne Fakultäten oder Universitäts-Institute kommen hierfür nicht in Frage		- The Identity Provider is operated with organizational-level authority \\ Kommentar: IdPs müssen auch vertragstechnisch im Namen der jeweiligen Einrichtung betrieben werden, einzelne Fakultäten oder Universitäts-Institute kommen hierfür nicht in Frage
	- The Identity Provider is trusted enough to be used to access your organization’s own systems \\ Kommentar: ... sofern diese SAML-fähig sind. Etwa die Hälfte der an der DFN-AAI teilnehmenden Einrichtungen nutzt hierfür die [[de:metadata_local\|lokalen Metadaten]]		- The Identity Provider is trusted enough to be used to access your organization’s own systems \\ Kommentar: ... sofern diese SAML-fähig sind. Etwa die Hälfte der an der DFN-AAI teilnehmenden Einrichtungen nutzt hierfür die [[de:metadata_local\|lokalen Metadaten]]

assurance_sp

Anonymous (anonymous@undisclosed.example.com) — 2024-01-21T12:47:40+00:00

2024/01/21 13:41		aktuell
Zeile 23:		Zeile 23:
	ShibRequestSetting requireSession true		ShibRequestSetting requireSession true
	<RequireAll>		<RequireAll>
		+	Require shib-attr assurance https://refeds.org/assurance/IAP/medium
		+	Require shib-attr assurance https://refeds.org/assurance/ATP/ePA-1m
		+	</RequireAll>
		+	</Location>
		+	</file>
		+
		+	Wie oben, zusätzlich akzeptiert der Service-Provider nur REFEDS Assurance Framework version 2.0.
		+
		+	<file apache /etc/apache2/sites-enabled/sp.uni-beispiel.de.conf>
		+	<Location /protected>
		+	AuthType shibboleth
		+	ShibRequestSetting requireSession true
		+	<RequireAll>
		+	Require shib-attr assurance https://refeds.org/assurance/version/2
	Require shib-attr assurance https://refeds.org/assurance/IAP/medium		Require shib-attr assurance https://refeds.org/assurance/IAP/medium
	Require shib-attr assurance https://refeds.org/assurance/ATP/ePA-1m		Require shib-attr assurance https://refeds.org/assurance/ATP/ePA-1m

attributes_best_practice

Anonymous (anonymous@undisclosed.example.com) — 2022-08-30T07:56:39+00:00

2022/08/30 09:56		aktuell
Zeile 11:		Zeile 11:
	\| <del>''mail''</del> \| nicht zur Identifizierung verwenden! \|		\| <del>''mail''</del> \| nicht zur Identifizierung verwenden! \|
	^ 1.2 Pairwise / targeted ^^		^ 1.2 Pairwise / targeted ^^
-	\| ''urn:oasis:names:tc:SAML:attribute:pairwise-id'' [[de:common_attributes#a17\|Doku]] \| empfohlen - Stored Id! (plus Scope)\|	+	\| ''Pairwise Id (SAML V2.0 Pairwise Subject Identifier)'' [[de:common_attributes#a17\|Doku]] \| empfohlen - Stored Id! (plus Scope)\|
	\| ''eduPersonTargetedID'' [[de:common_attributes#a11\|Doku]] \| deprecated - Wert sollte identisch mit dem Wert pairwise-id sein, der vor dem Scope steht \|		\| ''eduPersonTargetedID'' [[de:common_attributes#a11\|Doku]] \| deprecated - Wert sollte identisch mit dem Wert pairwise-id sein, der vor dem Scope steht \|
	\| ''persistent Id'' (SAML2 Name ID) \| deprecated - Wert sollte identisch mit dem Wert der pairwise-id sein, der vor dem Scope steht \|		\| ''persistent Id'' (SAML2 Name ID) \| deprecated - Wert sollte identisch mit dem Wert der pairwise-id sein, der vor dem Scope steht \|

attributes_transmission

Anonymous (anonymous@undisclosed.example.com) — 2024-11-08T10:27:49+00:00

2021/03/14 14:45		aktuell
Zeile 5:		Zeile 5:
	===== Möglichkeiten auf Service Provider-Seite =====		===== Möglichkeiten auf Service Provider-Seite =====
	- Laut Standard kann ein SP im Authentication Request bestimmte Attribute anfordern. ("The <AuthnRequest> MAY contain an AttributeConsumingServiceIndex XML attribute referencing information about desired or required attributes in [SAMLMeta]. The identity provider MAY ignore this, or send other attributes at its discretion." Quelle: oben verlinktes PDF). Uns ist jedoch noch keine tatsächliche Implementierung dieses Features begegnet.		- Laut Standard kann ein SP im Authentication Request bestimmte Attribute anfordern. ("The <AuthnRequest> MAY contain an AttributeConsumingServiceIndex XML attribute referencing information about desired or required attributes in [SAMLMeta]. The identity provider MAY ignore this, or send other attributes at its discretion." Quelle: oben verlinktes PDF). Uns ist jedoch noch keine tatsächliche Implementierung dieses Features begegnet.
-	- In den SP-Metadaten sollten die gewünschten bzw. erforderlichen Attribute genannt werden. Eine IdP-Konfiguration kann in den [[https://wiki.shibboleth.net/confluence/display/IDP4/AttributeInMetadataConfiguration\|Attribut-Filterregeln]] darauf eingehen, sie darf die Informationen aber auch ignorieren. Geht sie darauf ein, dann werden Attribute nur dann freigegeben, wenn sie in den SP-Metadaten stehen oder auch, wenn sie dort als erforderlich markiert sind. (Die Nutzer*innen können die Attributfreigabe natürlich immer noch ablehnen.)	+	- In den SP-Metadaten sollten die gewünschten bzw. erforderlichen Attribute genannt werden. Eine IdP-Konfiguration kann in den [[https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199501959/AttributeInMetadataConfiguration\|Attribut-Filterregeln]] darauf eingehen, sie darf die Informationen aber auch ignorieren. Geht sie darauf ein, dann werden Attribute nur dann freigegeben, wenn sie in den SP-Metadaten stehen oder auch, wenn sie dort als erforderlich markiert sind. (Die Nutzer*innen können die Attributfreigabe natürlich immer noch ablehnen.)
	- Werden vom IdP keine Attribute übermittelt, dann kann der SP versuchen, eine Attribute Query über die SOAP-Schnittstelle am IdP abzusetzen. Auch dabei werden die Attribut-Filterregeln einbezogen. Das bedeutet, dass bei fehlenden Freigaben auch eine Attribut Query keine Informationen holen kann. (Ab dem IdP 4.x wird die Erlaubnis für Attribute Queries nicht mehr standardmäßig erteilt, sondern muss im entsprechenden SAML-Profil (''conf/relying-party.xml'') angeschaltet werden.		- Werden vom IdP keine Attribute übermittelt, dann kann der SP versuchen, eine Attribute Query über die SOAP-Schnittstelle am IdP abzusetzen. Auch dabei werden die Attribut-Filterregeln einbezogen. Das bedeutet, dass bei fehlenden Freigaben auch eine Attribut Query keine Informationen holen kann. (Ab dem IdP 4.x wird die Erlaubnis für Attribute Queries nicht mehr standardmäßig erteilt, sondern muss im entsprechenden SAML-Profil (''conf/relying-party.xml'') angeschaltet werden.

attribute_authority

Anonymous (anonymous@undisclosed.example.com) — 2025-07-07T07:12:07+00:00

2025/04/28 17:03		aktuell
Zeile 58:		Zeile 58:
	<AttributeDefinition id="eduPersonEntitlement" xsi:type="Simple">		<AttributeDefinition id="eduPersonEntitlement" xsi:type="Simple">
	<InputDataConnector ref="myDatabase" attributeNames="name" />		<InputDataConnector ref="myDatabase" attributeNames="name" />
-	<!-- NB: bei Shibboleth IdP 4.x sind die AttributeEncoder ausgelagert! -->
-	<AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" friendlyName="myEduPersonEntitlement" encodeType="false"/>
	</AttributeDefinition>		</AttributeDefinition>

contact

Anonymous (anonymous@undisclosed.example.com) — 2026-02-17T09:38:06+00:00

2026/02/17 09:54		aktuell
Zeile 6:		Zeile 6:
	\| Telefon:(für vertragliche Fragen) \| +49-30-884299-318 \|		\| Telefon:(für vertragliche Fragen) \| +49-30-884299-318 \|
	\| Fax: \| +49-30-884299-370 \|		\| Fax: \| +49-30-884299-370 \|
-	Hinweis: Die DFN-AAI-Hotline bietet Hilfestellung bei der Installation und Konfiguration der Shibboleth-Software sowie bei allgemeinen Fragen rund um die Föderation. Aufgrund der Vielzahl möglicher Szenarien und Anwendungsfälle kann leider kein direkter Support zu Webanwendungen und IdM-Systemen angeboten werden. Über die [[de:aai:mailinglists\|Mailinglisten]] können sich die Nutzerinnen und Nutzer der DFN-AAI untereinander austauschen.	+	Hinweis: Die DFN-AAI-Hotline bietet Hilfestellung bei der Installation und Konfiguration der Shibboleth-Software sowie bei allgemeinen Fragen rund um die Föderation. Aufgrund der Vielzahl möglicher Szenarien und Anwendungsfälle kann leider kein direkter Support zu Webanwendungen und IdM-Systemen angeboten werden. Über die [[de:aai:mailinglists\|Mailinglisten]] können sich die Nutzer:innen der DFN-AAI untereinander austauschen.

	==== Administrativer Kontakt ====		==== Administrativer Kontakt ====

dataprotection

Anonymous (anonymous@undisclosed.example.com) — 2024-07-08T08:17:21+00:00

2024/07/07 15:45		aktuell
Zeile 8:		Zeile 8:
	* Konsultieren Sie hierzu dendie Datenschutzbeauftragten Ihrer Heimateinrichtung.		* Konsultieren Sie hierzu dendie Datenschutzbeauftragten Ihrer Heimateinrichtung.
	* Außer in Ausnahmefällen (mit dem/der Datenschutzbeauftragten abzustimmen), sollte ein IdP-seitiges User Consent Modul zum Einsatz kommen. Es ermöglicht den Nutzer*innen, die zu übertragenden Attribute und Attributwerte zu kontrollieren und ihre Übertragung ggf. zu unterbinden. Siehe hierzu auch die Seite [[de:shibidp:config-consent-dsgvo\|Beispiel für eine EU-DSGVO-konforme Konfiguration des User Consent Moduls]].		* Außer in Ausnahmefällen (mit dem/der Datenschutzbeauftragten abzustimmen), sollte ein IdP-seitiges User Consent Modul zum Einsatz kommen. Es ermöglicht den Nutzer*innen, die zu übertragenden Attribute und Attributwerte zu kontrollieren und ihre Übertragung ggf. zu unterbinden. Siehe hierzu auch die Seite [[de:shibidp:config-consent-dsgvo\|Beispiel für eine EU-DSGVO-konforme Konfiguration des User Consent Moduls]].
-	* Auch für SPs: Auf europäischer Ebene existiert seit 2013 der im eduGAIN-Kontext entwickelte [[de:geant_coco\|GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA (CoCo)]], 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:shibidp:config-attributes-coco\|Attribut-Konfiguration für Code of Conduct-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]].	+	* Auch für SPs: Auf europäischer Ebene existiert seit 2013 der im eduGAIN-Kontext entwickelte [[de:geant_coco\|GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA (CoCo)]], 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 [[de:entity_attributes\|Entity Attribute]] sowie unter [[de:shibidp:config-attributes-coco\|Attribut-Konfiguration für Code of Conduct-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]].


Zeile 16:		Zeile 16:
	* [[https://refeds.org/category/code-of-conduct/v2\|REFEDS Data Protection Code of Conduct (CoCo v.2)]], siehe auch [[de:shibidp:config-attributes-coco\|Attributfreigabe für Code-of-Conduct-SPs]]		* [[https://refeds.org/category/code-of-conduct/v2\|REFEDS Data Protection Code of Conduct (CoCo v.2)]], siehe auch [[de:shibidp:config-attributes-coco\|Attributfreigabe für Code-of-Conduct-SPs]]
	* M. Mörike, A. Strobel (Forschungsstelle Recht im DFN), Datenschutzrechtliche Analyse das AAI-Verfahrens ([[https://download.aai.dfn.de/praesentationen/betriebstagungen/69/BT69_AAI_DS-AAI-Verfahren_Strobel_Moerike.pdf\|Präsentation auf der 69. Betriebstagung]])		* M. Mörike, A. Strobel (Forschungsstelle Recht im DFN), Datenschutzrechtliche Analyse das AAI-Verfahrens ([[https://download.aai.dfn.de/praesentationen/betriebstagungen/69/BT69_AAI_DS-AAI-Verfahren_Strobel_Moerike.pdf\|Präsentation auf der 69. Betriebstagung]])
-	* J. Köcher, AAI und PKI - Aspekte des Datenschutzes ([[https://www2.dfn.de/fileadmin/5Presse/DFNMitteilungen/DFN_Mitteilungen_72.pdf\|DFN Mitteilungen 72, Juni 2007, Seite 12 ff.]])	+	* J. Köcher, AAI und PKI - Aspekte des Datenschutzes ([[https://download.aai.dfn.de/publikationen/dfn-mitteilungen/DFN-Mitteilungen-72.pdf\|DFN Mitteilungen 72, Juni 2007, Seite 12 ff.]])

	====== Shibboleth und Datenschutz ======		====== Shibboleth und Datenschutz ======

datenschutz_faq

Anonymous (anonymous@undisclosed.example.com) — 2023-03-31T09:42:03+00:00

2023/03/31 11:40		aktuell
Zeile 13:		Zeile 13:
	* Keine Weitergabe von Nutzerdaten, Bewegungsprofilen etc. an Dritte!		* Keine Weitergabe von Nutzerdaten, Bewegungsprofilen etc. an Dritte!
	* Aufbewahrungsfristen beachten!		* Aufbewahrungsfristen beachten!
		+	* Gut sichtbarer Hinweis auf Datenschutzerklärung!

	==== Was gilt es beim Betrieb eines Identity Providers zu berücksichtigen? ====		==== Was gilt es beim Betrieb eines Identity Providers zu berücksichtigen? ====

datenschutz_rollen

Anonymous (anonymous@undisclosed.example.com) — 2025-02-27T09:41:58+00:00

2025/02/27 10:41		aktuell
Zeile 16:		Zeile 16:
	===== Keine Auftragsverarbeitung =====		===== Keine Auftragsverarbeitung =====

-	Wie oben dargestellt verarbeitet der DFN-Verein in seiner Rolle als Föderationsbetreiber keine Daten von Endnnutzer:innen und agiert insofern auch nicht als Verantwortlicher im Sinne der DSGVO. Auch erteilt der DFN-Verein Teilnehmern an der DFN-AAI grundsätzlich keinen Auftrag zur Verarbeitung personenbezogener Daten. Daher werden die Teilnehmer per Vertrag darauf hingewiesen, dass sowohl lizenzrechtliche als auch datenschutzrechtliche Fragen bilateral zwischen Dienstanbieter und Heimateinrichtung geregelt werden müssen. Hierbei ergeben sich in Einzelfällen Szenarien, in denen ein Dienstanbieter als Auftragsverarbeiter für eine Heimateinrichtung agiert. Der DFN-Verein ist in solchen Fällen in keiner Weise vertraglich involviert. Die einige Ausnahme macht derzeit der vom DFN-Verein betriebene [https://doku.tid.dfn.de/de:shibidp:oidc-proxy#hinweise_fuer_dienstanbieter\|OIDC-Proxy], für den der DFN-Verein jeweils eine AVV mit den Betreibern der angeschlossenen Dienste abschließt.	+	Wie oben dargestellt verarbeitet der DFN-Verein in seiner Rolle als Föderationsbetreiber keine Daten von Endnnutzer:innen und agiert insofern auch nicht als Verantwortlicher im Sinne der DSGVO. Auch erteilt der DFN-Verein Teilnehmern an der DFN-AAI grundsätzlich keinen Auftrag zur Verarbeitung personenbezogener Daten. Daher werden die Teilnehmer per Vertrag darauf hingewiesen, dass sowohl lizenzrechtliche als auch datenschutzrechtliche Fragen bilateral zwischen Dienstanbieter und Heimateinrichtung geregelt werden müssen. Hierbei ergeben sich in Einzelfällen Szenarien, in denen ein Dienstanbieter als Auftragsverarbeiter für eine Heimateinrichtung agiert. Der DFN-Verein ist in solchen Fällen in keiner Weise vertraglich involviert. \\
		+	Die einige Ausnahme macht derzeit der vom DFN-Verein betriebene [[https://doku.tid.dfn.de/de:shibidp:oidc-proxy#hinweise_fuer_dienstanbieter\|OIDC-Proxy]], für den der DFN-Verein jeweils eine AVV mit den Betreibern der angeschlossenen Dienste abschließt.

ec_aai-plus

Anonymous (anonymous@undisclosed.example.com) — 2020-04-09T14:49:32+00:00

2026/04/29 13:45	aktuell
Zeile 1:	Zeile 1:
	+	====== Entity Category aai-plus ======
	+	([[de:entity_attributes#dfn-aai\|zurück zur Übersicht]])

	+	<callout type="danger" title="Work in Progress">
	+	Diese Seite ist noch im Aufbau begriffen!
	+	</callout>
	+
	+	Wert: http://aai.dfn.de/category/aai-plus
	+
	+	Beschreibung: Nur verfügbar für Entities, die bestimmten Kriterien entsprechen... FIXME

ec_bwidm-member

Anonymous (anonymous@undisclosed.example.com) — 2020-04-21T12:40:58+00:00

2019/07/18 11:05		aktuell
Zeile 6:		Zeile 6:
	Beschreibung: Nur verfügbar für Einrichtungen, die am [[https://www.bwidm.de\|bwIdM-Verbund]] (Baden-Württemberg) teilnehmen. Informationen zu Teilnahme, technischen Voraussetzungen und Rahmenbedingungen etc. unter https://www.bwidm.de		Beschreibung: Nur verfügbar für Einrichtungen, die am [[https://www.bwidm.de\|bwIdM-Verbund]] (Baden-Württemberg) teilnehmen. Informationen zu Teilnahme, technischen Voraussetzungen und Rahmenbedingungen etc. unter https://www.bwidm.de

		+	{{tag>entity-category entity-attribute}}

eduid

Anonymous (anonymous@undisclosed.example.com) — 2019-08-30T07:37:44+00:00

2019/08/30 09:35		aktuell

entity_categories

Anonymous (anonymous@undisclosed.example.com) — 2025-07-22T15:10:47+00:00

2025/07/09 09:42		aktuell
Zeile 9:		Zeile 9:
	\|[[http://clarin.eu/category/clarin-member\|http://clarin.eu/category/clarin-member]]\|Wird automatisch für alle Service Provider gesetzt, die von [[https://www.clarin.eu\|CLARIN-EU]] betrieben werden.\|		\|[[http://clarin.eu/category/clarin-member\|http://clarin.eu/category/clarin-member]]\|Wird automatisch für alle Service Provider gesetzt, die von [[https://www.clarin.eu\|CLARIN-EU]] betrieben werden.\|
	\|[[http://aai.dfn.de/category/dfn-edu-id\|http://aai.dfn.de/category/dfn-edu-id]] \| Wird vom DFN [[support@edu-id.dfn.de\|edu-ID-Support-Team]] vergeben \|		\|[[http://aai.dfn.de/category/dfn-edu-id\|http://aai.dfn.de/category/dfn-edu-id]] \| Wird vom DFN [[support@edu-id.dfn.de\|edu-ID-Support-Team]] vergeben \|
-	\|[[http://aai.dfn.de/category/fid-licences-member\|http://aai.dfn.de/category/fid-licences-member]] \| Service Provider, über die Lizenzen der [[https://www.fid-lizenzen.de/zusammenarbeit-fid-kfl\|Fachinformationsdienste (FID)]] in Deutschland bereitgestellt werden.\|	+	\|[[http://aai.dfn.de/category/fid-licences-member\|http://aai.dfn.de/category/fid-licences-member]] \| Service Provider, über die Lizenzen der [[https://www.fid-lizenzen.de/zusammenarbeit-fid-kfl\|Fachinformationsdienste (FID)]] in Deutschland bereitgestellt werden. Beitrittsanfragen richten Sie bitte an [[security@gbv.de\|]]\|
	\|[[http://aai.dfn.de/category/heidi-member\|http://aai.dfn.de/category/heidi-member]]\| Verfügbar für Einrichtungen, die an der HeIDI (HEssische IDentity-Management Infrastruktur) Föderation teilnehmen. Informationen finden Sie unter https://heidi-hessen.de \|		\|[[http://aai.dfn.de/category/heidi-member\|http://aai.dfn.de/category/heidi-member]]\| Verfügbar für Einrichtungen, die an der HeIDI (HEssische IDentity-Management Infrastruktur) Föderation teilnehmen. Informationen finden Sie unter https://heidi-hessen.de \|
	\|[[http://aai.dfn.de/category/highmeducation-member\|http://aai.dfn.de/category/highmeducation-member]]\|Verfügbar für Mitglieder des [[https://www.medizininformatik-initiative.de/de/konsortien/highmed\|HiGHmed Konsortiums]] ([[https://highmeducation.pages.gwdg.de/metadata/sp.html\|Doku für Projektpartner]])\|		\|[[http://aai.dfn.de/category/highmeducation-member\|http://aai.dfn.de/category/highmeducation-member]]\|Verfügbar für Mitglieder des [[https://www.medizininformatik-initiative.de/de/konsortien/highmed\|HiGHmed Konsortiums]] ([[https://highmeducation.pages.gwdg.de/metadata/sp.html\|Doku für Projektpartner]])\|

erasmus_faq

Anonymous (anonymous@undisclosed.example.com) — 2024-07-08T08:19:03+00:00

2022/05/24 17:10		aktuell
Zeile 7:		Zeile 7:
	Die Struktur von eduGAIN ist hierarchisch gegliedert:		Die Struktur von eduGAIN ist hierarchisch gegliedert:
	* Die unterste Ebene bilden die einzelne Hochschulen bzw. Forschungseinrichtungen mit ihren Nutzer*innen und ggf. lokalen Diensten.		* Die unterste Ebene bilden die einzelne Hochschulen bzw. Forschungseinrichtungen mit ihren Nutzer*innen und ggf. lokalen Diensten.
-	* Auf der nächsten Ebene sind die meisten Hochschulen und Forsschungseinrichtungen in Deutschland in einer sogenannten Föderation zusammengeschlossen, in der DFN-AAI (AAI: Authentication and Authorization Infrastructure). Die DFN-AAI wird vom DFN-Verein betrieben. Der DFN-Verein (Verein zur Förderung eines Deutschen Forschungsnetzes e.V.) ist das deutsche NREN, was für 'National Research and Education Network' steht. In dieser Funktion versorgt er nicht nur die meisten deutschen Hochschulen und Forschungseinrichtungen mit Internet, sondern bietet neben der DFN-AAI auch weitere Zusatzdienste an wie z.B. [[https://www2.dfn.de/dienstleistungen/eduroam/\|eduroam]], [[https://www.pki.dfn.de\|DFN-PKI]] oder [[https://www.conf.dfn.de\|DFNconf]]. Beim DFN-Verein als Föderationsbetreiber laufen die vertraglichen Absprachen und der Austausch technischer Informationen zusammen, damit das hochschulübergreifende Login funktioniert. Analoge Strukturen existieren in allen EU-Staaten und zahlreichen anderen Ländern.	+	* Auf der nächsten Ebene sind die meisten Hochschulen und Forsschungseinrichtungen in Deutschland in einer sogenannten Föderation zusammengeschlossen, in der DFN-AAI (AAI: Authentication and Authorization Infrastructure). Die DFN-AAI wird vom DFN-Verein betrieben. Der DFN-Verein (Verein zur Förderung eines Deutschen Forschungsnetzes e.V.) ist das deutsche NREN, was für 'National Research and Education Network' steht. In dieser Funktion versorgt er nicht nur die meisten deutschen Hochschulen und Forschungseinrichtungen mit Internet, sondern bietet neben der DFN-AAI auch weitere Zusatzdienste an wie z.B. [[https://www.dfn.de/dienste/security-trust-and-identity-services/eduroam/\|eduroam]], [[https://www.pki.dfn.de\|DFN-PKI]] oder [[https://www.conf.dfn.de\|DFNconf]]. Beim DFN-Verein als Föderationsbetreiber laufen die vertraglichen Absprachen und der Austausch technischer Informationen zusammen, damit das hochschulübergreifende Login funktioniert. Analoge Strukturen existieren in allen EU-Staaten und zahlreichen anderen Ländern.
	* Auf der dritten, der internationalen Ebene, haben sich wiederum die Forschungsnetze bzw. Föderationsbetreiber aus über 70 Ländern zusammengeschlossen, damit das o.g. Verfahren auch international funktioniert. Somit ist es möglich, sich z.B. mit einem deutschen Hochschullogin bei einem Dienst anzumelden, der in einem anderen Land betrieben wird und eigentlich in einer anderen Föderation registriert ist. Dieser Zusammenschluss heißt eduGAIN, also eine Föderation der internationalen Föderationen, eine Interfederation. Deutsche Hochschulen, die einen so genannten Identity Provider in der DFN-AAI betreiben, können mit diesem Identity Provider zusätzlich an eduGAIN teilnehmen (optional).		* Auf der dritten, der internationalen Ebene, haben sich wiederum die Forschungsnetze bzw. Föderationsbetreiber aus über 70 Ländern zusammengeschlossen, damit das o.g. Verfahren auch international funktioniert. Somit ist es möglich, sich z.B. mit einem deutschen Hochschullogin bei einem Dienst anzumelden, der in einem anderen Land betrieben wird und eigentlich in einer anderen Föderation registriert ist. Dieser Zusammenschluss heißt eduGAIN, also eine Föderation der internationalen Föderationen, eine Interfederation. Deutsche Hochschulen, die einen so genannten Identity Provider in der DFN-AAI betreiben, können mit diesem Identity Provider zusätzlich an eduGAIN teilnehmen (optional).

faqs

Anonymous (anonymous@undisclosed.example.com) — 2026-04-28T11:29:54+00:00

2026/04/27 11:45		aktuell
Zeile 18:		Zeile 18:
	* auf der Mailingliste [[https://www.listserv.dfn.de/sympa/info/dfn-aai-users\|dfn-aai-users@listserv.dfn.de]]		* auf der Mailingliste [[https://www.listserv.dfn.de/sympa/info/dfn-aai-users\|dfn-aai-users@listserv.dfn.de]]
	* im AAI-Forum bei der zweimal jährlich stattfindenden [[https://www.dfn.de/news/veranstaltungen/\|Betriebstagung]]		* im AAI-Forum bei der zweimal jährlich stattfindenden [[https://www.dfn.de/news/veranstaltungen/\|Betriebstagung]]
-	* Themen rund um Identity Management werden auch im [[https://www.zki.de/ueber-den-zki/arbeitskreise/arbeitskreis-identity-und-access-management/ \| ZKI AK Identity und Access Management]] diskutiert, der sich ebenfalls zweimal pro Jahr trifft.	+	* Themen rund um Identity Management werden auch im [[https://www.zki.de/unsere-arbeit/arbeitskreise/identity-und-access-management\| ZKI AK Identity und Access Management]] diskutiert, der sich ebenfalls zweimal pro Jahr trifft.
	* [[de:aai:datenschutz_faq\|Datenschutz]] (im Aufbau)		* [[de:aai:datenschutz_faq\|Datenschutz]] (im Aufbau)

identifier

Anonymous (anonymous@undisclosed.example.com) — 2025-01-07T15:11:01+00:00

2025/01/07 15:35		aktuell
Zeile 6:		Zeile 6:
	<datatables paging="false" info="false">		<datatables paging="false" info="false">
	^ Indentifier ^ targeted ^ pseudonym ^ Kommentar (siehe [[de:aai:attributes_best_practice\|Best Practice]]) ^		^ Indentifier ^ targeted ^ pseudonym ^ Kommentar (siehe [[de:aai:attributes_best_practice\|Best Practice]]) ^
-	\|eduPersonTargetedId (ePTID)\| x \| x \|abgekündigt, aber verbreitet; Wert der pairwise-ID ohne Scope\|	+	\|[[de:common_attributes#a11\|eduPersonTargetedId]] (ePTID)\| x \| x \|abgekündigt, aber verbreitet; Wert der pairwise-ID ohne Scope\|
-	\|persistentID (pid)\| x \| x \|abgekündigt, aber verbreitet; Wert der pairwise-ID ohne Scope\|	+	\|[[de:shibidp:config-storage#persistentid\|persistentID]] (pid)\| x \| x \|abgekündigt, aber verbreitet; Wert der pairwise-ID ohne Scope\|
-	\|eduPersonPrincipalName (ePPN)\|\|\|nicht mehr empfohlen\|	+	\|[[de:common_attributes#a07\|eduPersonPrincipalName]] (ePPN)\|\|\|nicht mehr empfohlen\|
-	\|eduPersonUniqueId\|\| x \|nicht mehr empfohlen\|	+	\|[[de:common_attributes#a12\|eduPersonUniqueId]]\|\| x \|nicht mehr empfohlen\|
-	\|SAML Pairwise ID\| x \| x \|löst ePTId und pid ab; Stored Id mit Scope\|	+	\|[[de:common_attributes#a17\|SAML Pairwise ID]]\| x \| x \|löst ePTId und pid ab; Stored Id mit Scope\|
-	\|SAML Subject ID\|\| x \|Unique ID + Scope („non-targeted“); Soll ePPN u. eduPersonUniqueId ablösen\|	+	\|[[de:common_attributes#a16\|SAML Subject ID]]\|\| x \|Unique ID + Scope („non-targeted“); Soll ePPN u. eduPersonUniqueId ablösen\|
	</datatables>		</datatables>

incidentresponse

Anonymous (anonymous@undisclosed.example.com) — 2023-06-06T16:07:53+00:00

2023/06/06 18:07		aktuell
Zeile 71:		Zeile 71:
	===== 3. Sirtfi Compliance für IdPs und SPs in der DFN-AAI =====		===== 3. Sirtfi Compliance für IdPs und SPs in der DFN-AAI =====

-	Teilnehmende Organisationen, die sich offiziell auf die Regeln des Sirfti-Frameworks verpflichten möchten, müssen einige Schritte unternehmen, um in ihren Metadaten das zusätzliche Entity Attribut veröffentlichen zu dürfen. Die Teilnahme ist freiwillig.	+	Teilnehmende Organisationen, die sich offiziell auf die Regeln des Sirfti-Frameworks verpflichten möchten, müssen einige Schritte unternehmen, um in ihren Metadaten das zusätzliche [[de:entity_attributes#sirtfi\|Entity Attribut]] veröffentlichen zu dürfen. Die Teilnahme ist freiwillig.

	==== Definitionen ====		==== Definitionen ====

incident_reporting_template

Anonymous (anonymous@undisclosed.example.com) — 2023-06-06T12:57:20+00:00

2018/10/29 11:40		aktuell
Zeile 1:		Zeile 1:
-	====== Berichtsvorlagn für Security Incident Response in der DFN-AAI ======	+	====== Berichtsvorlagen für Security Incident Response in der DFN-AAI ======

	===== Auszufüllen von der meldenden Einrichtung =====		===== Auszufüllen von der meldenden Einrichtung =====

infos

Anonymous (anonymous@undisclosed.example.com) — 2025-04-22T13:00:58+00:00

2025/04/22 14:37		aktuell
Zeile 23:		Zeile 23:
	* [[https://github.internet2.edu/docker/shib-idp\|TIER / Internet2 Image]] (Rockylinux, Amazon Corretto)		* [[https://github.internet2.edu/docker/shib-idp\|TIER / Internet2 Image]] (Rockylinux, Amazon Corretto)
	* [[https://github.com/iay/shibboleth-idp-docker\|Ian Young]] (Amazon Linux, Amazon Corretto)		* [[https://github.com/iay/shibboleth-idp-docker\|Ian Young]] (Amazon Linux, Amazon Corretto)
		+	Vielen Dank an Manuel Oellers für die Bereitstellung der Link-Sammlung.

mailinglists

Anonymous (anonymous@undisclosed.example.com) — 2021-12-13T10:20:47+00:00

2021/02/15 13:15		aktuell
Zeile 7:		Zeile 7:
	Wir empfehlen dringend, zumindest die Mailingliste [[https://www.listserv.dfn.de/sympa/info/dfn-aai-announce\|dfn-aai-announce@listserv.dfn.de]] zu abonnieren, damit wir Sie zeitnah über Sicherheitsprobleme, Policy-Änderungen und sonstige technische und organisatorische Maßnahmen informieren können.		Wir empfehlen dringend, zumindest die Mailingliste [[https://www.listserv.dfn.de/sympa/info/dfn-aai-announce\|dfn-aai-announce@listserv.dfn.de]] zu abonnieren, damit wir Sie zeitnah über Sicherheitsprobleme, Policy-Änderungen und sonstige technische und organisatorische Maßnahmen informieren können.
	===== Shibboleth =====		===== Shibboleth =====
-	Siehe unter https://wiki.shibboleth.net/confluence/display/WEB/Mailing+Lists	+	Siehe unter https://www.shibboleth.net/support/
	* Announce, announce@shibboleth.net		* Announce, announce@shibboleth.net
	* Users, users@shibboleth.net		* Users, users@shibboleth.net
	* Dev, dev@shibboleth.net		* Dev, dev@shibboleth.net
	Wir empfehlen die Teilnahme zumindest an [[announce-subscribe@shibboleth.net\|announce@shibboleth.net]], um über neue Versionen und Security-Updates informiert zu bleiben.		Wir empfehlen die Teilnahme zumindest an [[announce-subscribe@shibboleth.net\|announce@shibboleth.net]], um über neue Versionen und Security-Updates informiert zu bleiben.

mdq

Anonymous (anonymous@undisclosed.example.com) — 2024-02-02T08:43:45+00:00

2023/01/12 17:26		aktuell
Zeile 20:		Zeile 20:

	Zertifikat zur Überprüfung der Signatur der DFN-AAI MDQ Metadaten (PEM-Format) \\		Zertifikat zur Überprüfung der Signatur der DFN-AAI MDQ Metadaten (PEM-Format) \\
-	SHA256 Fingerprint: 73:5B:9E:76:8A:A6:33:73:4D:3E:C6:D2:1E:98:B3:D9:03:74:B9:87:16:52:16:53:32:26:9A:B2:55:FC:CA:D2 \\	+	SHA256 Fingerprint: 75:18:98:F6:E8:23:21:E8:B1:DC:71:6B:D0:AB:50:F0:C2:DB:9D:CE:4B:2B:A1:88:B1:42:DB:99:13:DB:0D:E9 \\
	https://www.aai.dfn.de/metadata/dfn-aai-mdq.pem		https://www.aai.dfn.de/metadata/dfn-aai-mdq.pem

mfa_mit_passwd_spnego_first

Anonymous (anonymous@undisclosed.example.com) — 2024-01-10T20:08:55+00:00

2024/01/01 17:20		aktuell
Zeile 1:		Zeile 1:
	====== MFA mit fudiscr und wahlweise Password/SPNEGO als erstem Faktor ======		====== MFA mit fudiscr und wahlweise Password/SPNEGO als erstem Faktor ======
-	([[user:hofmann_fu-berlin.de\|zurück zur fudiscr-Seite]])	+	([[de:shibidp:plugin-fudiscr\|zurück zur fudiscr-Seite]])

	<callout type="danger" title="Wichtiger Hinweis">		<callout type="danger" title="Wichtiger Hinweis">

oid

Anonymous (anonymous@undisclosed.example.com) — 2024-11-27T12:38:25+00:00

2024/11/27 11:20		aktuell
Zeile 1:		Zeile 1:
	====== Object Identifier DFN-AAI ======		====== Object Identifier DFN-AAI ======

-	Ein [[https://de.wikipedia.org/wiki/Object_Identifier\|Object Identifier (OID)]] ist ein weltweit eindeutiger Bezeichner für ein Informationsobjekt. OIDs sind aus Nummern bestehende Zeichenfolgen, die in einem hierarchischen Nummernraum organisiert sind. OIDs können für Objekte verschiedenster Art eingesetzt werden. Im DFN-Verein werden Object Identifier für die DFN-PKI und die DFN-AAI genutzt.	+	Ein [[https://de.wikipedia.org/wiki/Object_Identifier\|Object Identifier (OID)]] ist ein weltweit eindeutiger Bezeichner für ein Informationsobjekt. OIDs sind aus Nummern bestehende Zeichenfolgen, die in einem hierarchischen Nummernraum organisiert sind. OIDs können für Objekte verschiedenster Art eingesetzt werden. Im DFN-Verein werden Object Identifier für die [[de:dfnpki:oid\|DFN-PKI]] und die DFN-AAI genutzt.

	Dem DFN-Verein wurde von der IANA (Internet Assigned Numbers Authority) die "Private Enterprise Number" 22177 zugewiesen.		Dem DFN-Verein wurde von der IANA (Internet Assigned Numbers Authority) die "Private Enterprise Number" 22177 zugewiesen.

oidc

Anonymous (anonymous@undisclosed.example.com) — 2026-04-20T15:15:40+00:00

2025/09/11 10:44		aktuell
Zeile 10:		Zeile 10:
	* [[..:functionaltest_oidc_op\|Funktionstest]]		* [[..:functionaltest_oidc_op\|Funktionstest]]

-	Shib IdP als OIDC-Proxy****	+	Shib IdP als OpenID Provider (OP)****

-	* Dokumentation zur Nutzung und Konfiguration eines Shibboleth IdP als OIDC-Proxy	+	* Dokumentation zur Nutzung und Konfiguration eines Shibboleth IdP als OpenID Provider
	* [[..:shibidp:config-extensions-oidc\|Shibboleth IdP als OpenID Connect Provider]]		* [[..:shibidp:config-extensions-oidc\|Shibboleth IdP als OpenID Connect Provider]]

oidc_230329

Anonymous (anonymous@undisclosed.example.com) — 2023-04-13T10:47:43+00:00

2023/04/13 12:42		aktuell
Zeile 12:		Zeile 12:
	* Clients, die das nicht können: shared Secret müsste außerhalb der MDV verwaltet und ausgetauscht werden		* Clients, die das nicht können: shared Secret müsste außerhalb der MDV verwaltet und ausgetauscht werden
	* Wie könnte die MDV die Verteilung der shared Secrets ermöglichen/unterstützen?		* Wie könnte die MDV die Verteilung der shared Secrets ermöglichen/unterstützen?
-	* Single-Page Applications unterstützen nicht den Client Secret-Mechanismus, sondern arbeiten über PKCE	+	* Single Page Applications unterstützen nicht den Client Secret-Mechanismus, sondern arbeiten über PKCE
	* Gefühlt die Hälfte aller OIDC-Clients unterstützt ausschließlich PKCE		* Gefühlt die Hälfte aller OIDC-Clients unterstützt ausschließlich PKCE
	* Idee: Shared Secrets mit public Keys der IdPs verschlüsseln?		* Idee: Shared Secrets mit public Keys der IdPs verschlüsseln?
Zeile 19:		Zeile 19:

	Early Adopter - welche Anwendungen kommen überhaupt für eine Anbindung an die DFN-AAI in Frage?		Early Adopter - welche Anwendungen kommen überhaupt für eine Anbindung an die DFN-AAI in Frage?
-	* Beispiel Helmholtz AAI?	+	* Beispiele aus Helmholtz AAI oder GWDG?
-	* Beispiel GWDG?	+

portfolio

Anonymous (anonymous@undisclosed.example.com) — 2026-04-28T11:30:52+00:00

2026/04/23 14:24		aktuell
Zeile 19:		Zeile 19:
	Einbeziehung der Nutzerschaft in die Gestaltung und Weiterentwicklung des Dienstes		Einbeziehung der Nutzerschaft in die Gestaltung und Weiterentwicklung des Dienstes
	* AAI-Forum im Rahmen der [[https://www.dfn.de/news/veranstaltungen/\|DFN-Betriebstagung]]		* AAI-Forum im Rahmen der [[https://www.dfn.de/news/veranstaltungen/\|DFN-Betriebstagung]]
-	* Mitarbeit im [[https://www.zki.de/ueber-den-zki/arbeitskreise/arbeitskreis-identity-und-access-management/\|ZKI Arbeitskreis Identity und Access Management]]	+	* Mitarbeit im [[https://www.zki.de/unsere-arbeit/arbeitskreise/identity-und-access-management\|ZKI Arbeitskreis Identity und Access Management]]
	* Themenspezifische Ad-hoc Arbeitsgruppen		* Themenspezifische Ad-hoc Arbeitsgruppen
	Weiterentwicklung des Dienstes auf technischer, organisatorischer und rechtlicher Ebene:		Weiterentwicklung des Dienstes auf technischer, organisatorischer und rechtlicher Ebene:

refeds_authn_profiles_idp

Anonymous (anonymous@undisclosed.example.com) — 2022-02-08T16:18:02+00:00

2022/02/08 17:13		aktuell
Zeile 23:		Zeile 23:

	Falls die MFA-Prozesse und -Policies den Anforderungen des REFEDS Multi-Factor Authentication Profiles genügen:		Falls die MFA-Prozesse und -Policies den Anforderungen des REFEDS Multi-Factor Authentication Profiles genügen:
-	* The authentication of the user’s current session used a combination of at least two of the four distinct types of factors defined in ITU-T X.1254: Entity authentication assurance framework, section 3.1.3, authentication factor (something you know, something you have, something you are, something you do) [4].	+	* The authentication of the user’s current session used a combination of at least two of the four distinct types of factors defined in ITU-T X.1254: Entity authentication assurance framework, section 3.1.3, authentication factor (something you know, something you have, something you are, something you do).
	* The factors used are independent, in that access to one factor does not by itself grant access to other factors.		* The factors used are independent, in that access to one factor does not by itself grant access to other factors.
	* The combination of the factors mitigates single-factor only risks related to non-real-time attacks such as phishing, offline cracking, online guessing and theft of a (single) factor.		* The combination of the factors mitigates single-factor only risks related to non-real-time attacks such as phishing, offline cracking, online guessing and theft of a (single) factor.

refeds_authn_profiles_sp

Anonymous (anonymous@undisclosed.example.com) — 2022-02-08T15:41:22+00:00

2022/02/08 16:40		aktuell
Zeile 9:		Zeile 9:
	===== Single Factor Authentication Profile =====		===== Single Factor Authentication Profile =====
	* Spezifikation: https://refeds.org/profile/sfa		* Spezifikation: https://refeds.org/profile/sfa
-	* [[https://wiki.refeds.org/display/PRO/SFA+Profile+FAQ\|FAQ im REFEDS Wiki]]	+	* FAQ im REFEDS Wiki: https://wiki.refeds.org/display/PRO/SFA+Profile+FAQ

	===== Multi-Factor Authentication Profile =====		===== Multi-Factor Authentication Profile =====

selfsigned_certs

Anonymous (anonymous@undisclosed.example.com) — 2026-02-18T10:15:20+00:00

2026/02/18 11:13		aktuell
Zeile 3:		Zeile 3:
	Erstellen Sie eine Datei namens `selfsigned-cert.cnf` mit folgendem Inhalt und ersetzen Sie `yourhost.example.org` durch Ihren Hostnamen:		Erstellen Sie eine Datei namens `selfsigned-cert.cnf` mit folgendem Inhalt und ersetzen Sie `yourhost.example.org` durch Ihren Hostnamen:

-	# cat selfsigned-cert.cnf
	[req]		[req]
	default_bits=3072		default_bits=3072

training

Anonymous (anonymous@undisclosed.example.com) — 2026-01-28T13:17:57+00:00

2025/03/12 16:20		aktuell
Zeile 1:		Zeile 1:
	====== Schulungsmaterialien ======		====== Schulungsmaterialien ======

-	===== Einsteiger-Workshop IdP, März 2025 =====	+	===== Einsteiger-Workshop IdP, 2025 =====

-	* [[https://download.aai.dfn.de/ws/idp2025/\|Link zu den Workshop-Unterlagen]]	+	* [[https://download.aai.dfn.de/ws/2025_idp_einsteiger/\|Link zu den Workshop-Unterlagen]]
	* Inhalt:		* Inhalt:
	* Grundlagen Föderation, Metadaten & Attribute		* Grundlagen Föderation, Metadaten & Attribute

2024/11/28 10:19		aktuell
Zeile 5:		Zeile 5:
	Lesen Sie bitte die aktuelle Version der [[https://refeds.org/assurance\|Spezifikation]]! \\ Bei Fragen wenden Sie sich bitte an das [[hotline@aai.dfn.de\|DFN-AAI Team]].		Lesen Sie bitte die aktuelle Version der [[https://refeds.org/assurance\|Spezifikation]]! \\ Bei Fragen wenden Sie sich bitte an das [[hotline@aai.dfn.de\|DFN-AAI Team]].

-	Um als Identity Provider bzw. Heimateinrichtung grundsätzliche Konformität mit dem REFEDS Assurance Framework zu signalisieren und entsprechende Attributwerte zu übertragen, müssen vier sog. Conformance Criteria erfüllt sein:	+	Um als Identity Provider bzw. Heimateinrichtung grundsätzliche Konformität mit dem REFEDS Assurance Framework zu signalisieren und entsprechende Attributwerte zu übertragen, müssen die sog. Conformance Criteria erfüllt sein:
	- The Identity Provider is operated with organizational-level authority \\ Kommentar: IdPs müssen auch vertragstechnisch im Namen der jeweiligen Einrichtung betrieben werden, einzelne Fakultäten oder Universitäts-Institute kommen hierfür nicht in Frage		- The Identity Provider is operated with organizational-level authority \\ Kommentar: IdPs müssen auch vertragstechnisch im Namen der jeweiligen Einrichtung betrieben werden, einzelne Fakultäten oder Universitäts-Institute kommen hierfür nicht in Frage
	- The Identity Provider is trusted enough to be used to access your organization’s own systems \\ Kommentar: ... sofern diese SAML-fähig sind. Etwa die Hälfte der an der DFN-AAI teilnehmenden Einrichtungen nutzt hierfür die [[de:metadata_local\|lokalen Metadaten]]		- The Identity Provider is trusted enough to be used to access your organization’s own systems \\ Kommentar: ... sofern diese SAML-fähig sind. Etwa die Hälfte der an der DFN-AAI teilnehmenden Einrichtungen nutzt hierfür die [[de:metadata_local\|lokalen Metadaten]]

2022/08/30 09:56		aktuell
Zeile 11:		Zeile 11:
	\| <del>''mail''</del> \| nicht zur Identifizierung verwenden! \|		\| <del>''mail''</del> \| nicht zur Identifizierung verwenden! \|
	^ 1.2 Pairwise / targeted ^^		^ 1.2 Pairwise / targeted ^^
-	\| ''urn:oasis:names:tc:SAML:attribute:pairwise-id'' [[de:common_attributes#a17\|Doku]] \| empfohlen - Stored Id! (plus Scope)\|	+	\| ''Pairwise Id (SAML V2.0 Pairwise Subject Identifier)'' [[de:common_attributes#a17\|Doku]] \| empfohlen - Stored Id! (plus Scope)\|
	\| ''eduPersonTargetedID'' [[de:common_attributes#a11\|Doku]] \| deprecated - Wert sollte identisch mit dem Wert pairwise-id sein, der vor dem Scope steht \|		\| ''eduPersonTargetedID'' [[de:common_attributes#a11\|Doku]] \| deprecated - Wert sollte identisch mit dem Wert pairwise-id sein, der vor dem Scope steht \|
	\| ''persistent Id'' (SAML2 Name ID) \| deprecated - Wert sollte identisch mit dem Wert der pairwise-id sein, der vor dem Scope steht \|		\| ''persistent Id'' (SAML2 Name ID) \| deprecated - Wert sollte identisch mit dem Wert der pairwise-id sein, der vor dem Scope steht \|

2024/07/07 15:45		aktuell
Zeile 8:		Zeile 8:
	* Konsultieren Sie hierzu dendie Datenschutzbeauftragten Ihrer Heimateinrichtung.		* Konsultieren Sie hierzu dendie Datenschutzbeauftragten Ihrer Heimateinrichtung.
	* Außer in Ausnahmefällen (mit dem/der Datenschutzbeauftragten abzustimmen), sollte ein IdP-seitiges User Consent Modul zum Einsatz kommen. Es ermöglicht den Nutzer*innen, die zu übertragenden Attribute und Attributwerte zu kontrollieren und ihre Übertragung ggf. zu unterbinden. Siehe hierzu auch die Seite [[de:shibidp:config-consent-dsgvo\|Beispiel für eine EU-DSGVO-konforme Konfiguration des User Consent Moduls]].		* Außer in Ausnahmefällen (mit dem/der Datenschutzbeauftragten abzustimmen), sollte ein IdP-seitiges User Consent Modul zum Einsatz kommen. Es ermöglicht den Nutzer*innen, die zu übertragenden Attribute und Attributwerte zu kontrollieren und ihre Übertragung ggf. zu unterbinden. Siehe hierzu auch die Seite [[de:shibidp:config-consent-dsgvo\|Beispiel für eine EU-DSGVO-konforme Konfiguration des User Consent Moduls]].
-	* Auch für SPs: Auf europäischer Ebene existiert seit 2013 der im eduGAIN-Kontext entwickelte [[de:geant_coco\|GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA (CoCo)]], 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:shibidp:config-attributes-coco\|Attribut-Konfiguration für Code of Conduct-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]].	+	* Auch für SPs: Auf europäischer Ebene existiert seit 2013 der im eduGAIN-Kontext entwickelte [[de:geant_coco\|GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA (CoCo)]], 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 [[de:entity_attributes\|Entity Attribute]] sowie unter [[de:shibidp:config-attributes-coco\|Attribut-Konfiguration für Code of Conduct-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]].


Zeile 16:		Zeile 16:
	* [[https://refeds.org/category/code-of-conduct/v2\|REFEDS Data Protection Code of Conduct (CoCo v.2)]], siehe auch [[de:shibidp:config-attributes-coco\|Attributfreigabe für Code-of-Conduct-SPs]]		* [[https://refeds.org/category/code-of-conduct/v2\|REFEDS Data Protection Code of Conduct (CoCo v.2)]], siehe auch [[de:shibidp:config-attributes-coco\|Attributfreigabe für Code-of-Conduct-SPs]]
	* M. Mörike, A. Strobel (Forschungsstelle Recht im DFN), Datenschutzrechtliche Analyse das AAI-Verfahrens ([[https://download.aai.dfn.de/praesentationen/betriebstagungen/69/BT69_AAI_DS-AAI-Verfahren_Strobel_Moerike.pdf\|Präsentation auf der 69. Betriebstagung]])		* M. Mörike, A. Strobel (Forschungsstelle Recht im DFN), Datenschutzrechtliche Analyse das AAI-Verfahrens ([[https://download.aai.dfn.de/praesentationen/betriebstagungen/69/BT69_AAI_DS-AAI-Verfahren_Strobel_Moerike.pdf\|Präsentation auf der 69. Betriebstagung]])
-	* J. Köcher, AAI und PKI - Aspekte des Datenschutzes ([[https://www2.dfn.de/fileadmin/5Presse/DFNMitteilungen/DFN_Mitteilungen_72.pdf\|DFN Mitteilungen 72, Juni 2007, Seite 12 ff.]])	+	* J. Köcher, AAI und PKI - Aspekte des Datenschutzes ([[https://download.aai.dfn.de/publikationen/dfn-mitteilungen/DFN-Mitteilungen-72.pdf\|DFN Mitteilungen 72, Juni 2007, Seite 12 ff.]])

	====== Shibboleth und Datenschutz ======		====== Shibboleth und Datenschutz ======

2025/07/09 09:42		aktuell
Zeile 9:		Zeile 9:
	\|[[http://clarin.eu/category/clarin-member\|http://clarin.eu/category/clarin-member]]\|Wird automatisch für alle Service Provider gesetzt, die von [[https://www.clarin.eu\|CLARIN-EU]] betrieben werden.\|		\|[[http://clarin.eu/category/clarin-member\|http://clarin.eu/category/clarin-member]]\|Wird automatisch für alle Service Provider gesetzt, die von [[https://www.clarin.eu\|CLARIN-EU]] betrieben werden.\|
	\|[[http://aai.dfn.de/category/dfn-edu-id\|http://aai.dfn.de/category/dfn-edu-id]] \| Wird vom DFN [[support@edu-id.dfn.de\|edu-ID-Support-Team]] vergeben \|		\|[[http://aai.dfn.de/category/dfn-edu-id\|http://aai.dfn.de/category/dfn-edu-id]] \| Wird vom DFN [[support@edu-id.dfn.de\|edu-ID-Support-Team]] vergeben \|
-	\|[[http://aai.dfn.de/category/fid-licences-member\|http://aai.dfn.de/category/fid-licences-member]] \| Service Provider, über die Lizenzen der [[https://www.fid-lizenzen.de/zusammenarbeit-fid-kfl\|Fachinformationsdienste (FID)]] in Deutschland bereitgestellt werden.\|	+	\|[[http://aai.dfn.de/category/fid-licences-member\|http://aai.dfn.de/category/fid-licences-member]] \| Service Provider, über die Lizenzen der [[https://www.fid-lizenzen.de/zusammenarbeit-fid-kfl\|Fachinformationsdienste (FID)]] in Deutschland bereitgestellt werden. Beitrittsanfragen richten Sie bitte an [[security@gbv.de\|]]\|
	\|[[http://aai.dfn.de/category/heidi-member\|http://aai.dfn.de/category/heidi-member]]\| Verfügbar für Einrichtungen, die an der HeIDI (HEssische IDentity-Management Infrastruktur) Föderation teilnehmen. Informationen finden Sie unter https://heidi-hessen.de \|		\|[[http://aai.dfn.de/category/heidi-member\|http://aai.dfn.de/category/heidi-member]]\| Verfügbar für Einrichtungen, die an der HeIDI (HEssische IDentity-Management Infrastruktur) Föderation teilnehmen. Informationen finden Sie unter https://heidi-hessen.de \|
	\|[[http://aai.dfn.de/category/highmeducation-member\|http://aai.dfn.de/category/highmeducation-member]]\|Verfügbar für Mitglieder des [[https://www.medizininformatik-initiative.de/de/konsortien/highmed\|HiGHmed Konsortiums]] ([[https://highmeducation.pages.gwdg.de/metadata/sp.html\|Doku für Projektpartner]])\|		\|[[http://aai.dfn.de/category/highmeducation-member\|http://aai.dfn.de/category/highmeducation-member]]\|Verfügbar für Mitglieder des [[https://www.medizininformatik-initiative.de/de/konsortien/highmed\|HiGHmed Konsortiums]] ([[https://highmeducation.pages.gwdg.de/metadata/sp.html\|Doku für Projektpartner]])\|

2026/04/27 11:45		aktuell
Zeile 18:		Zeile 18:
	* auf der Mailingliste [[https://www.listserv.dfn.de/sympa/info/dfn-aai-users\|dfn-aai-users@listserv.dfn.de]]		* auf der Mailingliste [[https://www.listserv.dfn.de/sympa/info/dfn-aai-users\|dfn-aai-users@listserv.dfn.de]]
	* im AAI-Forum bei der zweimal jährlich stattfindenden [[https://www.dfn.de/news/veranstaltungen/\|Betriebstagung]]		* im AAI-Forum bei der zweimal jährlich stattfindenden [[https://www.dfn.de/news/veranstaltungen/\|Betriebstagung]]
-	* Themen rund um Identity Management werden auch im [[https://www.zki.de/ueber-den-zki/arbeitskreise/arbeitskreis-identity-und-access-management/ \| ZKI AK Identity und Access Management]] diskutiert, der sich ebenfalls zweimal pro Jahr trifft.	+	* Themen rund um Identity Management werden auch im [[https://www.zki.de/unsere-arbeit/arbeitskreise/identity-und-access-management\| ZKI AK Identity und Access Management]] diskutiert, der sich ebenfalls zweimal pro Jahr trifft.
	* [[de:aai:datenschutz_faq\|Datenschutz]] (im Aufbau)		* [[de:aai:datenschutz_faq\|Datenschutz]] (im Aufbau)