Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp:config-ecp [2020/04/14 14:27] – Silke Meyer
+++ de:shibidp:config-ecp [2023/03/02 14:40] (aktuell) – Silke Meyer
@@ Zeile 1: / Zeile 1: @@
 ====== Enhanced Client or Proxy (ECP) ======
-Die grundlegenden [[https://wiki.shibboleth.net/confluence/display/CONCEPT/ECP|Konzepte]] und die FIXME [[https://wiki.shibboleth.net/confluence/display/IDP30/ECPConfiguration|Konfiguration von ECP]] sind im Shibboleth Wiki dokumentiert.
+Die ECP-Schnittstelle eines IdP ist für die Kommunikation mit nicht-browserbasierten Clients da. Das grundlegende [[https://wiki.shibboleth.net/confluence/display/CONCEPT/ECP|Konzept]] ist im Shibboleth Wiki dokumentiert. ECP ist im Shibboleth-IdP standardmäßig aktiv.
-ECP ist im IdP 3.x out-of-the box aktiv.
 Achten Sie darauf, dass das ECP-SSO-Binding des IdPs in den DFN-AAI-Metadaten angegeben ist. Fehlt es, finden ECP-Clients den IdP nicht, wenn Sie sich anmelden wollen.
-{{de:ecp.png}}
+{{de:ecp.png|400}}
 Zum Testen eignet sich das vom CILogon Projekt bereitgestellte [[http://www.cilogon.org/ecp#TOC-A-Basic-ECP-IdP-Test-Script|Testscript 'testecp.sh']].
-Ob die IdP-seitigen Voreinstellungen für den ECP-Support ausreichen, hängt letztlich vom Verhalten der eingesetzten Clients ab, siehe hierzu die [[https://wiki.shibboleth.net/confluence/display/IDP30/PasswordAuthnConfiguration#PasswordAuthnConfiguration-UserInterface|Dokumentation im Shibboleth Wiki]].
-<callout type="danger" title="Schutz mit Basic-Auth nötig">
+<callout color="#ff9900" title="Schutz mit Basic-Auth nötig">
-Viele Sync&Share-Clients kommen mit der ECP-Variante des Shibboleth IdP leider nicht zurecht. Der ECP-Endpunkt muss für diese Clients noch explizit mit Basic-Auth geschützt werden. Dies kann mithilfe von Apache oder Tomcat gemacht werden - einfacher ist die Apache-Variante.
+Viele Sync&Share-Clients kommen mit der ECP-Variante des Shibboleth IdP leider nicht zurecht. Der ECP-Endpunkt muss für diese Clients noch explizit mit Basic-Auth geschützt werden. Dies kann mithilfe von **Apache oder Tomcat** gemacht werden - einfacher ist die Apache-Variante.
 </callout>
-===== ECP-Endpunkt mit Apache Basic-Auth schützen =====
+===== Entweder: ECP-Endpunkt mit Apache Basic-Auth schützen =====
 Authentifizierung per LDAP im Apache aktivieren:
@@ Zeile 49: / Zeile 47: @@
 </file>
-===== ECP-Endpunkt mit Tomcat Basic-Auth schützen =====
+===== Oder: ECP-Endpunkt mit Tomcat Basic-Auth schützen =====
+FIXME prüfen!
 Wir empfehlen, die ECP-Schnittstelle über den Webserver zu schützen, wenn dies in Ihrer Umgebung möglich ist.
-**1. web.xml** (unter /edit-webapp/WEB-INF bearbeiten): \\
+Zunächst aktivieren Sie folgende Blöcke in ''./edit-webapp/WEB-INF/web.xml'':
-Die beiden Blöcke am Ende ent-kommentieren: "Uncomment to use container managed
-authentication" und "Uncomment if you want BASIC auth managed by the container"
-**2. Context Fragment in Tomcat-Konfiguration anpassen.** \\
+<file xml ./edit-webapp/WEB-INF/web.xml>
-Das sieht dann ungefähr so aus (appName, Pfade etc. ggf. anpassen):
+    ...
+    <!--
+    Uncomment to use container managed authentication. The new servlet spec (3.1)
+    supports "**" as a wildcard syntax to avoid role usage, which is normally desirable.
+    Older containers usually support "*" when proprietary options are used (e.g., Jetty
+    requires setting the Strict property on the SecurityManager.)
+    -->
+    <security-constraint>
+        <display-name>Web Login Service</display-name>
+        <web-resource-collection>
+            <web-resource-name>user authentication</web-resource-name>
+            <url-pattern>/Authn/RemoteUser</url-pattern>
+            <url-pattern>/profile/SAML2/SOAP/ECP</url-pattern>
+            <http-method>POST</http-method>·
+        </web-resource-collection>
+        <auth-constraint>
+            <role-name>**</role-name>
+        </auth-constraint>
+        <user-data-constraint>
+            <transport-guarantee>CONFIDENTIAL</transport-guarantee>·
+        </user-data-constraint>
+    </security-constraint>
-<file xml /etc/tomcat8/Catalina/localhost/idp.xml>
+    <!-- Uncomment if you want BASIC auth managed by the container. -->
+    <login-config>
+        <auth-method>BASIC</auth-method>
+        <realm-name>Web Login Service</realm-name>
+    </login-config>
+    ...
+</file>
+Passen Sie das Context Fragment in der Tomcat-Konfiguration an. Das sieht dann ungefähr so aus (appName, Pfade etc. ggf. anpassen):
+<file xml /etc/tomcat9/Catalina/localhost/idp.xml>
 <Context docBase="/opt/shibboleth-idp/war/idp.war"
          privileged="true"
@@ Zeile 70: / Zeile 99: @@
 </file>
-**3. Tomcat den Pfad zur JAAS login.config als Startparameter mitgeben** (unter Debian in
+Geben Sie Tomcat den Pfad zur JAAS login.config als Startparameter mit:
-/etc/default/tomcat8):
-<file bash /etc/default/tomcat8>
+<file bash /etc/default/tomcat9>
-JAVA_OPTS=" ... -Djava.security.auth.login.config=file:/opt/shibboleth-idp/login.config
+JAVA_OPTS=" ... -Djava.security.auth.login.config=file:/opt/shibboleth-idp/login.config ..."
-..."
 </file>
-**4. /opt/shibboleth-idp/login.config**
+Legen Sie die Datei ''./login.config'' an:
-** ACHTUNG: die Java-Klasse ist eine andere als bei der gewohnten login.config des IdP 2.x !!**
 <file javascript /opt/shibboleth-idp/login.config>
@@ Zeile 96: / Zeile 121: @@
 </file>
+Starten Sie Tomcat neu.
+<callout color="#ff9900" title="Schutz vor Brute-Force">
-<callout type="danger" title="Schutz vor Brute-Force">
 Da dieser Endpunkt weltweit erreichbar sein muss, können hier auch Brute-Force-Passwort-Angriffe auftreten.
 Diesen sollten ebenfalls mithilfe von fail2ban begegnet werden, siehe die [[de:shibidp:fail2ban|fail2ban-Seite]] in diesem Wiki.
@@ Zeile 173: / Zeile 198: @@
 </file>
+{{tag>idp4 ecp syncandshare}}

idp4 ecp syncandshare