IDP-Konfiguration

Voraussetzungen für den IdP sind die Unterstützung von SAML 2.0, dem ECP und AssertionQuery Profil. Für Shibboleth IdPs wird eine Version ab v2.3.5 empfohlen. Die Installation und grundlegende Konfiguration des IdPs sollte bereits im Rahmen des Beitritts zur DFN-AAI erfolgt sein. Zu folgenden Punkte sind Anpassungen notwendig:

Persistend IDs
Attribute
uApprove
ECP (nicht mehr notwendig)

Persistent IDs

Für den Betrieb eines IdP müssen Persistente IDs aktiviert werden (vgl. DFN-AAI: Einrichten von Persistent IDs). Ziel ist es, im Anwendungsfall für jeden SP einen eindeutigen pseudonymen Identifier zu generieren und in einer Datenbank für zukünftige Zugriffe abzulegen (vgl. Shibboleth Wiki: IdPPersistentNameIdentifier).

Attribute

Die Definition der Attribute für bwIDM orientieren sich an den Spezifikationen der DFN-AAI und können hier eingesehen werden:

Attribute

Dabei unterscheiden wird für bwIDM zwischen einem Kernsatz von Attributen, weiteren optionalen Attributen, sowie dem oben bereits beschriebenen IdPPersistentNameIdentifier. Die Heimatorganisation liefert diese Attribute gemäß dem Standard via bwIDM-Infrastruktur an die angeschlossenen Dienste aus.

Mindestvoraussetzung für die Teilnahme neuer IdPs an bwIDM ist, dass diese zumindest den Kernsatz ausliefern können. Sollen jedoch die Mitglieder einer Heimatorganisation einzelne Landesdienste nutzen können, die ein oder mehrere optionale Attribute anfordern, dann muss der IdP auch dazu in der Lage sein bzw. entsprechend angepasst werden.

Filterregeln für Attribute

Um sicherzustellen, dass an einen SP nur genau die Attribute ausgeliefert werden, die vereinbart worden sind, kann man auf dem IdP entsprechende Attributfilter einrichten. Die dafür notwendigen Informationen finden Sie in der Übersicht der angeschlossenen Dienste.

Außerdem kann man damit die Auslieferung der für bwIDM vereinbarten Attribute auf die Service Provider begrenzen, die Mitglied von bwIDM sind. Dazu wird als Filter-Kriterium die entity category herangezogen. So könnte beispielsweise ein entsprechender Eintrag in der attribute-filter.xml aussehen (die in der Beispielkonfiguration verwendeten attributeID-Angaben müssen mit den Attributkennungen des Resolvers in der attribute-resolver.xml übereinstimmen):

<?xml version="1.0" encoding="UTF-8"?>
<afp:AttributeFilterPolicyGroup id="ShibbolethFilterPolicy"
   xmlns:afp="urn:mace:shibboleth:2.0:afp" xmlns:basic="urn:mace:shibboleth:2.0:afp:mf:basic"
   xmlns:saml="urn:mace:shibboleth:2.0:afp:mf:saml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:mace:shibboleth:2.0:afp classpath:/schema/shibboleth-2.0-afp.xsd
                       urn:mace:shibboleth:2.0:afp:mf:basic classpath:/schema/shibboleth-2.0-afp-mf-basic.xsd
                       urn:mace:shibboleth:2.0:afp:mf:saml classpath:/schema/shibboleth-2.0-afp-mf-saml.xsd">

   <!--  Release the transient ID to anyone -->
   <afp:AttributeFilterPolicy id="releaseTransientIdToAnyone">
      <afp:PolicyRequirementRule xsi:type="basic:ANY"/>
      <afp:AttributeRule attributeID="transientId">
         <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>
   </afp:AttributeFilterPolicy>

   <!--  Release bwIDM only to bwIDM members -->
   <afp:AttributeFilterPolicy id="releaseBwAttributesToBwIdM">
      <afp:PolicyRequirementRule xsi:type="saml:AttributeRequesterEntityAttributeExactMatch"
         attributeName="http://macedir.org/entity-category"
         attributeValue="http://aai.dfn.de/category/bwidm-member" />
      <afp:AttributeRule attributeID="bwidmOrgId">
         <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>
      <afp:AttributeRule attributeID="mail">
         <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>
      <afp:AttributeRule attributeID="sn">
         <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>
      <afp:AttributeRule attributeID="organizationName">
         <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>
      <afp:AttributeRule attributeID="givenName">
         <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>
      <afp:AttributeRule attributeID="eduPersonPrincipalName">
         <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>
      <afp:AttributeRule attributeID="eduPersonScopedAffiliation">
         <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>
      <afp:AttributeRule attributeID="persistent-id">
         <afp:PermitValueRule xsi:type="basic:ANY"/>
      </afp:AttributeRule>
   </afp:AttributeFilterPolicy>

</afp:AttributeFilterPolicyGroup>

uApprove

Im Rahmen des Beitritts zur DFN-AAI sollte bereits uApprove installiert und konfiguriert worden sein. uApprove ermöglicht es, den Endnutzer beim Login-Vorgang am IdP davon in Kenntnis zu setzen, dass und welche Autorisierungsdaten über ihn an einen Dienst übermittelt werden.

ECP

Durch den Wegfall des direkten Logins bei HPC Diensten und der Nutzung von Nextcloud für bwSync&Share wird ECP im Normalfall nicht mehr benötigt.

Einige Dienste in der Föderation nutzen ECP für die Authentifizierung. Falls noch nicht geschehen, muss ECP im IdP aktiviert werden. Dazu muss ein entsprechender ProfileHandler in die relying-party.xml eingetragen (vgl. IdPSAML2ECPProfileConfig) werden. Zusätzlich sollte der ECP Endpoint in die Metadaten eingetragen werden.

Außerdem muss der ECP Endpoint mit Basic Authentication im Servlet Container bzw. Webserver geschützt sein.

Es besteht die Möglichkeit, ECP für die jeweiligen Service Provider zu erlauben bzw. zu verbieten. Hierfür gibt es zwei verschiedene Ansätze: Entweder ECP standardmäßig verbieten und für einzelne SPs erlauben (Whitelist) oder ECP standardmäßig erlauben und für einzelne SPs verbieten (Blacklist). Die Konfiguration erfolgt wiederum über die relying-party.xml.

Whitelist-Ansatz für ECP

Für die DefaultRelyingParty wird ECP verboten, d.h. dort besteht kein entsprechender Eintrag. Stattdessen wird ECP im Einzelfall für jeweils eine einzelne RelyingParty erlaubt, d.h. hier erfolgt ein entsprechender Eintrag. Neben ECP muss auch die weitere Konfiguration (z.B. für SSO) hier erfolgen, weil der explizite Eintrag für einen einzeln SP als RelyingParty jeweils alle Werte aus der DefaultRelyingParty überschreibt. Beispieleintrag in der relying-party.xml:

<!-- ====================================== -->
<!--      Relying Party Configuration       -->
<!-- ====================================== -->

<rp:AnonymousRelyingParty
  provider="https://idp.uni-musterstadt.de/idp/shibboleth"
  defaultSigningCredentialRef="IdPCredential" />

<!-- Default Configuration -->
<!-- ===================== -->

<rp:DefaultRelyingParty
  provider="https://idp.uni-musterstadt.de/idp/shibboleth"
  defaultSigningCredentialRef="IdPCredential">

  <rp:ProfileConfiguration
   xsi:type="saml:ShibbolethSSOProfile"
   includeAttributeStatement="false"
   assertionLifetime="PT5M0.000S"
   signResponses="always"
   signAssertions="always" />

  <rp:ProfileConfiguration
   xsi:type="saml:SAML1AttributeQueryProfile"
   assertionLifetime="PT5M0.000S"
   signResponses="always"
   signAssertions="always" />

  <rp:ProfileConfiguration
   xsi:type="saml:SAML1ArtifactResolutionProfile"
   signResponses="always"
   signAssertions="always" />

 <rp:ProfileConfiguration xsi:type="saml:SAML2AttributeQueryProfile" 
   assertionLifetime="PT5M0.000S" 
   assertionProxyCount="0" 
   signResponses="always" 
   signAssertions="always" 
   encryptAssertions="always" 
   encryptNameIds="never" /> 

  <rp:ProfileConfiguration
   xsi:type="saml:SAML2SSOProfile"
   includeAttributeStatement="true"
   assertionLifetime="PT5M0.000S"
   assertionProxyCount="0"
   signResponses="always"
   signAssertions="always"
   encryptAssertions="always"
   encryptNameIds="never" />

  <rp:ProfileConfiguration
   xsi:type="saml:SAML2ArtifactResolutionProfile"
   signResponses="always"
   signAssertions="always"
   encryptAssertions="always"
   encryptNameIds="never" />

</rp:DefaultRelyingParty>

<!-- Whitelist Entry -->
<!-- =============== -->

<rp:RelyingParty id="https://sp.uni-musterhausen.de/sp"
  provider="https://idp.uni-musterstadt.de/idp/shibboleth"

defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
  defaultSigningCredentialRef="IdPCredential">

  <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
   includeAttributeStatement="true"
   assertionLifetime="PT5M"
   assertionProxyCount="0"
   signResponses="never"
   signAssertions="always"
   encryptAssertions="always"
   encryptNameIds="always" />

 <rp:ProfileConfiguration xsi:type="saml:SAML2AttributeQueryProfile" 
   assertionLifetime="PT5M0.000S" 
   assertionProxyCount="0" 
   signResponses="always" 
   signAssertions="always" 
   encryptAssertions="always" 
   encryptNameIds="never" /> 

 <rp:ProfileConfiguration xsi:type="saml:SAML2ECPProfile" 
  includeAttributeStatement="true" 
  assertionLifetime="PT5M" 
  assertionProxyCount="0" 
  signResponses="never" 
  signAssertions="always" 
  encryptAssertions="always" 
  encryptNameIds="always" /> 
</rp:RelyingParty>

Blacklist-Ansatz für ECP

In der DefaultRelyingParty wird ECP erlaubt, d.h. dort erfolgt ein entsprechender Eintrag. Anschließend wird ECP im Einzelfall für eine RelyingParty verboten, d.h. hier erfolgt kein entsprechender Eintrag. Neben ECP muss auch die weitere Konfiguration (z.B. für SSO) hier erfolgen, weil der explizite Eintrag für einen einzelnen SP als RelyingParty jeweils alle Standardeinstellungen überschreibt. Beispieleintrag in der relying-party.xml:

<!-- ====================================== -->
<!--      Relying Party Configuration       -->
<!-- ====================================== -->

<rp:AnonymousRelyingParty
  provider="https://idp.uni-musterstadt.de/idp/shibboleth"
  defaultSigningCredentialRef="IdPCredential" />

<!-- Default Configuration -->
<!-- ===================== -->

<rp:DefaultRelyingParty
  provider="https://idp.uni-musterstadt.de/idp/shibboleth"
  defaultSigningCredentialRef="IdPCredential">

  <rp:ProfileConfiguration
   xsi:type="saml:ShibbolethSSOProfile"
   includeAttributeStatement="false"
   assertionLifetime="PT5M0.000S"
   signResponses="always"
   signAssertions="always" />

  <rp:ProfileConfiguration
   xsi:type="saml:SAML1AttributeQueryProfile"
   assertionLifetime="PT5M0.000S"
   signResponses="always"
   signAssertions="always" />

  <rp:ProfileConfiguration
   xsi:type="saml:SAML1ArtifactResolutionProfile"
   signResponses="always"
   signAssertions="always" />

  <rp:ProfileConfiguration
   xsi:type="saml:SAML2SSOProfile"
   includeAttributeStatement="true"
   assertionLifetime="PT5M0.000S"
   assertionProxyCount="0"
   signResponses="always"
   signAssertions="always"
   encryptAssertions="always"
   encryptNameIds="never" />

  <rp:ProfileConfiguration
   xsi:type="saml:SAML2AttributeQueryProfile"
   assertionLifetime="PT5M0.000S"
   assertionProxyCount="0"
   signResponses="always"
   signAssertions="always"
   encryptAssertions="always"
   encryptNameIds="never" />

  <rp:ProfileConfiguration
   xsi:type="saml:SAML2ArtifactResolutionProfile"
   signResponses="always"
   signAssertions="always"
   encryptAssertions="always"
   encryptNameIds="never" />

  <rp:ProfileConfiguration
   xsi:type="saml:SAML2ECPProfile"
   includeAttributeStatement="true"
   assertionLifetime="PT5M.000S"
   assertionProxyCount="0"
   signResponses="always"
   signAssertions="always"
   encryptAssertions="always"
   encryptNameIds="never"/>

</rp:DefaultRelyingParty>

<!-- Blacklist Entry -->
<!-- =============== -->

<rp:RelyingParty id="https://sp.uni-musterdorf.de/sp"
  provider="https://idp.uni-musterstadt.de/idp/shibboleth"

defaultAuthenticationMethod="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
  defaultSigningCredentialRef="IdPCredential">

  <rp:ProfileConfiguration
   xsi:type="saml:SAML2AttributeQueryProfile"
   assertionLifetime="PT5M0.000S"
   assertionProxyCount="0"
   signResponses="always"
   signAssertions="always"
   encryptAssertions="always"
   encryptNameIds="never" />

 <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" 
   includeAttributeStatement="true" 
   assertionLifetime="PT5M" 
   assertionProxyCount="0" 
   signResponses="never" 
   signAssertions="always" 
   encryptAssertions="always" 
   encryptNameIds="always" /> 
</rp:RelyingParty>

ECP bei der DFN-Föderation registrieren

Der ECP Endpunkt des Identity Providers muss bei der DFN-Föderation bekannt gemacht werden. Dies geht in der DFN Metadaten Verwaltung unter den Metadaten des IDP. Bei „Single Sign On Services“ muss ein Binding „urn:oasis:names:tc:SAML:2.0:bindings:SOAP“ mit der passenden Location aufgeführt sein. Üblicherweise ist die Location „https://name.des.idp/idp/profile/SAML2/SOAP/ECP“. Falls das Binding noch nicht aufgeführt ist, kann es an dieser Stelle unter „neuen Single Sign On Service anlegen“ angelegt werden.