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:
Codeblock | ||||
---|---|---|---|---|
| ||||
<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