Microsoft ADFS an Q.wiki anbinden (SAML)

Diese Anleitung ist für IT-Fachpersonal gedacht und unterstützt dich bei der selbstständigen Anbindung von Q.wiki an Microsoft ADFS.

Empfehlung und allgemeine Informationen

Migration vorhandener Nutzer

Bei der Anbindung von ADFS werden bestehende Q.wiki-Nutzer mit übereinstimmender E-Mail-Adresse automatisch migriert. Die migrierten Nutzer werden mit den Daten aus Active Directory aktualisiert und von diesem Zeitpunkt an über dieses verwaltet.

Migrierte Nutzer melden sich über den Button Unternehmenslogin verwenden an. Die Anmeldung mit Nutzernamen und Passwort ist nicht mehr möglich.

Einrichten eines Notfall-Kontos

Sollte es zu einer Fehlfunktion seitens Active Directory kommen oder der Secret Token auslaufen, ist eine Anmeldung nur noch über manuell in Q.wiki angelegte Nutzer möglich. Aus diesem Grund empfehlen wir, ein manuell verwaltetes Konto der KeyUserGroup hinzuzufügen. Dieses Konto muss über eine gültige E-Mail-Adresse verfügen und darf nicht über Azure provisioniert werden – eine unpersönliche E-Mail-Adresse wie „service@…" oder „it-support@…" ist ideal.

Sollte der Schlüssel bereits abgelaufen sein, lies den Artikel 401 Unauthorized – Fehlermeldung bei Benutzeranmeldung.

Provisionierung

Mit eingerichteter SAML-Authentifizierung ist die sogenannte „Just-in-Time"-Provisionierung aktiv. Nutzerkonten werden automatisch in Q.wiki angelegt, wenn sie sich das erste Mal anmelden.

Die Provisionierung kannst du in der Nutzerverwaltung > 3-Punkt-Menü > Provisionierung konfigurieren einstellen:

Einrichtung

1. Öffne die Nutzerverwaltung und öffne über das 3-Punkt-Menü die IdP-SAML-Konfiguration.
2. Lade deine IdP-Metadaten hoch.
3. Die Q.wiki-Metadaten (Service Provider) sind unter https://IHRMANDANT.qwikinow.de/saml/sp/metadata verfügbar. Sie enthalten auch das Zertifikat.
4. Kopiere die ACS-URL aus dem Q.wiki-Dialog und verwende sie in deinem IdP als Entity ID und Antwort-URL:

   

5. Die NameID wird mit dem Attributnamen „email" erwartet – das ist meist Standard, kann in anderen IdPs aber ein angepasstes Mapping erfordern. Das NameID-Format ist nicht vorgegeben; wir empfehlen „persistent".

   

6. Messe das Active-Directory-Attribut für die E-Mail auf „email" und das Attribut für den Anzeigenamen auf „name":

   

7. Im folgenden Beispiel siehst du, wie die Regeln aussehen können:

   c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");

   LDAP als Claims:

   c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), query = ";displayName,mail;{0}", param = c.Value);