Diese Anleitung ist an IT-Fachpersonal gerichtet. Sie unterstützt die selbstständige Anbindung von Q.wiki an exponierte Microsoft ADFS. 

Wir empfehlen ausdrücklich die Nutzung von SCIM und OIDC für die Nutzerprovisionierung und Single Sign-On. SCIM provisioniert alle gewählten User "just in case" und ermöglicht so, Nutzern in Q.wiki Inhalte und Berechtigungen zuzuweisen, bevor die Nutzer sich das erste Mal an Q.wiki angemeldet haben. Das ist mit SAML und der "just in time" Provisionierung nicht möglich.

Sie benötigen Key User Rechte um die folgenden Schritte durchzuführen.

Empfehlung und allgemeine Informationen

Migration vorhandener Topic/LDAP Nutzer

Bei Anbindung von ADFS werden bestehende Q.wiki Nutzer Nutzer mit einer übereinstimmenden Email-Adresse migriert. Die migrierten Nutzer werden mit den Daten aus Entra ID aktualisiert und von diesem Zeitpunkt an über dieses verwaltet.

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

Einrichten eines "Notfall-Kontos"

Sollte es zu einer Fehlfunktion seitens Entra kommen, oder der Secret Token auslaufen, ist eine Anmeldung nur noch über manuell in Q.wiki angelegte Nutzer möglich. Aus diesem Grund empfiehlt es sich, ein manuell verwaltetes Konto der KeyUser Gruppe hinzuzufügen. Dieses Konto muss über eine valide Email-Adresse verfügen und darf nicht über Azure provisioniert werden, eine unpersönliche Email-Adresse wie "service@", "it-support@" bietet sich an. Sollte der Schlüssel bereits abgelaufen sein, lese bitte den folgenden 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 kann in der Nutzerverwaltung, 3-Punkt Menü, Provisionierung konfigurieren aktiviert werden:

Einrichtung

1. Rufen Sie die Benutzerverwaltung auf und öffnen Sie über das 3-Punkt Menü die IdP SAML Konfiguration.

2. Laden Sie Ihre IdP Metadaten hoch.

3. Die Q.wiki Metadaten (SP) sind unter https://IHRMANDANT.qwikinow.de/saml/sp/metadata verfügbar. Darin ist auch das Zertifikat enthalten.
   Der Algorithmus des Zertifikats ist "ECC 256", das kann bei ADFS zu Kompatibilitätsproblemen führen.

4. Die Metadaten sind erst verfügbar, nachdem Ihre IdP Metadaten hochgeladen wurden

5. Der Einfachheit halber empfehlen wir, die ACS URL als Entity ID zu vergeben und in Ihrem IdP zu verwenden:

   ACS URL aus dem Q.wiki Dialog kopieren und als Entitäts-ID und Antwort-URL einfügen:

   

6. Die Namens-ID wird explizit mit dem Attributnamen "email" erwartet, das ist für Entra Standard, kann in anderen IdP aber ein angepasstes Mapping erfordern. Das Namens-ID Format ist nicht vorgegeben, wir empfehlen persistent.
   
7. Zusätzlich muss das AD Attribut für Email auf email und eines für den Anzeigenamen auf "name" gemapped werden:
   
8. Die erzeugten Regeln sehen in unserem Beispiel so aus:
   
   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 as claims :
9. 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);