← Secret Key-Management  
 Produktivbetrieb →

Konfiguration des Verschlüsselungsalgorithmus

Inhaltsverzeichnis

Ab Shibboleth IdP 3.4 wurde eine Einstellung aufgenommen, mit der der Algorithmus eingestellt werden kann, mit dem die Assertions verschlüsselt werden. Der alte Standard-Algorithmus AES-CBC gilt nicht mehr als sicher, daher ist bei neu installierten IdPs ab Version 4.x die Voreinstellung AES-GCM.

Problem

Einige Nicht-Shibboleth-Service Provider können mit dem aktuell als sicher betrachteten Algorithmus AES-GCM noch nicht umgehen.

Als IdP-Betreiber*in müssen Sie sich daher überlegen, welchen Weg Sie beschreiten wollen:

  1. Sie können - unabhängig von dem globalen Setting Ihres IdPs - verschiedene SAML-Profile anlegen, in denen Sie den jeweiligen Algorithmus explizit mitgeben. Dies geht in beide Richtungen:
    • Bei globaler Verwendung des sicheren Algorithmus können Sie Ausnahmen für SPs konfigurieren, bei denen noch AES-CBC verwendet werden soll(empfohlen).
    • Bei globaler Verwendung des unsicheren Algorithmus können Sie Ausnahmen für solche SPs definieren, die bereits AES-GCM sprechen.
  2. Grundsätzlich könnten die jeweils unterstützten Verschlüsselungsalgorithmen auch in den IdP-/SP-Metadaten über ein entsprechendes Element (<EncryptionMethod>) deklariert werden. Der Shibboleth IdP ist z.B. anhand dieser Angabe in der Lage, eine Assertion gemäß AES-CBC zu verschlüsseln, auch wenn AES-GCM als Default gesetzt ist. Bislang wird dieses Element noch nicht von der DFN-AAI Metadatenverwaltung unterstützt. Wir arbeiten daran, die Metadatenverwaltung entsprechend zu erweitern. In den von der DFN-AAI verteilten eduGAIN-Metadaten ist das Element <EncryptionMethod> bereits fallweise enthalten und wird von IdPs dann auch ausgewertet (z.B. bei cat.eduroam.org).
  3. Sie können global auf den unsicheren Algorithmus zurückgehen, in dem Bewusstsein, dass die Verschlüsselung angreifbar ist (nicht empfohlen).

Liste betroffener Service Provider

Wir bemühen uns, die Liste der diesbezüglichen Entity IDs möglichst aktuell zu halten. Hinweise an hotline@aai.dfn.de sind sehr willkommen!

Standard-Algorithmen in den Versionen ab 3.4

Algorithmus global setzen

In der Datei ./conf/idp.properties gibt es eine neue Einstellung, um global, also für alle Service Provider, die Verwendung eines einheitlichen Verschlüsselungsalgorithmus festzulegen. (Verwenden Sie nur eine der beiden Zeilen!)

./conf/idp.properties
# alter Algorithmus AES-CBC:
idp.encryption.config=shibboleth.EncryptionConfiguration.CBC
# oder neuer Algorithmus AES-GCM:
idp.encryption.config=shibboleth.EncryptionConfiguration.GCM

Algorithmus pro Profil setzen

Die folgenden zwei Beispiele zeigen, wie Sie für einen oder mehrere SPs den alten Algorithmus erlauben (Quelle: Shibboleth Wiki).

Entity IDs

./conf/relying-party.xml
<util:list id="shibboleth.RelyingPartyOverrides">
 
  <bean parent="RelyingPartyByName" c:relyingPartyIds="#{{'HIER-DIE-ENTITYID-EINES-SP', 'ENTITYID-EINES-WEITEREN-SP', '...usw....'}}">
    <property name="profileConfigurations">
      <list>
        <bean parent="SAML2.SSO" p:securityConfiguration-ref="shibboleth.SecurityConfiguration.CBC" />
        <bean parent="SAML2.ECP" p:securityConfiguration-ref="shibboleth.SecurityConfiguration.CBC" />
        <bean parent="SAML2.Logout" p:securityConfiguration-ref="shibboleth.SecurityConfiguration.CBC" />
        <bean parent="SAML2.AttributeQuery" p:securityConfiguration-ref="shibboleth.SecurityConfiguration.CBC" />
        <bean parent="SAML2.ArtifactResolution" p:securityConfiguration-ref="shibboleth.SecurityConfiguration.CBC" />
      </list>
    </property>
  </bean>
 
</util:list>

Entity Category

Hier ein Beispiel, bei dem die abweichende Profil-Konfiguration über die Entity Category http://aai.dfn.de/category/no-aes-gcm-support gesteuert wird. Die Zuordnung zu dieser Entity Category wird zentral über eine Liste gesteuert, die die o.g. Entity IDs enthält. Hierbei werden auch SPs erfasst, die über die eduGAIN Downstream-Metadaten in die DFN-AAI kommen.
Die sonstigen Einstellungen/Parameter müssen den lokalen Bedürfnissen bzw. Gegebenheiten angepasst werden!

./conf/relying-party.xml
<util:list id="shibboleth.RelyingPartyOverrides">
 
  <bean parent="RelyingPartyByTag">
    <constructor-arg name="candidates">
      <list>
        <bean parent="TagCandidate" c:name="http://macedir.org/entity-category"
              p:values="http://aai.dfn.de/category/no-aes-gcm-support"/>
      </list>
    </constructor-arg>
    <property name="profileConfigurations">
      <list>
        <bean parent="SAML2.SSO"
          p:securityConfiguration-ref="shibboleth.SecurityConfiguration.CBC"
          p:postAuthenticationFlows="#{ {'terms-of-use', 'attribute-release'} }"
          p:nameIDFormatPrecedence="#{ {'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'} }" />
        <bean parent="SAML2.Logout" p:securityConfiguration-ref="shibboleth.SecurityConfiguration.CBC"/>
        <bean parent="SAML2.ArtifactResolution" p:securityConfiguration-ref="shibboleth.SecurityConfiguration.CBC"/>
      </list>
    </property>
  </bean>
 
</util:list>

Algorithmus pro Profil setzen, Variante

Der Algorithmus kann im IDP 5.x auch in der metadata-providers.xml Datei gesetzt werden. In manchen Konfigurationen kann das zur Übersichtlichkeit beitragen, z.B. wenn die relying-party.xml sowieso schon umfangreich ist.

./conf/metadata-providers.xml
<!-- Metadaten aller SPs der DFN-AAI Produktivföderation -->
<MetadataProvider id="DFN_AAI"
                xsi:type="FileBackedHTTPMetadataProvider"
                backingFile="%{idp.home}/metadata/DFN-AAI-sp-metadata.xml"
                metadataURL="https://www.aai.dfn.de/metadata/dfn-aai-sp-metadata.xml"
                maxRefreshDelay="PT2H">
 
	<MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
	                certificateFile="%{idp.home}/credentials/dfn-aai.g2.pem"/>
 
	<MetadataFilter xsi:type="Algorithm">
		<md:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
		<Entity>https://auth.brockhaus.de/samlauth</Entity>
                <Entity>https://auth.brockhaus.at/samlauth</Entity>
                <Entity>https://citaviweb.citavi.com/shibboleth</Entity>
                <Entity>https://www.degruyter.com/shibboleth</Entity>
                <Entity>https://dropbox.com/sp</Entity>
		<Entity>https://fiori.fhhrz.net</Entity>
                <Entity>https://test-fiori.fhhrz.net</Entity>
		<Entity>https://shibboleth.highwire.org/entity/secure-sp</Entity>
		<Entity>https://elibrary.hirzel.de</Entity>
                <Entity>https://elibrary.hogrefe.de</Entity>
		<Entity>https://ticket.iop.org/shibboleth</Entity>
                <Entity>https://login.rlp.net/adfs/services/trust</Entity>
		<Entity>https://meiner-elibrary.de</Entity>
		<Entity>https://secure.nature.com/shibboleth</Entity>
		<Entity>https://www.service4mobility.com/europe</Entity>
		<Entity>https://elibrary.steiner-verlag.de</Entity>
		<Entity>https://prd.thieme.de/shibboleth-sp</Entity>
		<Entity>https://sp.tshhosting.com/shibboleth</Entity>
		<Entity>https://sp.onlinelibrary.wiley.com/shibboleth</Entity>
        </MetadataFilter>           
 
</MetadataProvider>

Die Reihenfolge der <MetadataFilter/> ist hierbei wichtig. <MetadataFilter/> vom Typ „SignatureValidation“ müssen immer vor <MetadataFilter/> vom Typ „Algorithm“ definiert werden.

Verwendeten Algorithmus im IdP-Log nachvollziehen

Ein neu installierter IdP 5.x loggt den verwendeten Algorithmus ins idp-audit.log:

idp-audit.log
127.0.0.2|2020-11-25T09:18:42.067973Z|2020-11-25T09:18:53.319425Z|pingel|https://sp2.local/shibboleth|_f3f9070c525b2e7898b61e4a9c0e3a4b|password|2020-11-25T09:18:47.055896Z|eduPersonEntitlement,samlSubjectID,samlPairwiseID,mail,eduPersonScopedAffiliation|||false|false|AES128-GCM|Redirect|POST||Success||759afa9ead212d7d7f928be18669ff55af4009d6309491145bfcd8c74c5200d8|Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0

Um dieses Logging-Verhalten auch in einem von 3.x aktualisierten IdP zu bekommen, können Sie die Datei conf/audit.xml durch die Datei dist/conf/audit.xml ersetzen.

Außerdem loggt der IdP im Loglevel DEBUG für idp.loglevel.messages die verschlüsselten Assertions. Dort finden Sie den verwendeten Algorithmus (Ausschnitt gekürzt):

idp-process.log
[...]
<saml2:EncryptedAssertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#aes128-gcm" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/>

Unterstützte Algorithmen am SP prüfen

Bei Shibboleth SPs finden Sie die Liste der unterstützten Verschlüsselungsalgorithmen über den Metadata Handler (/Shibboleth.sso/Metadata) in den Elementen namens <EncryptionMethod>.

Bei anderen SP-Implementierungen existieren i.d.R. ähnliche Mechanismen. Ansonsten hilft ein Blick in die Dokumentation der betreffenden SP-Software oder eine Anfrage beim Customer Support des Herstellers bzw. Plattformbetreibers.

, , , , ,
← Secret Key-Management  
Überblick: Tutorial zur IdP-Inbetriebnahme  
 Produktivbetrieb →