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 [2025/05/01 18:04] Raoul Gunnar Boreniusde:shibidp:config-extensions-oidc [2025/09/08 10:35] (aktuell) – [Attribute / Claims] IdPv3-Syntax entfernt Doreen Liebenau
Zeile 9: Zeile 9:
 ===== Installation der Plugins ===== ===== Installation der Plugins =====
  
-  vgl. https://wiki.shibboleth.net/confluence/display/IDPPLUGINS/OIDC+OP +Folgende Plugins werden benötigt:  
-  * vgl. https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1294074003/PluginInstallation+**Plugin** | **Plugin ID** | 
 +|[[https://shibboleth.atlassian.net/wiki/x/BIERUg|OIDC Common components]]| net.shibboleth.oidc.common| 
 +|[[https://shibboleth.atlassian.net/wiki/x/DQDHv|IdP OIDC/OAuth Shared Configuration]]| net.shibboleth.idp.plugin.oidc.config| 
 +|[[https://shibboleth.atlassian.net/wiki/x/gIERUg|OIDC OP Extension]] | net.shibboleth.idp.plugin.oidc.op|
  
-Kündigen Sie eine Wartung des IdP an, da durch die Installation der Idp kurzzeitig nicht funktionsfähig ist!+Eine ausführliche Anleitung zur Plugin-Installation finden Sie im [[https://shibboleth.atlassian.net/wiki/x/kIG0vg|Shibboleth-Wiki]].  
 + 
 +Denken Sie daran eine Wartung des IdP anzukündigen, da durch die Installation der IdP kurzzeitig nicht funktionsfähig ist!
  
 ==== IdP 5.x.x ==== ==== IdP 5.x.x ====
Zeile 18: Zeile 23:
 <code bash> <code bash>
 root@idp:/opt/shibboleht-idp$ bin/plugin.sh -I net.shibboleth.oidc.common root@idp:/opt/shibboleht-idp$ bin/plugin.sh -I net.shibboleth.oidc.common
-bin/plugin.sh -I net.shibboleth.idp.plugin.oidc.config +root@idp:/opt/shibboleht-idp$ bin/plugin.sh -I net.shibboleth.idp.plugin.oidc.config 
-bin/plugin.sh -I net.shibboleth.idp.plugin.oidc.op+root@idp:/opt/shibboleht-idp$ bin/plugin.sh -I net.shibboleth.idp.plugin.oidc.op
 </code> </code>
  
Zeile 160: Zeile 165:
  
 Um die "Metadaten", also die Konfigurationsparameter, unter ''https://idp.example.org/.well-known/openid-configuration'' bereitzustellen, gehen Sie so vor (vgl. auch [[https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879256/OPDiscovery|OPDiscovery]] im Shibboleth-Wiki):  Um die "Metadaten", also die Konfigurationsparameter, unter ''https://idp.example.org/.well-known/openid-configuration'' bereitzustellen, gehen Sie so vor (vgl. auch [[https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879256/OPDiscovery|OPDiscovery]] im Shibboleth-Wiki): 
-  * In der mitgelieferten Datei ''/opt/shibboleth-idp/static/openid-configuration.json'' muss jeweils ''<nowiki>{{ service_name }}</nowiki>'' durch Ihren Wert für ''idp.example.org'' ausgetauscht werden. (Ja, muss es. Das ist kein Jinja-Template.) In derselben Datei sollten Sie nicht unterstützte Scopes aus dem Abschnitt ''scopes_supported'' entfernen. +  * In der mitgelieferten Datei ''/opt/shibboleth-idp/static/openid-configuration.json'' muss der Platzhalter ''**<nowiki>{{ service_name }}</nowiki>**'' durch den Hostnamen Ihres IdPs (''idp.uni-something.de''ausgetauscht werden so dass in der Datei an allen Stellen des Platzhalters gültige URLs Ihres IdPs entstehen. (Ja, muss es. Das ist kein Jinja-Template.) In derselben Datei sollten Sie nicht unterstützte Scopes aus dem Abschnitt ''scopes_supported'' entfernen. 
-  * Dann müssen Sie für unverifizierte Relying Parties ein Profil freischalten:<file xml /opt/shibboleth-idp/conf/relying-party.xml>...+  * dann müssen Sie für unverifizierte Relying Parties ein Profil freischalten. Die vorhandene Bean-Definition wird wie folgt ergänzt:<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 222: Zeile 227:
 Da die OIDC-Clients (Relying Parties, RP) ja derzeit noch nicht aus Föderationsmetadaten kommen, werden sie über statische XML-Metadaten hinzugefügt (vgl. Da die OIDC-Clients (Relying Parties, RP) ja derzeit noch nicht aus Föderationsmetadaten kommen, werden sie über statische XML-Metadaten hinzugefügt (vgl.
 [[https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879133/OPMetadataClientRegistration|OPMetadataClientRegistration]] und [[https://shibboleth.atlassian.net/wiki/spaces/SC/pages/1912406916/OAuthRPMetadataProfile|OAuthRPMetadataProfile]] im Shibboleth-Wiki). Sie gehen dabei genau so bzw. so ähnlich vor, wie Sie sonst auch Metadata Provider hinzufügen. Von den Betreiber*innen der RP benötigen Sie mindestens folgende Werte: [[https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1376879133/OPMetadataClientRegistration|OPMetadataClientRegistration]] und [[https://shibboleth.atlassian.net/wiki/spaces/SC/pages/1912406916/OAuthRPMetadataProfile|OAuthRPMetadataProfile]] im Shibboleth-Wiki). Sie gehen dabei genau so bzw. so ähnlich vor, wie Sie sonst auch Metadata Provider hinzufügen. Von den Betreiber*innen der RP benötigen Sie mindestens folgende Werte:
-  * eine Client ID (im Beispiel https://rp.example.org)+  * eine Client ID (im Beispiel https://rp.example.org) - **Achtung:** Manche Clients sind nicht in der Lage, bei BasicAuth den Doppelpunkt im ''https:'' zu escapen! In diesem Fall das https-Präfix weglassen.
   * das Client Secret   * das Client Secret
   * die Redirect URI für den Callback   * die Redirect URI für den Callback
  
-== Option 1: xml-Metadaten ==+**Option 1: xml-Metadaten** \\
  
 <file xml /opt/shibboleth-idp/conf/metadata-providers.xml><MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" <file xml /opt/shibboleth-idp/conf/metadata-providers.xml><MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider"
Zeile 290: Zeile 295:
  
  
-== Option 2: JSON-Metadaten ==+**Option 2: JSON-Metadaten** \\ 
 Um die RP-Metadaten um JSON-Format einzubinden, hinterlegen Sie eine entsprechende Datei mit den Angaben zu einer oder auch gleich mehreren Relying Parties:<file json /opt/shibboleth-idp/metadata/oidc-client.json>[ Um die RP-Metadaten um JSON-Format einzubinden, hinterlegen Sie eine entsprechende Datei mit den Angaben zu einer oder auch gleich mehreren Relying Parties:<file json /opt/shibboleth-idp/metadata/oidc-client.json>[
     {     {
Zeile 459: Zeile 465:
 </file> </file>
  
-=== 2. Syntax IdP 3.x === 
- 
-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, inkl. der Namespace-Deklaration im allerersten Absatz:<file xml /opt/shibboleth-idp/conf/attribute-resolver.xml><?xml version="1.0" encoding="UTF-8"?> 
-<AttributeResolver 
-        xmlns="urn:mace:shibboleth:2.0:resolver"  
-        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
-        xmlns:oidc="urn:mace:shibboleth:2.0:resolver:oidc" 
-        xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd 
-                            urn:mace:shibboleth:2.0:resolver:oidc http://shibboleth.net/schema/oidc/shibboleth-attribute-encoder-oidc.xsd"> 
-... 
-    <!-- OIDC subjects --> 
-    <AttributeDefinition id="subject-public" xsi:type="Simple" 
-            activationConditionRef="shibboleth.oidc.Conditions.PublicRequired"> 
-        <InputDataConnector ref="myLDAP" attributeNames="uid" /> 
-        <AttributeEncoder xsi:type="oidc:OIDCString" name="sub" /> 
-    </AttributeDefinition> 
- 
-    <AttributeDefinition id="subject-pairwise" xsi:type="Simple" 
-            activationConditionRef="shibboleth.oidc.Conditions.PairwiseRequired"> 
-        <InputDataConnector ref="myStoredId" attributeNames="persistentId"/> 
-        <AttributeEncoder xsi:type="oidc:OIDCString" name="sub" /> 
-    </AttributeDefinition> 
-... 
-</file> 
- 
-In Datei ''/opt/shibboleth-idp/conf/attribute-filter.xml'' weitere Attribute analog zu ''/opt/shibboleth-idp/conf/examples/oidc-attribute-filter.xml'' ergänzen:<file xml /opt/shibboleth-idp/conf/attribute-filter.xml>... 
-    <!-- OIDC scopes --> 
-    <AttributeFilterPolicy id="OPENID_SCOPE"> 
-        <PolicyRequirementRule xsi:type="oidc:OIDCScope" value="openid" /> 
-        <AttributeRule attributeID="subject-public"> 
-            <PermitValueRule xsi:type="ANY" /> 
-        </AttributeRule> 
-        <AttributeRule attributeID="subject-pairwise"> 
-            <PermitValueRule xsi:type="ANY" /> 
-        </AttributeRule> 
-    </AttributeFilterPolicy> 
- 
-    <AttributeFilterPolicy id="OPENID_SCOPE_EMAIL"> 
-        <PolicyRequirementRule xsi:type="oidc:OIDCScope" value="email" /> 
-        <AttributeRule attributeID="mail"> 
-            <PermitValueRule xsi:type="ANY" /> 
-        </AttributeRule> 
-        <AttributeRule attributeID="email_verified"> 
-            <PermitValueRule xsi:type="ANY" /> 
-        </AttributeRule> 
-    </AttributeFilterPolicy> 
- 
-    <AttributeFilterPolicy id="OPENID_SCOPE_PROFILE"> 
-        <PolicyRequirementRule xsi:type="oidc:OIDCScope" value="profile" /> 
-        <AttributeRule attributeID="displayName"> 
-            <PermitValueRule xsi:type="ANY" /> 
-        </AttributeRule> 
-        <AttributeRule attributeID="sn"> 
-            <PermitValueRule xsi:type="ANY" /> 
-        </AttributeRule> 
-        <AttributeRule attributeID="givenName"> 
-            <PermitValueRule xsi:type="ANY" /> 
-        </AttributeRule> 
-        <AttributeRule attributeID="uid"> 
-            <PermitValueRule xsi:type="ANY" /> 
-        </AttributeRule> 
-        <AttributeRule attributeID="gender"> 
-            <PermitValueRule xsi:type="ANY" /> 
-        </AttributeRule> 
-        <AttributeRule attributeID="eduPersonPrincipalName"> 
-            <PermitValueRule xsi:type="ANY" /> 
-        </AttributeRule> 
-    </AttributeFilterPolicy> 
-...</file> 
  
 ==== Token-Verschlüsselung ==== ==== Token-Verschlüsselung ====
Zeile 591: Zeile 526:
   * ''idp-process.log'' lesen. [[de:shibidp:troubleshooting#grundsaetzliche_vorgehensweise_bei_der_fehlersuche|DEBUG]]-Loglevel anschalten.   * ''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.)   * ''InvalidProfileConfiguration''-Fehler? -> ''conf/relying-party.xml'' muss korrigiert werden (s.o.)
 +  * Fehler bei der Client-Authentifizierung mittels BasicAuth, ''client_id'' und ''client_secret'' - manche Clients (u.a. Keycloak) sind nicht in der Lage, den Doppelpunkt im https: zu escapen! In diesem Fall das https-Präfix entfernen (OP- und Client-seitig)
   * standardisierte RequestURI abfragen:<code bash>curl -I https://idp.example.org/.well-known/openid-configuration   * standardisierte RequestURI abfragen:<code bash>curl -I https://idp.example.org/.well-known/openid-configuration
 HTTP/1.1 303 See Other HTTP/1.1 303 See Other
  • Zuletzt geändert: vor 6 Monaten