Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:shibidp3userdepro [2019/08/28 09:29] – [Verlässlichkeit von Queries] Wolfgang Pempe | de:shibidp:config-deprovisionierung [2021/09/29 14:45] – [Queries stellen] Wolfgang Pempe | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
~~NOTOC~~ | ~~NOTOC~~ | ||
+ | |||
====== User Deprovisionierung via Attribute Query ====== | ====== User Deprovisionierung via Attribute Query ====== | ||
+ | |||
+ | <callout color="# | ||
+ | Dieser Artikel ist ein Community-Beitrag für Shibboleth IdP 3.x. Es ist unklar, ob er für Shibboleth IdP 4.x so noch gilt. | ||
+ | </ | ||
+ | |||
{{INLINETOC 2}} | {{INLINETOC 2}} | ||
- | =====Einleitung===== | + | ===== Einleitung ===== |
Dies ist **keine fertige Schritt für Schritt Anleitung** wie man eine " | Dies ist **keine fertige Schritt für Schritt Anleitung** wie man eine " | ||
Zeile 10: | Zeile 16: | ||
(Ausgenommen: | (Ausgenommen: | ||
- | =====Lösungsansätze===== | + | ===== Lösungsansätze ===== |
Also wie entscheiden wir nun ob ein Nutzer noch existiert oder nicht?\\ | Also wie entscheiden wir nun ob ein Nutzer noch existiert oder nicht?\\ | ||
Überlegen wir mal kurz welche Möglichkeiten sich uns bieten, wenn wir nun " | Überlegen wir mal kurz welche Möglichkeiten sich uns bieten, wenn wir nun " | ||
- | - Sperren und Löschen des Nutzers nach definierter Inaktivität dessen | + | |
+ | | ||
* Positiv: einfachster Weg ohne die Notwendigkeit irgendwelcher Erweiterungen | * Positiv: einfachster Weg ohne die Notwendigkeit irgendwelcher Erweiterungen | ||
* Negativ: Nutzererfahren unschön wenn man nach längerer Inaktivität einen leeren Account vorfindet und/oder sich in regelmäßigen Abständen einloggen muss (eventuell vorher per Mail benachrichtigen? | * Negativ: Nutzererfahren unschön wenn man nach längerer Inaktivität einen leeren Account vorfindet und/oder sich in regelmäßigen Abständen einloggen muss (eventuell vorher per Mail benachrichtigen? | ||
- | - Abfrage des IDM-Systems (regelmäßig oder nach definierter Inaktivität des Nutzers) über eine weitere Schnittstelle | + | |
* Positiv: Nutzer wird nur gesperrt/ | * Positiv: Nutzer wird nur gesperrt/ | ||
* Negativ: größerer Aufwand durch Anbindung über weitere Schnittstelle (eventuell Probleme mit Datenschutz und anderen technischen Vorkehrungen etc.) | * Negativ: größerer Aufwand durch Anbindung über weitere Schnittstelle (eventuell Probleme mit Datenschutz und anderen technischen Vorkehrungen etc.) | ||
- | - Abfrage des Shibboleth-IdP (regelmäßig oder nach definierter Inaktivität des Nutzers) via Attribute-Query | + | |
* Positiv: Nutzung einer bereits existierenden Schnittstelle | * Positiv: Nutzung einer bereits existierenden Schnittstelle | ||
* 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 Queries===== | + | ===== 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**. \\ Ursprünglich diente dieses Verfahren bei SAML1 der direkten Übertragung der Nutzer-Attribute zwischen IdP und SP über einen Backchannel. \\ Hier stellte der SP nach erfolgreichem Login des Nutzers eine separate Anfrage an den IdP, welcher alle Attribute über den Nutzer auslieferte, |
- | Ursprünglich diente dieses Verfahren bei SAML1 der direkten Übertragung der Nutzer-Attribute zwischen IdP und SP über einen Backchannel.\\ | + | |
- | Hier stellte der SP nach erfolgreichem Login des Nutzers eine separate Anfrage an den IdP, welcher alle Attribute über den Nutzer auslieferte, | + | |
- | Um solch einen Query stellen zu können muss der SP im Besitz eines gültigen **NameIdentifiers** sein, damit der IdP diesen Auflösen kann.\\ | + | Um solch einen Query stellen zu können muss der SP im Besitz eines gültigen **NameIdentifiers** |
- | Wenn ein SP einen Query zu einem beliebigen Zeitpunkt stellen möchte (unabhängig vom Vorhandensein eines Login-Contextes des Nutzers), so kommt hier lediglich die **" | + | |
- | Diese muss auf Seiten des IdP dazu in einer Datenbank gespeichert werden, damit Sie rückwärts aufgelöst werden kann. | + | |
**Anforderungen** | **Anforderungen** | ||
- | * persistentId wird an SP ausgeliefert | ||
- | * persistentId wird auf IdP Seite gespeichert | ||
- | * persistentId wird auf SP Seite gespeichert | ||
- | * Nutzer hat sich wenigstens einmal am SP angemeldet | ||
- | * Attribute Query Profil ist für RelyingParty freigeschalten | ||
- | * SP hat Möglichkeit einen Query zu stellen | ||
- | * SP erreicht den IdP direkt (ohne Umweg/ | ||
- | * es wird wenigstens ein Attribut an den SP ausgeliefert | ||
- | =====Queries stellen===== | + | * persistentId wird an SP ausgeliefert |
+ | * persistentId wird auf IdP Seite gespeichert | ||
+ | * persistentId wird auf SP Seite gespeichert | ||
+ | * Nutzer hat sich wenigstens einmal am SP angemeldet | ||
+ | * Attribute Query Profil ist für RelyingParty freigeschalten | ||
+ | * SP hat Möglichkeit einen Query zu stellen | ||
+ | * SP erreicht den IdP direkt (ohne Umweg/ | ||
+ | * es wird wenigstens ein Attribut an den SP ausgeliefert | ||
+ | |||
+ | ===== Queries stellen ===== | ||
Wie stellt man einen Query? | Wie stellt man einen Query? | ||
- | Standardmäßig bringt der SP ein **" | + | Standardmäßig bringt der SP ein **" |
- | Dieses empfiehlt sich jedoch nur für einen initialen Test, um zu Prüfen ob alle Einstellungen passen und der Attribute Query korrekt beantwortet wird.\\ | + | |
- | Für den Produktiv-Einsatz arbeitet es **zu langsam**! | + | |
< | < | ||
Zeile 59: | Zeile 61: | ||
# surname: Mustermann | # surname: Mustermann | ||
# ... | # ... | ||
+ | |||
</ | </ | ||
Zeile 70: | Zeile 73: | ||
# surname: Mustermann | # surname: Mustermann | ||
# ... | # ... | ||
+ | |||
</ | </ | ||
- | Will man nun vom SP aus automatisiert Anfragen stellen so empfiehlt es sich auf den **Attribute Handler** bzw. die [[https:// | + | Will man nun vom SP aus automatisiert Anfragen stellen, so existiert hierfür der. sog. Attribute |
<file xml / | <file xml / | ||
<!-- ... --> | <!-- ... --> | ||
- | < | + | |
- | < | + | < |
- | <Library path="attributequery-handler.so" fatal=" | + | <Library path="plugins.so" fatal=" |
- | </ | + | </ |
- | </ | + | </ |
- | < | + | |
- | < | + | < |
- | <Library path="attributequery-handler-lite.so" | + | <Library path="plugins-lite.so" |
- | </ | + | |
- | </ | + | </ |
- | < | + | |
- | < | + | < |
- | <!-- ... --> | + | <!-- ... --> |
- | <Handler type="AttributeQuery" Location="/ | + | <Handler type="AttributeResolver" Location="/ |
- | <!-- ... --> | + | <!-- ... --> |
- | </ | + | </ |
- | <!-- ... --> | + | <!-- ... --> |
- | </ | + | < |
+ | <!-- ... --> | ||
+ | | ||
<!-- ... --> | <!-- ... --> | ||
+ | |||
+ | |||
</ | </ | ||
- | Vergessen Sie nicht den **" | + | Vergessen Sie nicht den **" |
- | Danach kann ein Aufruf z.B. direkt mit CURL durchgeführt werden. | + | |
< | < | ||
Zeile 107: | Zeile 114: | ||
Stichwort URLencoding!!! | Stichwort URLencoding!!! | ||
- | # curl -k " | + | # curl -k " |
</ | </ | ||
- | Alternativ kann dies auch mit Hilfe des mitgelieferten Python-Skriptes ausgeführt werden. | + | ===== Verlässlichkeit von Queries ===== |
- | < | + | Hat man seine ersten Queries erfolgreich gestellt, kommen schnell die Fragen auf: \\ **Wann kann ich den Nutzer löschen? |
- | # / | + | |
- | </ | + | |
- | =====Verlässlichkeit von Queries===== | + | Wenn wir davon ausgehen dass ein Query das gleiche Attribut-Set zurück liefert, wie ein normaler Login-Vorgang, |
- | Hat man seine ersten Queries erfolgreich gestellt, kommen schnell die Fragen auf:\\ | + | **leeres Ergebnis** |
- | **Wann kann ich den Nutzer löschen?** und **Wie verlässlich ist die Rückgabe?** | + | |
- | Wenn wir davon ausgehen dass ein Query das gleiche Attribut-Set zurück liefert, wie ein normaler Login-Vorgang, | + | |
- | Aber **ACHTUNG**!!!\\ | + | |
- | Folgende Fallstricke können fälschlicherweise zu einem **leeren** oder auch **nicht | + | * persistentId wird auf Seiten des IdP generell nicht gespeichert |
+ | * Nutzer ist nicht mehr im LDAP (obwohl noch im IDM vorhanden - Synchronisierungsproblem) | ||
+ | | ||
+ | | ||
- | **leeres Ergebnis**\\ | + | **nicht leeres Ergebnis** |
- | * persistentId wurde falsch übergeben | + | |
- | * persistentId existiert nicht auf Seiten des IdP | + | |
- | * persistentId wird auf Seiten des IdP generell nicht gespeichert | + | |
- | * Nutzer ist nicht mehr im LDAP (obwohl noch im IDM vorhanden - Synchronisierungsproblem) | + | |
- | * LDAP-Verbindung ist abgebrochen | + | |
- | * Query ist fehlgeschlagen | + | |
- | **nicht leeres Ergebnis**\\ | + | * Statische Attribute im Resolver liefern immer Werte (obwohl Nutzer nicht mehr existent) |
- | * Statische Attribute im Resolver liefern immer Werte (obwohl Nutzer nicht mehr existent) | + | * Nutzer wurde im LDAP nicht entfernt (obwohl im IDM nicht mehr vorhanden - Synchronisierungsproblem) |
- | | + | * Nutzer Passwort wurde im LDAP geändert (damit er sich nicht mehr einloggen kann) |
- | | + | |
- | Prinzipiell kann behauptet werden, dass man einem **leeren** Ergebnis **nicht** trauen kann und sollte!\\ | + | Prinzipiell kann behauptet werden, dass man einem **leeren** |
- | Doch wie schließt man nun die diversen Fehler bei der Übertragung aus? | + | |
- | Sicherer wäre es, wenn man ein Attribut bekommt, was den Nutzerstatus abbildet und an Hand dessen man entscheidet, | + | Sicherer wäre es, wenn man ein Attribut bekommt, was den Nutzerstatus abbildet und an Hand dessen man entscheidet, |
- | Denn wenn man einen definierten Wert für das Attribut erhält kann man zumindest davon ausgehen, dass alles funktioniert hat und der Query erfolgreich abgearbeitet wurde und auch sonst keine Probleme bei der Abfrage des LDAP oder sonst irgendwo bei der Kommunikation zwischen den Systemen aufgetreten sind! | + | |
- | Um den LDAP nicht mit **Karteileichen** vollzumüllen, | + | Um den LDAP nicht mit **Karteileichen** |
- | * '' | + | |
- | | + | * '' |
- | * '' | + | * '' |
- | | + | * '' |
- | | + | * '' |
- | | + | * '' |
- | Scheidet ein Nutzer aus oder muss z.B. auf Grund eines Sicherheitsvorfalls kurzfristig deaktiviert werden, so verschiebt man diesen zunächst nach '' | + | Scheidet ein Nutzer aus oder muss z.B. auf Grund eines Sicherheitsvorfalls kurzfristig deaktiviert werden, so verschiebt man diesen zunächst nach '' |
- | Damit kann er sich schon mal nicht mehr am IdP authentifizieren (da nicht mehr im baseDN).\\ | + | |
- | Kommt der Nutzer nach x-Tagen nicht mehr zurück an die Einrichtung so kann man ihn dauerhaft löschen und nach '' | + | |
- | Generell reicht es zu, wenn die Einträge unter '' | + | Generell reicht es zu, wenn die Einträge unter '' |
- | Jetzt definieren wir im IdP das Attribut [[https:// | + | Jetzt definieren wir im IdP das Attribut [[:de: |
Vokabular für schacUserStatus: | Vokabular für schacUserStatus: | ||
- | * Attributwert: | ||
- | * '' | ||
- | * '' | ||
- | * '' | ||
- | * '' | ||
+ | * Attributwert: | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
<file xml conf/ | <file xml conf/ | ||
< | < | ||
- | <!-- look in dn of archiveLDAP for inactive or blocked --> | + | |
- | <!-- schacUserStatus --> | + | <!-- schacUserStatus --> |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | if (typeof entryDN != " | + | if (typeof entryDN != " |
- | var prefix = " | + | var prefix = " |
- | var disabled= " | + | var disabled= " |
- | var locked | + | var locked |
var deleted = " | var deleted = " | ||
- | for (i=0; i< | + | |
- | var tmp = entryDN.getValues().get(i); | + | var tmp = entryDN.getValues().get(i); |
- | if (tmp.endsWith(disabled)) { | + | |
- | schacUserStatus.addValue(prefix + " | + | schacUserStatus.addValue(prefix + " |
- | } | + | } |
- | else if (tmp.endsWith(locked)) { | + | else if (tmp.endsWith(locked)) { |
- | schacUserStatus.addValue(prefix + " | + | schacUserStatus.addValue(prefix + " |
- | } | + | } |
- | else if (tmp.endsWith(deleted)) { | + | else if (tmp.endsWith(deleted)) { |
- | schacUserStatus.addValue(prefix + " | + | schacUserStatus.addValue(prefix + " |
- | } | + | } |
- | else { | + | else { |
- | schacUserStatus.addValue(prefix + " | + | schacUserStatus.addValue(prefix + " |
- | } | + | } |
- | } | + | } |
- | } | + | } |
- | ]]> | + | ]]> |
- | </ | + | </ |
- | </ | + | </ |
- | < | + | |
- | ldapURL=" | + | ldapURL=" |
- | baseDN=" | + | baseDN=" |
- | principal=" | + | principal=" |
- | principalCredential=" | + | principalCredential=" |
- | searchScope=" | + | searchScope=" |
- | maxResultSize=" | + | maxResultSize=" |
- | useStartTLS=" | + | useStartTLS=" |
- | < | + | |
- | < | + | < |
- | %{idp.attribute.resolver.LDAP.archiveSearchFilter} | + | %{idp.attribute.resolver.LDAP.archiveSearchFilter} |
- | ]]> | + | ]]> |
- | </ | + | </ |
- | </ | + | </ |
< | < | ||
+ | |||
+ | |||
</ | </ | ||
<file properties conf/ | <file properties conf/ | ||
< | < | ||
- | idp.attribute.resolver.LDAP.archiveDN | + | |
- | idp.attribute.resolver.LDAP.archiveSearchFilter = (uid=$requestContext.principalName) | + | idp.attribute.resolver.LDAP.archiveSearchFilter = (uid=$requestContext.principalName) |
< | < | ||
+ | |||
+ | |||
</ | </ | ||
<file xml conf/ | <file xml conf/ | ||
< | < | ||
- | < | + | |
- | < | + | < |
- | </ | + | </ |
< | < | ||
+ | |||
+ | |||
</ | </ | ||
- | Bekommt ein SP nun bei einem Query einen der folgenden Werte, so kann er den Nutzer verlässlich sperren oder gar löschen.\\ | + | Bekommt ein SP nun bei einem Query einen der folgenden Werte, so kann er den Nutzer verlässlich sperren oder gar löschen. |
- | | + | |
- | | + | |
- | | + | * '' |
- | | + | * '' |
- | Als Beispiel für '' | + | * |
- | https:// | + | |
- | =====Queries einschränken===== | + | Als Beispiel für eine Attribute Query, die ein solches Attribut liefert, kann dieser URL genutzt werden: \\ [[https:// |
+ | (zuvor bitte bei der DFN-AAI Hotline Bescheid sagen, damit die ACL für diesen Handler entsprechend erweitert wird) | ||
+ | |||
+ | ===== Queries einschränken ===== | ||
Wer darf eigentlich Queries stellen? | Wer darf eigentlich Queries stellen? | ||
- | Da Queries nur mit Angabe der persistentId funktionieren, | + | Da Queries nur mit Angabe der persistentId funktionieren, |
- | Dies lässt sich unter Angabe einer [[de:shibidp3activationcondition|Activation Condition]] simpel lösen.\\ | + | **ACHTUNG: |
- | **ACHTUNG: | + | |
<file xml conf/ | <file xml conf/ | ||
< | < | ||
- | <bean id=" | + | |
- | < | + | < |
- | < | + | < |
- | <bean parent=" | + | <bean parent=" |
- | <ref bean=" | + | <ref bean=" |
- | <ref bean=" | + | <ref bean=" |
- | </ | + | </ |
- | </ | + | </ |
- | </ | + | </ |
- | < | + | |
- | <bean parent=" | + | <bean parent=" |
- | < | + | < |
- | < | + | < |
- | <bean parent=" | + | <bean parent=" |
- | <ref bean=" | + | <ref bean=" |
- | <ref bean=" | + | <ref bean=" |
- | <ref bean=" | + | <ref bean=" |
- | </ | + | </ |
- | </ | + | </ |
- | </ | + | </ |
- | </ | + | </ |
< | < | ||
+ | |||
+ | |||
</ | </ | ||
<file xml conf/ | <file xml conf/ | ||
< | < | ||
- | <bean id=" | + | |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | </ | + | </ |
- | </ | + | </ |
- | </ | + | </ |
< | < | ||
+ | |||
+ | |||
</ | </ | ||
- | Wozu sollen Queries genutzt werden?\\ | + | Wozu sollen Queries genutzt werden? |
- | * User-Synchronisierung | + | |
- | * User-Deprovisionierung | + | |
- | Möchte man via Query Nutzerdaten synchron halten, so sind keine weiteren Einstellungen nötig.\\ | + | * User-Synchronisierung |
- | 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!!! | + | * User-Deprovisionierung |
- | Will man Queries ausschließlich zur User-Deprovisionierung benutzen, so kann man sämtliche anderen Attribute für diesen Kanal deaktivieren.\\ | + | Möchte |
- | Dies bringt unter anderem folgende Vorteile mit sich: | + | |
- | * Minimierung der openLDAP Abfragen | + | |
- | * Lastminimierung bei scripted Attributes | + | |
- | * Datenschutz + Datensparsamkeit! | + | |
- | Dazu laden wir uns zunächst folgende JAR-File [[https:// | + | 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: |
- | Anschließend den IdP neubauen. | + | |
+ | * Minimierung der openLDAP Abfragen | ||
+ | * Lastminimierung bei scripted Attributes | ||
+ | * Datenschutz + Datensparsamkeit! | ||
+ | |||
+ | Dazu laden wir uns zunächst folgende JAR-File [[https:// | ||
+ | Anschließend den IdP neubauen. | ||
< | < | ||
+ | |||
# ./ | # ./ | ||
+ | |||
</ | </ | ||
- | 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** |
- | 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**, | + | |
<file xml conf/ | <file xml conf/ | ||
< | < | ||
- | <!-- condition is true if request is NOT an attribute-query --> | + | |
- | <bean id=" | + | <bean id=" |
- | < | + | < |
- | < | + | < |
- | <ref bean=" | + | <ref bean=" |
- | </ | + | </ |
- | </ | + | </ |
- | </ | + | </ |
- | <!-- condition is true if request is NOT an attribute-query and if sp is one of the following --> | + | |
- | <bean id=" | + | <bean id=" |
- | < | + | < |
- | < | + | < |
- | <ref bean=" | + | <ref bean=" |
- | <bean parent=" | + | <bean parent=" |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | < | + | < |
- | </ | + | </ |
- | </ | + | </ |
- | </ | + | </ |
- | </ | + | </ |
- | </ | + | </ |
- | </ | + | </ |
- | <!-- condition is true if request IS an attribute-query and if sp consumes the persistentId --> | + | |
- | <bean id=" | + | <bean id=" |
- | < | + | < |
- | < | + | < |
- | <ref bean=" | + | <ref bean=" |
- | <ref bean=" | + | <ref bean=" |
- | </ | + | </ |
- | </ | + | </ |
- | </ | + | </ |
< | < | ||
+ | |||
+ | |||
</ | </ | ||
- | Nun aktivieren wir die Bedingungen im Resolver.\\ | + | Nun aktivieren wir die Bedingungen im Resolver. \\ Dadurch werden **normale** |
- | 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/ | <file xml conf/ | ||
< | < | ||
- | # Die Angabe einer ActivationCondition an einem normalen Attribut führt leider nicht dazu, dass die LDAP-Abfragen nur gestellt werden, wenn der SP in der Condition steht | + | |
- | # Sondern: | + | # Sondern: |
- | # - Das Attribut wird erst gebaut (LDAP-Abfrage) und erst danach greift die Condition und regelt die Weitergabe des Attributs an die Filter | + | # - Das Attribut wird erst gebaut (LDAP-Abfrage) und erst danach greift die Condition und regelt die Weitergabe des Attributs an die Filter |
- | # - Die Condition MUSS daher an die LDAP-Dependency (DataConnector) gehangen werden, um die Ausführung der LDAP-Anfragen zu steuern/ | + | # - Die Condition MUSS daher an die LDAP-Dependency (DataConnector) gehangen werden, um die Ausführung der LDAP-Anfragen zu steuern/ |
- | < | + | |
- | < | + | < |
- | < | + | < |
- | </ | + | </ |
- | < | + | |
- | < | + | < |
- | </ | + | </ |
- | # Bei Attributen, die zusätzliche Conditions erhalten sollen können diese direkt am Attribut referenziert werden | + | |
- | < | + | |
- | < | + | < |
- | < | + | < |
- | </ | + | </ |
- | < | + | |
- | < | + | < |
- | </ | + | </ |
- | < | + | |
- | < | + | < |
- | < | + | < |
- | </ | + | </ |
- | < | + | |
- | < | + | < |
- | </ | + | </ |
< | < | ||
+ | |||
+ | |||
</ | </ | ||
Zusammenfassend hat man somit folgende Punkte realisiert: | Zusammenfassend hat man somit folgende Punkte realisiert: | ||
- | * attributeQueries sind nur für SPs freigeschalten, | ||
- | * wer diese bezieht ist in der activation-conditions.xml unter der bean " | ||
- | * bei einem query soll lediglich das attribut " | + | * attributeQueries sind nur für SPs freigeschalten, |
- | * alle anderen attribute "nur" bei normalen logins | + | * wer diese bezieht ist in der activation-conditions.xml unter der bean " |
- | | + | |
- | * jeder dataConnector erhält eine condition, somit werden z.B. unnötige LDAP-Abfragen vorweg vermieden | + | * bei einem query soll lediglich das attribut |
- | * jedes attribut | + | * alle anderen |
- | | + | * die einschränkungen müssen in der attribute-resolver.xml mittels activationConditionRef realisiert |
- | | + | |
- | =====Wann / Wie oft Queries stellen===== | + | * jeder dataConnector erhält eine condition, somit werden z.B. unnötige LDAP-Abfragen vorweg vermieden |
+ | * jedes attribut welches nur von einem dataconnector abhängt braucht nicht unbedingt eine weitere condition | ||
+ | * lediglich attribute die von keinem connector oder von anderen attributen (ohne connector) abhängen benötigen eine zusätzliche condition | ||
+ | * teils verknüpfung mehrerer bedingungen bei den conditions da einige attribute z.B. nur an bestimmte SPs ausgeliefert werden | ||
+ | |||
+ | ===== Wann / Wie oft Queries stellen ===== | ||
Wann und wie oft sollten Queries gestellt werden? | Wann und wie oft sollten Queries gestellt werden? | ||
- | Zunächst vorweg:\\ | + | Zunächst vorweg: \\ **Der SP ist verantwortlich** |
- | **Der SP ist verantwortlich** dafür Sorge zu tragen, dass der IdP während seines Betriebes **nicht gestört** wird, in dem er z.B. mit zu vielen Anfragen " | + | |
Daher empfiehlt es sich Nutzer nur dann zu prüfen wenn folgende Bedingungen erfüllt sind: | Daher empfiehlt es sich Nutzer nur dann zu prüfen wenn folgende Bedingungen erfüllt sind: | ||
- | * letzter login > x Tage | ||
- | * letzte Prüfung > x Tage | ||
- | 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: | + | |
- | Am Besten man nutzt also eine Cachefile, in der man hinterlegt, wann der Nutzer das letzte Mal erfolgreich abgefragt wurde.\\ | + | Desweiteren sollte man **kleine Pausen zwischen einzelnen Queries** |
- | Es ist also **nicht notwendig** und **nicht emfehlenswert** jeden Nutzer jeden Tag zu prüfen! | + | |
+ | Am Besten man nutzt also eine Cachefile, in der man hinterlegt, wann der Nutzer das letzte Mal erfolgreich abgefragt wurde. \\ Es ist also **nicht notwendig** | ||
Vorteile: | Vorteile: | ||
- | * man minimiert die Anzahl an Anfragen (und damit die Last auf z.B. den IdP und den LDAP) | ||
- | * man vermeidet DOS-Attacken und eventuelle Sperrung via Fail2Ban | ||
- | * man gewährleistet, | ||
- | Alternativ besteht vielleicht die Möglichkeit einen **separaten IdP** aufzusetzen, | + | * man minimiert die Anzahl an Anfragen (und damit die Last auf z.B. den IdP und den LDAP) |
- | Dabei sollte sichergestellt sein, dass alle IdP-Server via **Datenbank-Replikation** den gleichen Datenbestand aufweisen!!! | + | * man vermeidet DOS-Attacken und eventuelle Sperrung via Fail2Ban |
+ | * man gewährleistet, | ||
+ | |||
+ | Alternativ besteht vielleicht die Möglichkeit einen **separaten IdP** aufzusetzen, | ||
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) | ||
- | =====Links / Dokumentation===== | + | ===== Links / Dokumentation ===== |
- | | + | |
- | | + | * [[de: |
- | | + | |
- | | + | * [[https:// |
- | | + | * [[https:// |
+ | * [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/ | ||
+ | * [[https:// | ||
+ | |||
+ | {{tag> | ||
+ |