Konfiguration des Verschlüsselungsalgorithmus

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).

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!

  • IdP 3.4: alter Standard shibboleth.EncryptionConfiguration.CBC
  • upgegradeter IdP 4.x: alter Standard, wenn der Algorithmus nicht manuell hochgesetzt wird
  • neu installierter IdP 4.x: neuer Standard shibboleth.EncryptionConfiguration.GCM

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

Die folgenden zwei Beispiele zeigen, wie Sie für einen oder mehrere IdPs den alten Algorithmus erlauben (Quelle: https://wiki.shibboleth.net/confluence/display/IDP4/SecurityConfiguration).

./conf/relying-party.xml
<util:list id="shibboleth.RelyingPartyOverrides">
 
  <bean parent="RelyingPartyByName" c:relyingPartyIds="HIER-DIE-ENTITYID-DES-SP">
    <property name="profileConfigurations">
      <list>
        <bean parent="Shibboleth.SSO" p:securityConfiguration-ref="shibboleth.SecurityConfiguration.CBC" />
        <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>

Ein Beispiel mit mehreren SP-EntityIDs, mit den Angaben für Post Authentication Flows und NameID-Formate, aber ohne ECP-Schnittstelle und ohne die Erlaubnis für Attribute Queries würde so aussehen:

./conf/relying-party.xml
<util:list id="shibboleth.RelyingPartyOverrides">
 
  <bean parent="RelyingPartyByName" c:relyingPartyIds="#{{'ENTITYID1', 'ENTITYID2', 'ENTITYID3'}}">
    <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>

Der IdP loggt im Loglevel DEBUG u.a. 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#"/>
  • Zuletzt geändert: vor 5 Tagen