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
de:shibidp:config-extensions-oidc [2023/04/25 14:55] – Wartungsbaustein rausgenommen Silke Meyerde:shibidp:config-extensions-oidc [2023/05/25 14:47] (aktuell) – [Troubleshooting] Typo Silke Meyer
Zeile 18: Zeile 18:
 <code bash> <code bash>
 root@idp:~# cd /opt/install/ root@idp:~# cd /opt/install/
-root@idp:~# curl -O https://shibboleth.net/downloads/identity-provider/plugins/oidc-common/2.1.0/oidc-common-dist-2.1.0.tar.gz +root@idp:~# curl -O https://shibboleth.net/downloads/identity-provider/plugins/oidc-common/2.2.0/oidc-common-dist-2.2.0.tar.gz 
-root@idp:~# curl -O https://shibboleth.net/downloads/identity-provider/plugins/oidc-common/2.1.0/oidc-common-dist-2.1.0.tar.gz.asc +root@idp:~# curl -O https://shibboleth.net/downloads/identity-provider/plugins/oidc-common/2.2.0/oidc-common-dist-2.2.0.tar.gz.asc 
-root@idp:~# curl -O https://shibboleth.net/downloads/identity-provider/plugins/oidc-op/3.3.0/idp-plugin-oidc-op-distribution-3.3.0.tar.gz +root@idp:~# curl -O https://shibboleth.net/downloads/identity-provider/plugins/oidc-op/3.4.0/idp-plugin-oidc-op-distribution-3.4.0.tar.gz 
-root@idp:~# curl -O https://shibboleth.net/downloads/identity-provider/plugins/oidc-op/3.3.0/idp-plugin-oidc-op-distribution-3.3.0.tar.gz.asc+root@idp:~# curl -O https://shibboleth.net/downloads/identity-provider/plugins/oidc-op/3.4.0/idp-plugin-oidc-op-distribution-3.4.0.tar.gz.asc 
 +# seit OIDC-OP Plugin-Version 3.4.0 zusätzlich: 
 +root@idp:~# curl -O https://shibboleth.net/downloads/identity-provider/plugins/oidc-config/1.0.1/idp-plugin-oidc-config-dist-1.0.1.tar.gz 
 +root@idp:~# curl -O https://shibboleth.net/downloads/identity-provider/plugins/oidc-config/1.0.1/idp-plugin-oidc-config-dist-1.0.1.tar.gz.asc
 </code> </code>
  
Zeile 28: Zeile 31:
  
 Im IdP <nowiki><=</nowiki> 4.1.2 gibt es einen Bug (vgl. https://issues.shibboleth.net/jira/browse/IDP-1838), hier lässt sich die Kompatibilitäts-Prüfung mittels Parameter ''<nowiki>--nocheck</nowiki>'' umgehen:<code bash> Im IdP <nowiki><=</nowiki> 4.1.2 gibt es einen Bug (vgl. https://issues.shibboleth.net/jira/browse/IDP-1838), hier lässt sich die Kompatibilitäts-Prüfung mittels Parameter ''<nowiki>--nocheck</nowiki>'' umgehen:<code bash>
-root@idp:~# /opt/shibboleth-idp/bin/plugin.sh --nocheck -i oidc-common-dist-1.1.0.tar.gz +root@idp:~# /opt/shibboleth-idp/bin/plugin.sh --nocheck -i /opt/install/oidc-common-dist-2.2.0.tar.gz 
-root@idp:~# /opt/shibboleth-idp/bin/plugin.sh --nocheck -i idp-plugin-oidc-op-distribution-3.0.1.tar.gz</code>+root@idp:~# /opt/shibboleth-idp/bin/plugin.sh --nocheck -i /opt/install/idp-plugin-oidc-config-dist-1.0.1.tar.gz 
 +root@idp:~# /opt/shibboleth-idp/bin/plugin.sh --nocheck -i /opt/install/idp-plugin-oidc-op-distribution-3.4.0.tar.gz</code>
  
 Zur Konfiguration des HTTP-Proxy (IdP >= 4.1.3) müssen wir eine Datei ''/opt/install/beanfile.xml'' mit eigenen HttpClient-Parametern anlegen:<file xml /opt/install/beanfile.xml><?xml version="1.0" encoding="UTF-8"?> Zur Konfiguration des HTTP-Proxy (IdP >= 4.1.3) müssen wir eine Datei ''/opt/install/beanfile.xml'' mit eigenen HttpClient-Parametern anlegen:<file xml /opt/install/beanfile.xml><?xml version="1.0" encoding="UTF-8"?>
Zeile 55: Zeile 59:
 </beans></file> </beans></file>
  
-Und dann mit folgenden Parametern installieren:<code bash>root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -hc myHttpClient -i oidc-common-dist-1.1.0.tar.gz beanfile.xml +Und dann mit folgenden Parametern installieren:<code bash>root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -hc myHttpClient -i oidc-common-dist-2.2.0.tar.gz beanfile.xml 
-root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -hc myHttpClient -i idp-plugin-oidc-op-distribution-3.0.1.tar.gz beanfile.xml</code>+root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -hc myHttpClient -i idp-plugin-oidc-op-distribution-3.4.0.tar.gz beanfile.xml</code>
  
 ==== Installation ohne HTTP-Proxy ==== ==== Installation ohne HTTP-Proxy ====
-<code bash>root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -i oidc-common-dist-1.1.0.tar.gz +<code bash>root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -i /opt/install/oidc-common-dist-2.2.0.tar.gz 
-2021-07-21 11:07:04,309 - INFO [net.shibboleth.idp.installer.plugin.impl.PluginInstaller:233] - Installing Plugin net.shibboleth.oidc.common version 1.1.0 +2021-07-21 11:07:04,309 - INFO [net.shibboleth.idp.installer.plugin.impl.PluginInstaller:233] - Installing Plugin net.shibboleth.oidc.common version 2.2.0 
-Installing Plugin net.shibboleth.oidc.common version 1.1.0+Installing Plugin net.shibboleth.oidc.common version 2.2.0
 2021-07-21 11:07:04,400 - INFO [net.shibboleth.idp.installer.BuildWar:225] - Rebuilding /opt/shibboleth-idp/war/idp.war, Version 4.1.2 2021-07-21 11:07:04,400 - INFO [net.shibboleth.idp.installer.BuildWar:225] - Rebuilding /opt/shibboleth-idp/war/idp.war, Version 4.1.2
 Rebuilding /opt/shibboleth-idp/war/idp.war, Version 4.1.2 Rebuilding /opt/shibboleth-idp/war/idp.war, Version 4.1.2
Zeile 73: Zeile 77:
 Creating war file /opt/shibboleth-idp/war/idp.war</code> Creating war file /opt/shibboleth-idp/war/idp.war</code>
  
-<code bash>root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -i idp-plugin-oidc-op-distribution-3.0.1.tar.gz+<code bash>root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -i /opt/install/idp-plugin-oidc-config-dist-1.0.1.tar.gz 
 +Installing Plugin net.shibboleth.idp.plugin.oidc.config version 1.0.1 
 +Rebuilding /opt/shibboleth-idp/idp2.local/war/idp.war, Version 4.3.1 
 +Initial populate from /opt/shibboleth-idp/idp2.local/dist/webapp to /opt/shibboleth-idp/idp2.local/webpapp.tmp 
 +Overlay from /opt/shibboleth-idp/idp2.local/dist/plugin-webapp to /opt/shibboleth-idp/idp2.local/webpapp.tmp 
 +Overlay from /opt/shibboleth-idp/idp2.local/edit-webapp to /opt/shibboleth-idp/idp2.local/webpapp.tmp 
 +Creating war file /opt/shibboleth-idp/idp2.local/war/idp.war</code> 
 + 
 +<code bash>root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -i /opt/install/idp-plugin-oidc-op-distribution-3.4.0.tar.gz
 Plugin net.shibboleth.idp.plugin.oidc.op: Trust store folder does not exist, creating Plugin net.shibboleth.idp.plugin.oidc.op: Trust store folder does not exist, creating
 Plugin net.shibboleth.idp.plugin.oidc.op: Trust store does not exist, creating Plugin net.shibboleth.idp.plugin.oidc.op: Trust store does not exist, creating
Zeile 82: Zeile 94:
 Username: Henri Mikkonen <henri.mikkonen@iki.fi> Username: Henri Mikkonen <henri.mikkonen@iki.fi>
  [yN] y  [yN] y
-Installing Plugin net.shibboleth.idp.plugin.oidc.op version 3.0.1+Installing Plugin net.shibboleth.idp.plugin.oidc.op version 3.4.0
 Rebuilding /opt/shibboleth-idp/war/idp.war, Version 4.1.2 Rebuilding /opt/shibboleth-idp/war/idp.war, Version 4.1.2
 Initial populate from /opt/shibboleth-idp/dist/webapp to /opt/shibboleth-idp/webpapp.tmp Initial populate from /opt/shibboleth-idp/dist/webapp to /opt/shibboleth-idp/webpapp.tmp
Zeile 165: Zeile 177:
 Aktivieren Sie die entsprechenden OIDC-Profile im Shibboleth IdP, in der Datei ''conf/relying-party.xml''. Um OIDC-Clients manuell hinzuzufügen, fügen Sie in die Abschnitte ''shibboleth.UnverifiedRelyingParty'' und ''shibboleth.DefaultRelyingParty'' folgende Parameter hinzu. Außerdem sollten auch beim OIDC-Login dieselben Flows wie beim SAML-Login berücksichtigt werden, hier die Anzeige der Nutzungsbedingungen und die Abfrage der Zustimmung zur Attributübertragung. Achtung: Wenn Sie weitere Flows unter postAuthenticationFlows eintragen, etwa context-check, dann berücksichtigen Sie dies ggf. beim Debugging! Hier wird nur die Standardkonfiguration beschrieben. Aktivieren Sie die entsprechenden OIDC-Profile im Shibboleth IdP, in der Datei ''conf/relying-party.xml''. Um OIDC-Clients manuell hinzuzufügen, fügen Sie in die Abschnitte ''shibboleth.UnverifiedRelyingParty'' und ''shibboleth.DefaultRelyingParty'' folgende Parameter hinzu. Außerdem sollten auch beim OIDC-Login dieselben Flows wie beim SAML-Login berücksichtigt werden, hier die Anzeige der Nutzungsbedingungen und die Abfrage der Zustimmung zur Attributübertragung. Achtung: Wenn Sie weitere Flows unter postAuthenticationFlows eintragen, etwa context-check, dann berücksichtigen Sie dies ggf. beim Debugging! Hier wird nur die Standardkonfiguration beschrieben.
  
-Datei ''/opt/shibboleth-idp/conf/relying-party.xml'' bearbeiten:<file xml /opt/shibboleth-idp/conf/relying-party.xml>...+  * Bearbeiten Sie die Datei ''/opt/shibboleth-idp/conf/relying-party.xml'':<file xml /opt/shibboleth-idp/conf/relying-party.xml>...
     <bean id="shibboleth.UnverifiedRelyingParty" parent="RelyingParty">     <bean id="shibboleth.UnverifiedRelyingParty" parent="RelyingParty">
         <property name="profileConfigurations">         <property name="profileConfigurations">
Zeile 191: Zeile 203:
 ...</file> ...</file>
  
 +  * Testen Sie dann, ob Sie das Schlüsselmaterial öffentlich oder zumindest von der Relying Party aus abrufen können.<code bash>root@idp:~# curl https://idp.example.org/idp/profile/oidc/keyset</code>
  
 === RP-Metadaten hinterlegen === === RP-Metadaten hinterlegen ===
Zeile 338: Zeile 351:
 </code> </code>
  
-==== Attribute ====+==== Attribute / Claims ====
 Für OIDC sollten eine globale subject-id und/oder eine anwendungsbezogene pairwise-id definiert werden. Nachfolgend zwei Beispiele: Für OIDC sollten eine globale subject-id und/oder eine anwendungsbezogene pairwise-id definiert werden. Nachfolgend zwei Beispiele:
  
Zeile 437: Zeile 450:
 Wenn Sie einen IdP betreiben, der seit Shibboleth 3.x nie neu installiert, sondern immer aktualisiert wurde, dann haben Sie die Attribute Registry möglicherweise noch nicht in Betrieb genommen. Die Transcoding-Regeln für die Attribute werden dann nicht aus der Registry geholt, sondern sie müssen direkt in der Attribut-Definition genannt werden. Eine  Attributdefinition kann dann so aussehen, hier basierend auf den Attributen uid und persistentId: Wenn Sie einen IdP betreiben, der seit Shibboleth 3.x nie neu installiert, sondern immer aktualisiert wurde, dann haben Sie die Attribute Registry möglicherweise noch nicht in Betrieb genommen. Die Transcoding-Regeln für die Attribute werden dann nicht aus der Registry geholt, sondern sie müssen direkt in der Attribut-Definition genannt werden. Eine  Attributdefinition kann dann so aussehen, hier basierend auf den Attributen uid und persistentId:
  
-In der Datei ''/opt/shibboleth-idp/conf/attribute-resolver.xml'' Attribute analog zu ''/opt/shibboleth-idp/conf/examples/oidc-attribute-resolver.xml'' ergänzen:<file xml /opt/shibboleth-idp/conf/attribute-resolver.xml><?xml version="1.0" encoding="UTF-8"?>+In der Datei ''/opt/shibboleth-idp/conf/attribute-resolver.xml'' Attribute analog zu ''/opt/shibboleth-idp/conf/examples/oidc-attribute-resolver.xml'' ergänzen, inkl. der Namespace-Deklaration im allerersten Absatz:<file xml /opt/shibboleth-idp/conf/attribute-resolver.xml><?xml version="1.0" encoding="UTF-8"?>
 <AttributeResolver <AttributeResolver
         xmlns="urn:mace:shibboleth:2.0:resolver"          xmlns="urn:mace:shibboleth:2.0:resolver" 
Zeile 505: Zeile 518:
 ...</file> ...</file>
  
 +==== Token-Verschlüsselung ====
 +Die ID- und UserInfo-Tokens, die bei OIDC 1.0 zum Einsatz kommen, müssen signiert sein und über eine TLS-verschlüsselte Verbindung übertragen werden. Sie darüber hinaus auch noch zu verschlüsseln, ist optional. Wir empfehlen, zunächst ein funktionierendes Setup ohne die optionale Token-Verschlüsselung fertigzustellen und diesen Schritt, so er gewünscht ist, erst dann in Angriff zu nehmen.
  
 +Die Token-Verschlüsselung schalten Sie mit dieser Einstellung von ''conf/oidc.properties'' an:<file properties /opt/shibboleth-idp/conf/oidc.properties># Set false to preclude issuing unencrypted ID/UserInfo tokens without specific overrides
 +# default: idp.oidc.encryptionOptional = true
 +idp.oidc.encryptionOptional = false</file>
 +
 +Das Profil OIDC.SSO in ''conf/relying-party.xml'' muss um die entsprechende Property ergänzt werden:
 +
 +<file xml /opt/shibboleth-idp/conf/relying-party.xml>    <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
 +        <property name="profileConfigurations">
 +            <list>
 +                <bean parent="OIDC.SSO" p:postAuthenticationFlows="#{ {'terms-of-use', 'attribute-release'} }" p:encryptionOptional="false" />
 +                <ref bean="OIDC.UserInfo"/>
 +                <ref bean="OAUTH2.Revocation"/>
 +                <ref bean="OAUTH2.Introspection" />
 +            </list>
 +        </property>
 +    </bean>
 +</file>
 +
 +In einem Setup ohne dynamische Client-Registrierung müssen die hinterlegten RP-Metadaten um Informationen zu Signaturalgorithmen und Schlüsselmaterial ergänzt werden. Bei dynamischer Client-Registrierung sollte eine Relying Party diese Informationen bei der Registrierung selbst an den OP schicken.<file json /opt/shibboleth-idp/metadata/oidc-client.json>[
 +    {
 +        "client_id": "https://rp.example.org",
 +        "client_secret": "HIER-STEHT-EIN-GEHEIMES-SECRET",
 +        "response_types": ["code"],
 +        "grant_types": ["authorization_code"],
 +        "scope": "openid info profile email",
 +        "redirect_uris": ["https://rp.example.org/CALLBACK-ENDPOINT"],
 +        "id_token_signed_response_alg":"RS256",
 +        "id_token_encrypted_response_alg":"RSA1_5",
 +        "id_token_encrypted_response_enc":"A256GCM",
 +        "userinfo_encrypted_response_alg":"RSA1_5",
 +        "userinfo_encrypted_response_enc":"A256GCM",
 +        "jwks_uri": "https://rp.example.org/CALLBACK-ENDPOINT?jwks=rsa"
 +    }
 +]</file>
 +
 +FIXME: Funktionierende Syntax für xml-Metadaten fehlt
 +
 +**Achtung:** Sollten Sie später die Token-Verschlüsselung wieder aus der Konfiguration herausnehmen, achten Sie darauf, dass auf beiden Seiten auch die Informationen zu Signaturalgorithmen und Schlüsselmaterial aus den Metadaten der Gegenstelle entfernt werden müssen, sonst wird weiterhin versucht, die Tokens zu verschlüsseln.
 ===== Weitere Hinweise ===== ===== Weitere Hinweise =====
 Das OIDC-Plugin unterstützt bislang noch kein Logout, und die OIDC-RPs werden auch nicht auf der Logout-Seite angezeigt: Das OIDC-Plugin unterstützt bislang noch kein Logout, und die OIDC-RPs werden auch nicht auf der Logout-Seite angezeigt:
Zeile 516: Zeile 569:
 Ihren OpenID Provider können Sie mit unseren [[de:functionaltest_oidc_op#funktionstest_openid_connect_op|öffentlichen Relying Parties]] testen. Alle unsere Testsysteme sind momentan //nur// für dynamische Client-Registrierung konfiguriert. Ihren OpenID Provider können Sie mit unseren [[de:functionaltest_oidc_op#funktionstest_openid_connect_op|öffentlichen Relying Parties]] testen. Alle unsere Testsysteme sind momentan //nur// für dynamische Client-Registrierung konfiguriert.
  
 +===== Troubleshooting =====
 +FIXME: to be continued...
 +
 +  * ''idp-process.log'' lesen. [[de:shibidp:troubleshooting#grundsaetzliche_vorgehensweise_bei_der_fehlersuche|DEBUG]]-Loglevel anschalten.
 +  * ''InvalidProfileConfiguration''-Fehler? -> ''conf/relying-party.xml'' muss korrigiert werden (s.o.)
 +  * standardisierte RequestURI abfragen:<code bash>curl -I https://idp.example.org/.well-known/openid-configuration
 +HTTP/1.1 303 See Other
 +Location: https://idp.example.org/idp/profile/oidc/configuration</code>
 +  * eigentliche OP-Metadaten abfragen: <code bash>curl -s https://idp.example.org/idp/profile/oidc/configuration</code>
 +  * Schlüsselmaterial des OpenID Connect Providers abfragen:<code bash>curl -s https://idp.example.org/idp/profile/oidc/keyset | python -m json.tool</code>
 +  * Schlüsselmaterial der Relying Party abfragen, URL steht in RP-Metadaten (Datei oder OP-Datenbank):<code bash>curl -s https://rp.example.org/protected/callback?jwks=rsa | python3 -m json.tool</code>
 +  * Fehler bei Generierung eines validen Sub Claims?
 +    * genaue Prüfung der Dateien:
 +    * ''conf/services.xml'' -> Wird die [[de:shibidp:upgrade#umstellung_auf_die_nutzung_der_attribute_registry_optional|Attribute Registry]] benutzt oder nicht? Sind die Sub Claims dann in die Registry importiert?
 +    * Sind sie in ''conf/attribute-resolver.xml'' definiert?
 +    * Ist in ''conf/attribute-resolver.xml'' oben im einleitenden xml-Tag ''<AttributeResolver ...>'' oidc mit drin?
 +    * Freigaberegeln in ''conf/attribute-filter.xml'' prüfen
 +    * Log checken: Welcher Sub Claim wird von der RP angefordert? Haben Sie vielleicht nur den anderen Sub Claim erlaubt?
 {{tag>idp4 openidc oidc extension}} {{tag>idp4 openidc oidc extension}}
  • Zuletzt geändert: vor 13 Monaten