Hier ist beschrieben, wie Keycloak zu konfigurieren ist, damit eine SAML-Authentifizierung über den Shibboleth Identity Provider möglich ist. In den folgenden Screenshots wird der Development-Server von schnaq mit dem Development-IdP der HHU verbunden.
Eine detailliertere und weiterreichende Dokumentation findet sich unter: https://www.blog.albert-stark.de/p/shibboleth-and-keycloak/
Die resultierenden Metadaten müssen dem IdP zur Verfügung gestellt werden (diese sind sehr minimalistisch, falls jemand weiß, wie Zusatzinformationen wie Organization, ContactPerson, AttributeConsumingService etc angegeben werden können, bitte melden). In unserem Fall wird die generierte xml-Datei per Ansible auf dem IdP abgelegt und per FilesystemMetadataProvider in der metadata-providers.xml integriert.
Attributfreigabe im IdP:
<AttributeFilterPolicy id="schnaq">
<PolicyRequirementRule xsi:type="Requester" value="https://auth.schnaq.com/realms/schnaq" />
<AttributeRule attributeID="mail" permitAny="true" />
<AttributeRule attributeID="givenName" permitAny="true" />
<AttributeRule attributeID="sn" permitAny="true" />
<AttributeRule attributeID="displayName" permitAny="true" />
<AttributeRule attributeID="eduPersonAffiliation">
<PermitValueRule xsi:type="Value" value="employee" caseSensitive="false" />
</AttributeRule>
</AttributeFilterPolicy>
displayName wird vermutlich in Zukunft genutzt. eduPersonAffiliation wird genutzt um Angestellten ("employee") zusätzliche Dienste zur Verfügung zu stellen (s. letzter Screenshot). Über Keycloak-Mapper werden die Werte der SAML-Attribute dem Dienst verfügbar gemacht (die Zuordnung der User passiert vermutlich implizit über die persistentId):
Die einzelnen Mapper: "Attribute Name" muss genau der Bezeichnung der SAML-Assertion entsprechen (oder URN), "Attribute User Name" dem Zielbezeichner.
Angestellte bekommen Zugang zur Enterprise-Version:
Bei Fragen:
idm ät hhu Punkt de
christian ät schnaq Punkt com
