Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:entity_attributes [2020/01/27 15:27]
Silke Meyer [Sirtfi (Security Incident Response Trust Framework for Federated Identity)]
de:entity_attributes [2020/05/13 15:58] (aktuell)
Silke Meyer [Research and Scholarship]
Zeile 1: Zeile 1:
-~~NOTOC~~ +====== Entity ​Attributes ​====== 
-====== Entity ​Attribute ​====== +<callout color="#​ff9900"​ title="​Entity Attributes?">​ 
-{{INLINETOC 2}} +Bei Entity Attributen handelt es sich um eine [[https://​wiki.oasis-open.org/​security/​SAML2MetadataAttr|Erweiterung der SAML2-Metadaten]]mit der IdPs, Attribute Authorities ​oder SPs zu Gruppen zusammengefasst werden können. Systeme mit gemeinsamen Merkmalen, z.B. einer Projektzugehörigkeit, ​werden mit Entity Attributen ​in den Metadaten ​markiertDie Attributnamen und -werte können dann zum Filtern verwendet werden: IdP-seitig ​ist das interessant,​ um Attributfreigaben ​für SP-Gruppen ​zu vereinheitlichen ​oder um in der Relying Party-Konfiguration Profile ​zu aktivieren. SP-seitig ​können damit Metadaten gefiltert werden, um zugriffsberechtigte IdPs festzumachen. 
-Bei Entity Attributen handelt es sich um eine Erweiterung ​(Extension) ​der SAML2-Metadaten, ​die es ermöglicht,​ Entities (IdPs, Attribute AuthoritiesSPs)die bestimmte Merkmale teilen (z.B. Projektzugehörigkeit)mittels solcher Attribute ​in den Metadaten ​zu markieren und auf diese Weise zu Gruppen zusammenzufassenAnhand der Attributnamen und -Werte lassen sich sowohl Metadaten filtern (insbes. SP-seitig) als auch Attributfreigaben ​an Gruppen ​von SPs definieren ​oder in der //Relying Party// Konfiguration ​bestimmte ​Profile aktivieren ​(IdP-seitig) - siehe [[#​referenzen_shibboleth_wiki|unten]] sowie die Beispiele unter [[:​de:​shibidp3attrfilter|Attribut-Konfiguration]].+</​callout>​
  
-Der betreffende Standard ist hier dokumentiert:​ [[https://​wiki.oasis-open.org/​security/​SAML2MetadataAttr|SAML V2.0 Metadata Extension for Entity Attributes]]+===== Verlässlichkeitsklasse des IdP =====
  
-===== Beispiele ===== 
- 
-==== Verlässlichkeitsklasse des IdP ==== 
 Über dieses Entity Attribut wird die [[de:​degrees_of_reliance|Verlässlichkeitsklasse]] des Identity Providers angezeigt. Über dieses Entity Attribut wird die [[de:​degrees_of_reliance|Verlässlichkeitsklasse]] des Identity Providers angezeigt.
 +
 <file xml dfn-aai-idp-metadata.xml>​ <file xml dfn-aai-idp-metadata.xml>​
   <​md:​EntityDescriptor entityID="​https://​idp.scc.kit.edu/​idp/​shibboleth">​   <​md:​EntityDescriptor entityID="​https://​idp.scc.kit.edu/​idp/​shibboleth">​
Zeile 25: Zeile 23:
     </​md:​Extensions>​     </​md:​Extensions>​
 </​file>​ </​file>​
-==== Sirtfi ​(Security Incident Response Trust Framework for Federated Identity) ==== + 
-Dieses Entity Attribut bezeugt die Bereitschaft und die Fähigkeit des jeweiligen ​IdP-, AA- oder SP-Betreibers,​ die Anforderungen des Sirtfi Frameworks einzuhalten und bei Sicherheitsvorfällen die Gegenstellen zeitnah zu informieren. Siehe hierzu [[https://​wiki.refeds.org/​display/​SIRTFI/​SIRTFI+Home|https://​wiki.refeds.org/​display/​SIRTFI/​SIRTFI+Home]] und hier im Wiki unter [[de:​aai:​incidentresponse#​sirtfi_compliance_fuer_idps_und_sps_in_der_dfn-aai|Incident Response]]. **Als formales Kriterium muss in den Metadaten ein Security Kontakt benannt sein (keine persönliche E-Mail-Adresse).** Um sicherzustellen,​ dass die Anforderungen bezüglich der Betriebssicherheit [OS] eingehalten werden, prüft das Team der DFN-AAI zwei technische Kriterien, bevor die entsprechende Checkbox freigegeben wird:  +===== Sirtfi ​===== 
-  - Es wird vorausgesetzt, dass Sirtfi-konforme Einrichtungen die jeweils aktuellste Software-Version für den IdP bzw. SP einsetzen + 
-  - Außerdem muss die SSL-Konfiguration des betreffenden ​Webservers ​aktuellen ​Best Practices ​entsprechen. ​(Derzeit ​ziehen wir den Servertest von [[https://​www.ssllabs.com/​|ssllabs.com]] ​zur Prüfung ​heran. ​**Aktueller Hinweis:** Ab Ende Januar 2020 vergibt SSLLabs [[https://​blog.qualys.com/​ssllabs/​2018/​11/​19/​grade-change-for-tls-1-0-and-tls-1-1-protocols|keine A-Bewertung mehr für Webserver, die noch TLS 1.0 und TLS 1.1 unterstützen]]. Bitte aktualisieren Sie ggf. Ihre Konfiguration bis zum **31.03.2020**,​ um das Sirtfi-Attribut weiterhin zu tragen.)+<callout color="#​ff9900"​ title="​Sirtfi">​ 
 +Dieses seltsame Wort wird "​certify"​ ausgesprochen. Es steht für "Security Incident Response Trust Framework for Federated Identity"​. ​Dieses Entity Attribut bezeugt die Bereitschaft und Fähigkeit des IdP-, AA- oder SP-Betreibers,​ die Anforderungen des Sirtfi Frameworks einzuhalten und bei Sicherheitsvorfällen die Gegenstellen zeitnah zu informieren. Siehe hierzu [[https://​wiki.refeds.org/​display/​SIRTFI/​SIRTFI+Home|die REFEDS-Website]] und unsere Dokumentation zu [[de:​aai:​incidentresponse#​sirtfi_compliance_fuer_idps_und_sps_in_der_dfn-aai|Sirtfi Compliance in der DFN-AAI]]. 
 +</​callout>​ 
 + 
 +Das Sirtfi Entity Attribut darf nur unter den im Framework festgelegten Bedingungen geführt werden. Wir prüfen folgende formale und technische Kriterien, bevor wir die entsprechende Checkbox freigeben:​ 
 +  - In den Metadaten ​muss ein Security-Kontakt benannt sein. Dabei muss es sich um eine Funktionsadresse handeln, ​keine persönliche E-Mail-Adresse. 
 +  - Wir setzen voraus, dass Sirtfi-konforme Einrichtungen die jeweils aktuellste Software-Version für den IdP bzw. SP einsetzen. 
 +  - Die SSL-Konfiguration des Webservers ​muss aktueller ​Best Practice ​entsprechen. ​Dazu ziehen wir den Servertest von [[https://​www.ssllabs.com/​|ssllabs.com]] heran. ​ 
 Zu den Maßnahmen und Prozeduren im Falle eines Sicherheitsvorfalls siehe unter [[de:​aai:​incidentresponse|Incident Response]]. Zu den Maßnahmen und Prozeduren im Falle eines Sicherheitsvorfalls siehe unter [[de:​aai:​incidentresponse|Incident Response]].
 +
 <file xml dfn-aai-edugain+sp-metadata.xml>​ <file xml dfn-aai-edugain+sp-metadata.xml>​
   <​md:​EntityDescriptor entityID="​https://​cern.ch/​login"​ xsi:​schemaLocation="​urn:​oasis:​names:​tc:​SAML:​2.0:​metadata saml-schema-metadata-2.0.xsd urn:​mace:​shibboleth:​metadata:​1.0 shibboleth-metadata-1.0.xsd http://​www.w3.org/​2000/​09/​xmldsig#​ xmldsig-core-schema.xsd">​   <​md:​EntityDescriptor entityID="​https://​cern.ch/​login"​ xsi:​schemaLocation="​urn:​oasis:​names:​tc:​SAML:​2.0:​metadata saml-schema-metadata-2.0.xsd urn:​mace:​shibboleth:​metadata:​1.0 shibboleth-metadata-1.0.xsd http://​www.w3.org/​2000/​09/​xmldsig#​ xmldsig-core-schema.xsd">​
Zeile 46: Zeile 53:
 </​file>​ </​file>​
  
-==== eduGAIN Registration Authority ​====+====== ​Entity Categories ​====== 
 +Eine Entity Category ist genau genommen auch ein Entity Attribut. Service Provider nutzen Entity Categories, um über die Metadaten zu kommunizieren,​ dass sie bestimmte Anforderungen stellen und/oder erfüllen. Ein SP kann beliebig viele Entity Categories setzen.
  
-Hier werden in den eduGAIN-Metadaten die //​Registration Authorities//​ (=Föderationen) angegeben, über die die jeweilige ​Entity ​in eduGAIN registriert wurde (für Attributfreigabe ​ab IdP 3.x obsolet, ​siehe [[https://​wiki.shibboleth.net/​confluence/display/IDP30/RegistrationAuthorityConfiguration|Doku im Shibboleth Wiki]]):+IdP-seitig können als "​Gegenstücke"​ **Entity ​Category Support**-Attribute definiert werden. Damit signalisieren IdPs, dass sie für SPs der Entity Category eine Attributfreigabe ​erteilenZu diesem Themenkomplex ​siehe [[https://​wiki.refeds.org/display/ENT/Entity-Categories+Home|https://​wiki.refeds.org/​display/​ENT/​Entity-Categories+Home]].
  
-<file xml dfn-aai-edugain+sp-metadata.xml>​ +===== Internationale Entity Categories ===== 
-  <​md:​EntityDescriptor entityID="​https://foodl.org/​simplesaml/​module.php/saml/sp/metadata.php/​saml">​ + 
-    <​md:​Extensions>​ +Drei Entity Categories kommen international zum Einsatz. Um sie für Ihre Systeme in der DFN-AAI zu setzen, verwenden Sie die [[https://www.aai.dfn.de/verwaltung/|Metadatenverwaltung]]. Dort tauchen die Checkboxen allerdings erst auf, wenn Ihr System die jeweiligen technischen Bedingungen erfüllt
-      <​mdrpi:​RegistrationInfo registrationAuthority="​http://​feide.no/"​ registrationInstant="​2011-05-05T06:​16:​34Z">​ + 
-        <​mdrpi:​RegistrationPolicy xml:​lang="​en">​http:​//www.feide.no/files/feide/​metadata-registration-practice-statement.pdf</mdrpi:RegistrationPolicy>​ +==== GÉANT Data Protection Code of Conduct ==== 
-      </​mdrpi:​RegistrationInfo>​ + 
-      <​mdattr:​EntityAttributes>​ +Die Entity Category GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA ist eine Selbstverpflichtungserklärung von Service ProvidernDamit sagen Sie über sich aus, dass sie die über SAML2 übertragenen personenbezogenen Daten von Endnutzern entsprechend den geltenden Datenschutzrichtlinien behandelnHintergrundinformationen finden Sie hier im [[https://doku.tid.dfn.de/de:geant_coco|Wiki]]. 
-        <​saml:​Attribute Name="​http://aai.dfn.de/edugain/registrationAuthority"​ NameFormat="​urn:​oasis:​names:​tc:​SAML:​2.0:attrname-format:uri">​ + 
-          <saml:AttributeValue>​http://​feide.no/</​saml:​AttributeValue>​ +Die Bedingungen für das Tragen der Entity Category sind im [[https://wiki.geant.org/display/eduGAIN/​Recipe+for+a+Service+Provider|GÉANT Wiki]] dokumentiertUnsere Metadatenverwaltung prüft, ob Ihr ''​mdui:PrivacyStatementURL''​ auf ein Dokument verweist, das den Code of Conduct explizit referenziert. Des Weiteren müssen die Requested Attributes in den Metadaten deklariert sein.  
-        </​saml:​Attribute>​ + 
-      </​mdattr:​EntityAttributes>​ +IdPs, die für Code of Conduct-SPs pauschal eine feste Attributliste freigeben möchten, sollten [[de:shibidp:config-attributes-coco|folgende Filterregel]] haben
-</​file>​+ 
 +==== Research and Scholarship ====
  
-===== Entity Categories ===== +Die Entity Category ​Research and Scholarship können ​Service Provider ​setzenderen Dienst ​die Zusammenarbeit oder das Management in den Bereichen Forschung ​und Bildung unterstützt. 
-Das [[#​entity_attribute|Entity Attribut]] **Entity Category** wird häufig dazu verwendet, ​Service Provider, die bestimmte Anforderungen stellen ​und/oder erfüllen, zu markierenDieses Attribut kann beliebig viele Werte annehmen. Ergänzend zu Entity Categories können **Entity Category Support** Attribute definiert werden, mit denen IdP signalisieren können, dass für SPs der entsprechende Entity Categorie eine Attributfreigabe erteilt wird. Zu diesem Themenkomplex siehe [[https://wiki.refeds.org/display/ENT/Entity-Categories+Home|https://​wiki.refeds.org/​display/​ENT/​Entity-Categories+Home]]+Die Bedingungen sind bei [[https://​refeds.org/​category/research-and-scholarship|REFEDS]] aufgelistet,​ wichtig sind für Sie vor allem die Registrierungskriterien (Punkt 4) und die Attributliste (Punkt 5).
  
-==== International ==== +Die Attributfreigaben,​ die IdP-seitig erfolgen können, sind unter [[de:shibidp:​config-attributes-rands|Attributfreigaben für die REFEDS Research and Scholarship Entity Category]] dokumentiert.
-**International** kommen vor allem diese Entity Categories zum Einsatz:+
  
-  * [[:​de:​shibidp3attrfilter#​attributfreigabe_fuer_code-of-conduct_sps|GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA]] +==== Hide from Discovery ==== 
-  * [[:​de:​shibidp3attrfilter#​refeds_research_and_scholarship_entity_category|Research and Scholarship]] +Die Entity Category ​[[https://​refeds.org/​category/​hide-from-discovery|Hide from Discovery]] ​für IdPs haben wir derzeit nicht in der Metadatenverwaltung implementiert. SPs sollten dennoch so konfiguriert sein, dass Sie die Entity Category unterstützen.
-  * [[https://​refeds.org/​category/​hide-from-discovery|Hide from Discovery ​(nur IdPs)]]+
  
-In der DFN-AAI **Metadatenverwaltung** tauchen die entsprechenden Checkboxen erst auf, wenn Ihr System die jeweiligen technischen Bedingungen erfüllt. +==== Beispiele ====
-  * Für die Entity Category für den GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA sind die Bedingungen im [[https://​wiki.geant.org/​display/​eduGAIN/​Recipe+for+a+Service+Provider|GÉANT Wiki]] dokumentiert. Unsere Metadatenverwaltung prüft, ob Ihr mdui:​PrivacyStatementURL auf ein Dokument verweist, das den Code of Conduct explizit referenziert. Des Weiteren müssen die Requested Attributes in den Metadaten deklariert sein. +
-  * Für die Entity Category Research and Scholarship finden Sie bei [[https://​refeds.org/​category/​research-and-scholarship|REFEDS]] die Registrierungskriterien (Punkt 4) und die Attributliste (Punkt 5).+
  
-=== Beispiele ===+Hier sehen Sie den Metadatenauszug eines Services Providers mit drei Entity Attributes: Er sagt CoCo-Compliance zu, bietet einen Dienst für kollaboratives Arbeiten in der Forschung o.ä. an und gehört zur Gruppe der Clarin-SPs.
  
 <file xml dfn-aai-sp-metadata.xml>​ <file xml dfn-aai-sp-metadata.xml>​
Zeile 95: Zeile 100:
     </​Extensions>​     </​Extensions>​
 </​file>​ </​file>​
 +
 +Hier sehen Sie den Metadatenauszug eines Identity Providers: Er hat Attributfreigaben für Code of Conduct-getreue SPs konfiguriert und verpflichtet sich den Kriterien der Verlässlichkeitsklasse Advanced.
  
 <file xml dfn-aai-metadata.xml>​ <file xml dfn-aai-metadata.xml>​
Zeile 114: Zeile 121:
 </​file>​ </​file>​
  
-==== DFN-AAI ==== +===== Entity Categories in der DFN-AAI =====
-In der **DFN-AAI** ​ kommen verschiedene Entity Categories zum Einsatz, die z.B. nach Projektzugehörigkeit vergeben und anhand der IdP- und SP-seitigen Filtermechanismen dazu eingesetzt werden können, sog. **virtuelle Subföderationen** zu bilden, z.B. für bwIDM, Nds-AAI und die Virtuelle Hochschule Bayern. Folgende Kategorien werden derzeit vergeben: +
- +
-  * [[de:​aai:​ec_bwidm-member|http://​aai.dfn.de/​category/​bwidm-member]] +
-  * [[de:​aai:​ec_clarin-member|http://​clarin.eu/​category/​clarin-member]] +
-  * [[de:​aai:​ec_ndsidm-member|http://​aai.dfn.de/​category/​ndsidm-member]] +
-  * [[de:​aai:​ec_vetmed-member|http://​aai.dfn.de/​category/​vetmed-member]] +
-  * [[de:​aai:​ec_vhb-member|http://​aai.dfn.de/​category/​vhb-member]] +
-  * [[de:​aai:​ec_rarp-member|http://​aai.dfn.de/​category/​rarp-member]] +
-  * [[de:​aai:​ec_public-idp|http://​aai.dfn.de/​category/​public-idp]]+
  
 +<callout color="#​ff9900"​ title="​Eigene Entity Category?">​
 Implementierungswünsche für weitere Entity Categories richten Sie bitte an [[hotline@aai.dfn.de|hotline@aai.dfn.de]]. Implementierungswünsche für weitere Entity Categories richten Sie bitte an [[hotline@aai.dfn.de|hotline@aai.dfn.de]].
 +</​callout>​
  
-=== Beispiele (Metadaten) ===+In der DFN-AAI ​ kommen Entity Categories zum Einsatz, die z.B. nach Projektzugehörigkeit vergeben werden. Sie können anhand der IdP- und SP-seitigen Filtermechanismen dazu eingesetzt werden, sogenannte **virtuelle Subföderationen** zu bilden, z.B. für bwIDM, Nds-AAI und die Virtuelle Hochschule Bayern. Folgende Kategorien werden derzeit vergeben: 
 + 
 +^ Wert ^ Beschreibung ^ 
 +| http://​aai.dfn.de/​category/​bwidm-member | Verfügbar für Einrichtungen,​ die am [[https://​www.bwidm.de|bwIdM-Verbund]] (Baden-Württemberg) teilnehmen. Informationen zu Teilnahme, technischen Voraussetzungen und Rahmenbedingungen unter https://​www.bwidm.de | 
 +| 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/​ndsidm-member | Verfügbar für Einrichtungen,​ die am Nds-AAI Projekt (Niedersachsen) teilnehmen. | 
 +| http://​aai.dfn.de/​category/​vetmed-member | Verfügbar für Einrichtungen,​ die am [[https://​www.tiho-hannover.de/​studium-lehre/​keldat-kompetenzzentrum/​|KELDAT-Projekt]] (Tiermedizin) teilnehmen. | 
 +| http://​aai.dfn.de/​category/​vhb-member | Verfügbar für Trägerhochschulen der Virtuellen Hochschule Bayern. Informationen zu Teilnahme, technischen Voraussetzungen und Rahmenbedingungen unter https://​www.vhb.org/​ | 
 +| http://​aai.dfn.de/​category/​rarp-member | Verfügbar für Mitglieder der Rechenzentrumsallianz Rheinland-Pfalz | 
 +| http://​aai.dfn.de/​category/​highmeducation-member | Verfügbar für Mitglieder des [[https://​www.medizininformatik-initiative.de/​de/​konsortien/​highmed|HiGHmed Konsortiums]] | 
 +| http://​aai.dfn.de/​category/​public-idp | Hiermit werden IdPs gekennzeichnet,​ die bekanntermaßen allen offenstehen,​ d.h. auch Nutzer*innen außerhalb von Wissenschaft und Forschung. Eine Identitätsprüfung findet i.d.R. nicht statt. Die Vergabe dieser Entity Category wird über eine manuell gepflegte Blacklist gesteuert. Hinweise auf IdPs, die dieser Kategorie zuzuordnen sind, richten Sie bitte an [[hotline@aai.dfn.de|hotline@aai.dfn.de]]. | 
 + 
 +==== Beispiele (Metadaten) ===
 + 
 +Hier sehen Sie den Metadatenauszug eines SP, der am bwIdM-Verbund teilnimmt:
  
 <file xml dfn-aai-sp-metadata.xml>​ <file xml dfn-aai-sp-metadata.xml>​
Zeile 143: Zeile 157:
     </​Extensions>​     </​Extensions>​
 </​file>​ </​file>​
 +
 +Hier sehen Sie den Metadatenauszug eines IdP, der am bwIdM-Verbund teilnimmt und sich der Verlässlichkeitsklasse Advanced zuordnet:
  
 <file xml dfn-aai-metadata.xml>​ <file xml dfn-aai-metadata.xml>​
Zeile 162: Zeile 178:
 </​file>​ </​file>​
  
-=== Public IdPs / Self-Signup IdPs === +Hier sehen Sie den Metadatenauszug eines IdP aus den eduGAIN-Metadaten (UK-Föderation), an dem sich Nutzer*innen selbst registrieren können:
- +
-Hiermit werden alle IdPs gekennzeichnetdie bekanntermaßen jedermann/​frau offenstehen,​ d.h. auch Nutzern außerhalb von Wissenschaft und Forschung. Eine Identitätsprüfung findet i.d.R. nicht statt. Die Vergabe dieser Entity Category wird über eine manuell gepflegte Blacklist gesteuert. Hinweise auf IdPs, die dieser Kategorie zuzuordnen sind, richten Sie bitte an hotline@aai.dfn.de.+
  
 <file xml dfn-aai-edugain+idp-metadata.xml>​ <file xml dfn-aai-edugain+idp-metadata.xml>​
Zeile 181: Zeile 195:
 </​file>​ </​file>​
  
-===== Beispiele (Filter) ​=====+==== Beispiele (Filter) ====
  
 SP-seitige Whitelist, bei der die Metadaten, mit denen der SP arbeitet, auf IdPs aus dem bwIDM-Projekt beschränkt werden: SP-seitige Whitelist, bei der die Metadaten, mit denen der SP arbeitet, auf IdPs aus dem bwIDM-Projekt beschränkt werden:
Zeile 260: Zeile 274:
 Weitere Beispiele unter [[https://​wiki.aai.dfn.de/​de:​shibidp3attrfilter|Attribut-Konfiguration]]. Weitere Beispiele unter [[https://​wiki.aai.dfn.de/​de:​shibidp3attrfilter|Attribut-Konfiguration]].
  
-===== Referenzen ​(Shibboleth Wiki) =====+===== Referenzen ===== 
 +Weiterführende Informationen finden Sie im Shibboleth Wiki unter folgenden Links:
  
   * **IdP - Attributfreigabe**   * **IdP - Attributfreigabe**
Zeile 275: Zeile 290:
       * [[https://​wiki.shibboleth.net/​confluence/​display/​SHIB2/​NativeSPMetadataFilter#​NativeSPMetadataFilter-EntityAttributesMetadataFilter(Version2.5andAbove)|Entity Attributes Metadata Filter]]       * [[https://​wiki.shibboleth.net/​confluence/​display/​SHIB2/​NativeSPMetadataFilter#​NativeSPMetadataFilter-EntityAttributesMetadataFilter(Version2.5andAbove)|Entity Attributes Metadata Filter]]
  
 +{{tag>​entity-category entity-attribute fixme}}
  • Zuletzt geändert: vor 5 Monaten