Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
de:shibidp:config-extensions-oidc [2023/02/01 17:11] – [Attribute] OIDC Sub Claims für die Registry Silke Meyer | de:shibidp:config-extensions-oidc [2023/05/25 14:47] – [Troubleshooting] Typo Silke Meyer |
---|
====== Shibboleth IdP als OpenID Connect - Provider ====== | ====== Shibboleth IdP als OpenID Connect - Provider ====== |
| |
{{:piktogramm_baustelle.svg |de:Bundesministerium für Verkehr, Bau- und Wohnungswesen (https://commons.wikimedia.org/wiki/File:Piktogramm_Baustelle.svg), „Piktogramm Baustelle“, als gemeinfrei gekennzeichnet, Details auf Wikimedia Commons: https://commons.wikimedia.org/wiki/Template:PD-VzKat}} | |
| |
<callout color="#ff9900" title="Seite wird überarbeitet"> | |
</callout> | |
| |
\\ | |
| |
<callout color="#ff9900" title="Danke"> | <callout color="#ff9900" title="Danke"> |
<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.2.1/idp-plugin-oidc-op-distribution-3.2.1.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.2.1/idp-plugin-oidc-op-distribution-3.2.1.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> |
| |
| |
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"?> |
</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 |
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 |
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 |
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"> |
...</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 === |
</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: |
| |
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" |
...</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: |
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}} |