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
Nächste ÜberarbeitungBeide Seiten der Revision
de:shibidp:config-storage [2020/04/14 15:13] – Silke Meyerde:shibidp:config-storage [2020/05/13 16:14] – ↷ Links angepasst weil Seiten im Wiki verschoben wurden Silke Meyer
Zeile 5: Zeile 5:
 Standardmäßig werden Informationen zu Sessions, User Consent (bzgl. Attributfreigabe) und Persistent IDs clientseitig in Cookies abgelegt. Wir betrachten die clientseitige Speicherung nur als initiale "Notlösung", damit der IdP auch ohne Datenbank funktioniert. In einem fertigen Produktivszenario ist das Abspeichern dieser Informationen auf Serverseite unbedingt zu empfehlen, da nur damit erweiterte SAML-Funktionalitäten möglich sind (z.B. persistentIds oder Single-Logout). Nur so kann sichergestellt werden, dass bei Attribute Queries, die Entscheidungen des/der Nutzers/Nutzerin hinsichtlich Attributfreigabe berücksichtigt werden. Standardmäßig werden Informationen zu Sessions, User Consent (bzgl. Attributfreigabe) und Persistent IDs clientseitig in Cookies abgelegt. Wir betrachten die clientseitige Speicherung nur als initiale "Notlösung", damit der IdP auch ohne Datenbank funktioniert. In einem fertigen Produktivszenario ist das Abspeichern dieser Informationen auf Serverseite unbedingt zu empfehlen, da nur damit erweiterte SAML-Funktionalitäten möglich sind (z.B. persistentIds oder Single-Logout). Nur so kann sichergestellt werden, dass bei Attribute Queries, die Entscheidungen des/der Nutzers/Nutzerin hinsichtlich Attributfreigabe berücksichtigt werden.
  
-<callout color="#660066" title="persistentId?">+<callout color="#ff9900" title="persistentId?">
 PersistentIds werden vom IdP pro Useraccount und pro Service Provider automatisch generiert. Sie sind pseudonym und können am SP zur Wiedererkennung und Personalisierung verwendet werden. Nur am IdP ist ist ersichtlich, welchen Nutzer*innen die persistentIds zuzuordnen sind. persistentIds sind keine normalen Attribute, sondern sogenannte SAML2 NameIDs. Ihre Freigabe wird in der Konfigurationsdatei ''./conf/relying-party.xml'' reguliert. PersistentIds werden vom IdP pro Useraccount und pro Service Provider automatisch generiert. Sie sind pseudonym und können am SP zur Wiedererkennung und Personalisierung verwendet werden. Nur am IdP ist ist ersichtlich, welchen Nutzer*innen die persistentIds zuzuordnen sind. persistentIds sind keine normalen Attribute, sondern sogenannte SAML2 NameIDs. Ihre Freigabe wird in der Konfigurationsdatei ''./conf/relying-party.xml'' reguliert.
 </callout> </callout>
  
-<callout color="#660066" title="Attribute Query?">+<callout color="#ff9900" title="Attribute Query?">
 Bei einer Attribute Query fragt ein Service Provider direkt beim IdP Nutzerdaten ab, also ohne, dass Nutzer*innen einen Loginvorgang angestoßen haben. Dies tun manche SPs, um Informationen darüber zu bekommen, ob Useraccounts am IdP noch aktiv sind. Für Attribute Queries wird gerne die persistentId verwendet. Bei einer Attribute Query fragt ein Service Provider direkt beim IdP Nutzerdaten ab, also ohne, dass Nutzer*innen einen Loginvorgang angestoßen haben. Dies tun manche SPs, um Informationen darüber zu bekommen, ob Useraccounts am IdP noch aktiv sind. Für Attribute Queries wird gerne die persistentId verwendet.
 </callout> </callout>
Zeile 168: Zeile 168:
 Wählen Sie ein Quellattribut aus Ihrem IdM, das **über die Zeit eindeutig** bleibt! Bei OpenLDAP ist das oft die ''uid'', bei Active Directory der ''sAMAccountName'' oder ''cn''. Wenn Sie diese Attribute für neue Accounts wiederverwenden, dann //müssen// Sie ein anderes IdM-Attribut zur Generierung der persistentId verwenden. Wählen Sie ein Quellattribut aus Ihrem IdM, das **über die Zeit eindeutig** bleibt! Bei OpenLDAP ist das oft die ''uid'', bei Active Directory der ''sAMAccountName'' oder ''cn''. Wenn Sie diese Attribute für neue Accounts wiederverwenden, dann //müssen// Sie ein anderes IdM-Attribut zur Generierung der persistentId verwenden.
  
-Ein möglicher Workaround: Sie können sich in der ''./conf/attribute-resolver.xml'' ein neues Attribut definieren. Dieses Attribut könnte aus einem Hash aus uid und dem Anlegedatum des Accounts bestehen. Beispiele zur Generierung finden Sie unter [[:de:shibidp3pidspecials|Persistent ID - Sonderfälle]].+Ein möglicher Workaround: Sie können sich in der ''./conf/attribute-resolver.xml'' ein neues Attribut definieren. Dieses Attribut könnte aus einem Hash aus uid und dem Anlegedatum des Accounts bestehen. Beispiele zur Generierung finden Sie unter [[de:shibidp:config-pidspecials|Persistent ID - Sonderfälle]].
  
 ==== Generierung und Speicherung ==== ==== Generierung und Speicherung ====
Zeile 308: Zeile 308:
  
 <code bash> <code bash>
-root@idp:/opt/shibboleth-idp# service tomcat8 restart+root@idp:/opt/shibboleth-idp# systemctl restart tomcat9
 </code> </code>
  
Zeile 315: Zeile 315:
 HINWEIS: Da die persistendId kein SAML-Attribut ist, wird Ihnen diese nach dem Login am IdP nicht in der Liste der zu übertragenden Attribute angezeigt. Erst wenn Sie wieder am Test-SP sind wird Ihnen dort die persistentId, sofern diese übertragen wurde, zusammen mit den übertragenen Attributen angezeigt. HINWEIS: Da die persistendId kein SAML-Attribut ist, wird Ihnen diese nach dem Login am IdP nicht in der Liste der zu übertragenden Attribute angezeigt. Erst wenn Sie wieder am Test-SP sind wird Ihnen dort die persistentId, sofern diese übertragen wurde, zusammen mit den übertragenen Attributen angezeigt.
  
-Falls die persistentId nur an ausgewählte SPs übertragen werden soll, so finden sich [[:de:shibidp3pidspecials|hier einige Beispiele]]. +Falls die persistentId nur an ausgewählte SPs übertragen werden soll, so finden sich [[de:shibidp:config-pidspecials|hier einige Beispiele]].
- +
-**Weiter geht es mit [[:de:shibidp3slo|Single Logout]]. **+
  
 +**Weiter geht es mit [[:de:shibidp:config-slo|Single Logout]]. **
  
 +{{tag>idp4 tutorial}}
  • Zuletzt geändert: vor 13 Tagen