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/09 16:28] – [Generator anschalten] Silke Meyerde:shibidp:config-storage [2020/04/14 16:22] – [Weitergabe der Persistent ID] 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 type="danger" 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 type="danger" 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 224: Zeile 224:
 </file> </file>
  
-Viertens: meist sind Usernamen im IdM-System unabhängig von Gross- und Kleinschreibung. D.h. die User können Ihren Loginnamen sowohl in Gross- als auch Kleinschreibung angeben und damit einen erfolgreichen Login durchführen. Allerdings führt dieses später zu Problemen beim Verwalten der Usernamen in der lokalen IdP-Datenbank da diese Gross- und Kleinschreibung unterscheidet. Wir empfehlen daher den Usernamen in diesen Fällen im IdP in Kleinbuchstaben umzuwandeln:+==== Lowercase-Usernamen ==== 
 + 
 +Meist sind Usernamen in IdM-Systemen unabhängig von Groß- und Kleinschreibung: Nutzer*innen können ihre Anmeldenamen sowohl groß, als auch klein schreiben und sich damit erfolgreich anmelden. Die IdP-Datenbank unterscheidet jedoch zwischen Groß- und Kleinschreibung. Wir empfehlen daher, alle Usernamen im IdP in Kleinbuchstaben zu verarbeiten:
  
 <file xml ./conf/c14n/simple-subject-c14n-config.xml> <file xml ./conf/c14n/simple-subject-c14n-config.xml>
Zeile 231: Zeile 233:
    ...    ...
 </file> </file>
- 
-Damit werden die Usernamen vom IdP nur noch in Kleinbuchstabenform verarbeitet und in die Datenbank geschrieben. 
  
 ===== Session-Informationen und User Consent ===== ===== Session-Informationen und User Consent =====
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>
  
  • Zuletzt geändert: vor 4 Wochen