Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung
Vorhergehende Überarbeitung
de:shibidp3userdepro [2017/08/22 14:58]
Martin Lunze angelegt
de:shibidp3userdepro [2018/07/19 15:26]
Wolfgang Pempe
Zeile 23: Zeile 23:
       * Negativ: es sind teilweise Anpassungen am SP und/oder IDM nötig       * Negativ: es sind teilweise Anpassungen am SP und/oder IDM nötig
  
-=====Anforderungen an Querys=====+=====Anforderungen an Queries=====
  
 Betrachten wir die letzte Variante mit Hilfe des Shibboleth-eigenen Board-Mittels namens **Attribute-Query**.\\ Betrachten wir die letzte Variante mit Hilfe des Shibboleth-eigenen Board-Mittels namens **Attribute-Query**.\\
Zeile 43: Zeile 43:
    * es wird wenigstens ein Attribut an den SP ausgeliefert    * es wird wenigstens ein Attribut an den SP ausgeliefert
  
-=====Querys ​stellen=====+=====Queries ​stellen=====
  
 Wie stellt man einen Query? Wie stellt man einen Query?
Zeile 115: Zeile 115:
 </​code>​ </​code>​
  
-=====Verlässlichkeit von Querys=====+=====Verlässlichkeit von Queries=====
  
-Hat man seine ersten ​Querys ​erfolgreich gestellt kommen schnell die Fragen auf:\\+Hat man seine ersten ​Queries ​erfolgreich gestellt kommen schnell die Fragen auf:\\
 **Wann kann ich den Nutzer löschen?** und **Wie verlässlich ist die Rückgabe?​** **Wann kann ich den Nutzer löschen?** und **Wie verlässlich ist die Rückgabe?​**
  
Zeile 230: Zeile 230:
    * urn:​schac:​userStatus:​de:​einrichtung.de:​affiliation:​blocked    * urn:​schac:​userStatus:​de:​einrichtung.de:​affiliation:​blocked
  
-=====Querys ​einschränken=====+=====Queries ​einschränken=====
  
-Wer darf eigentlich ​Querys ​stellen?+Wer darf eigentlich ​Queries ​stellen?
  
-Da Querys ​nur mit Angabe der persistentId funktionieren,​ so kann man per RelyingParty-Config einschränken,​ dass nur die SPs Querys ​stellen dürfen für die auch die persistentId freigegeben ist.\\+Da Queries ​nur mit Angabe der persistentId funktionieren,​ so kann man per RelyingParty-Config einschränken,​ dass nur die SPs Queries ​stellen dürfen für die auch die persistentId freigegeben ist.\\
 Dies lässt sich unter Angabe einer [[de:​shibidp3activationcondition|Activation Condition]] simpel lösen.\\ Dies lässt sich unter Angabe einer [[de:​shibidp3activationcondition|Activation Condition]] simpel lösen.\\
 **ACHTUNG:​** Diese Einstellung ist nur zu empfehlen, wenn **keine SAML1 SPs** mehr bedient werden!!! **ACHTUNG:​** Diese Einstellung ist nur zu empfehlen, wenn **keine SAML1 SPs** mehr bedient werden!!!
Zeile 278: Zeile 278:
 </​file>​ </​file>​
  
-Wozu sollen ​Querys ​genutzt werden?\\+Wozu sollen ​Queries ​genutzt werden?\\
    * User-Synchronisierung    * User-Synchronisierung
    * User-Deprovisionierung    * User-Deprovisionierung
Zeile 285: Zeile 285:
 Es empfiehlt sich jedoch im Vorfeld mit dem **Datenschutzbeauftragten** dieses Vorgehen im Vorfeld zu besprechen, da hier **ohne Einverständnis** des Nutzers **personenbezogene Daten** ausgetauscht werden!!! Es empfiehlt sich jedoch im Vorfeld mit dem **Datenschutzbeauftragten** dieses Vorgehen im Vorfeld zu besprechen, da hier **ohne Einverständnis** des Nutzers **personenbezogene Daten** ausgetauscht werden!!!
  
-Will man Querys ​ausschließlich zur User-Deprovisionierung benutzen, so kann man sämtliche anderen Attribute für diesen Kanal deaktivieren.\\+Will man Queries ​ausschließlich zur User-Deprovisionierung benutzen, so kann man sämtliche anderen Attribute für diesen Kanal deaktivieren.\\
 Dies bringt unter anderem folgende Vorteile mit sich: Dies bringt unter anderem folgende Vorteile mit sich:
    * Minimierung der openLDAP Abfragen    * Minimierung der openLDAP Abfragen
Zeile 299: Zeile 299:
  
 Danke noch mal an Steffen Hofmann (FU Berlin), der diese Datei zur Verfügung gestellt hat.\\ Danke noch mal an Steffen Hofmann (FU Berlin), der diese Datei zur Verfügung gestellt hat.\\
-Mit Hilfe des enthaltenen Predicate ist es uns möglich eine Entscheidung zu treffen ob es sich um einen Attribute-Query handelt oder nicht.\\ +Mit Hilfe des **enthaltenen Predicate** ist es uns möglich eine Entscheidung zu treffen ob es sich um einen **Attribute-Query** handelt oder nicht.\\ 
-Darauf aufbauend erstellen wir uns beliebige Activation Conditions, um die Erstellung und Freigabe von Attributen zu steuern.+Darauf aufbauend erstellen wir uns beliebige ​**Activation Conditions**, um die Erstellung und **Freigabe von Attributen** zu steuern.
  
 <file xml conf/​activation-conditions.xml>​ <file xml conf/​activation-conditions.xml>​
Zeile 342: Zeile 342:
 </​file>​ </​file>​
  
-Nun aktivieren wir die Bedingungen im Resolver, so dass die **normalen** Attribute **nur** noch bei einem normalen Login gebaut und an den Filter weitergereicht werden, aber nicht bei einem Query und dass das **schacUserStatus** Attribut **nur** noch bei einem Query erstellt ​wird.+Nun aktivieren wir die Bedingungen im Resolver.\\ 
 +Dadurch werden ​**normale** Attribute **nur** noch bei einem normalen Login gebaut und an den Filter weitergereicht werden, aber nicht bei einem Query.\\ 
 +Das **schacUserStatus** Attribut ​hingegen wird **nur** noch bei einem Query erstellt.
  
 <file xml conf/​attribute-resolver.xml>​ <file xml conf/​attribute-resolver.xml>​
Zeile 395: Zeile 397:
    * teils verknüpfung mehrerer bedingungen bei den conditions da einige attribute z.B. nur an bestimmte SPs ausgeliefert werden    * teils verknüpfung mehrerer bedingungen bei den conditions da einige attribute z.B. nur an bestimmte SPs ausgeliefert werden
  
-=====Wann / Wie oft Querys ​stellen=====+=====Wann / Wie oft Queries ​stellen=====
  
-Wann und wie oft sollten ​Querys ​gestellt werden?+Wann und wie oft sollten ​Queries ​gestellt werden?
  
 Zunächst vorweg:\\ Zunächst vorweg:\\
Zeile 406: Zeile 408:
    * letzte Prüfung > x Tage    * letzte Prüfung > x Tage
  
-Desweiteren sollte man **kleine Pausen zwischen einzelnen ​Querys** lassen, damit man als SP nicht Gefahr läuft z.B. durch Mechanismen wie Fail2Ban ausgesperrt zu werden.\\+Desweiteren sollte man **kleine Pausen zwischen einzelnen ​Queries** lassen, damit man als SP nicht Gefahr läuft z.B. durch Mechanismen wie Fail2Ban ausgesperrt zu werden.\\
 Als Betreiber eines IdP ist es durchaus denkbar sich ähnlich wie im Thema [[de:​shibidp3fail2ban|Abwehr Brute Force]] Gedanken zu machen um sich gegen zu viele Query-Anfragen zu schützen. Als Betreiber eines IdP ist es durchaus denkbar sich ähnlich wie im Thema [[de:​shibidp3fail2ban|Abwehr Brute Force]] Gedanken zu machen um sich gegen zu viele Query-Anfragen zu schützen.
  
Zeile 417: Zeile 419:
    * man gewährleistet,​ dass sich weiterhin Nutzer einloggen können    * man gewährleistet,​ dass sich weiterhin Nutzer einloggen können
  
-Alternativ besteht vielleicht die Möglichkeit einen separaten IdP aufzusetzen,​ der ausschließlich für die Abarbeitung von Querys ​zuständig ist.\\ +Alternativ besteht vielleicht die Möglichkeit einen **separaten IdP** aufzusetzen,​ der **ausschließlich** für die Abarbeitung von **Queries** ​zuständig ist.\\ 
-Dabei sollte sichergestellt sein, dass alle IdP-Server via Datenbank-Replikation den gleichen Datenbestand aufweisen!!!+Dabei sollte sichergestellt sein, dass alle IdP-Server via **Datenbank-Replikation** den gleichen Datenbestand aufweisen!!!
  
 Denkbare Schwellwerte für Fail2Ban wären: maximal 50 Queries innerhalb von 10 Sekunden (nicht getestet und abhängig von der Menge der zu prüfenden Nutzer) Denkbare Schwellwerte für Fail2Ban wären: maximal 50 Queries innerhalb von 10 Sekunden (nicht getestet und abhängig von der Menge der zu prüfenden Nutzer)
  • Zuletzt geändert: vor 12 Monaten