SAML Authentifizierung mit Mindbreeze

Installation und Einrichtung

Mindbreeze GmbH, A-4020 Linz, .

Diese Unterlagen sind streng vertraulich. Durch die Übermittlung und Präsentation dieser Unterlagen alleine werden keine Rechte an unserer Software, an unseren Dienstleistungen und Dienstleistungsresultaten oder sonstigen geschützten Rechten begründet. Die Weitergabe, Veröffentlichung oder Vervielfältigung ist nicht gestattet.

Aus Gründen der einfacheren Lesbarkeit wird auf die geschlechtsspezifische Differenzierung, z.B. Benutzer/-innen, verzichtet. Entsprechende Begriffe gelten im Sinne der Gleichbehandlung grundsätzlich für beide Geschlechter.

SAML Authentifizierung mit Mindbreeze

Bei SAML (Security Markup Language) handelt es sich um einen XML-basierten Standard für Authentifizierung und Authorisierung zwischen Identity Provider (IdP, Hersteller von Assertions) und Service Provider (Assertion Konsumenten) in einer Security Domain. Fabasoft Mindbreeze Enterprise Services, wie Index- und Client Service, sind Service Provider.

Als Identity Provider wird bei Mindbreeze das Open Source Produkt Shibboleth, der Internet-2-Middleware Initiative eingesetzt. Folgend wird die Installation und Konfiguration von Shibboleth, sowie die SAML-Konfiguration in Fabasoft Mindbreeze Enterprise beschrieben.

Identity Provider Konfiguration für Shibboleth 2.x

Die Shibboleth Konfigurationsdateien befinden sich im Installationsverzeichnis unter conf. Um Shibboleth mit Fabasoft Mindbreeze InSpire zu verwenden müssen die Dateien relying-party.xml und handler.xml verändert werden. Die nächsten beiden Abschnitte erläutern die notwendigen Schritte.

Konfiguration der Relying Parties

Damit der IdP Authentifizierungsanfragen von Fabasoft Mindbreeze Enterprise Services annimmt, müssen die Metadaten zu den Services (Entity Descriptor) für den IdP erreichbar sein. Die Metadaten werden in einem XML-Dokument definiert. Der Entities Descriptor der Mindbreeze InSpire Services ist über den Fabasoft Mindbreeze Inspire Management Center, unter der URL <inspire_url>:8443/saml20/sp/entitiesdescriptor, erreichbar. In der Datei relying-party.xml der Shibboleth-Konfiguration muss dieser URL folgendermaßen eingetragen werden:

<MetadataProvider id="<provider_id>"
    xsi:type="FileBackedHTTPMetadataProvider"
  xmlns="urn:mace:shibboleth:2.0:metadata"
    metadataURL="<mesmaster_url>/saml20/sp/entitiesdescriptor"
    backingFile="<backing_file_path>"
/>

<mesmaster_url> muss durch die URL von Fabasoft Mindbreeze Enterprise Master ersetzt werden und <backing_file_path> gibt den Pfad an, wo die Metadaten für schnelleren Zugriff zwischengespeichert werden. Beachten Sie, dass in <provider_id> keine Leerzeichen oder auch andere spezielle Zeichen vorkommen dürfen. Nach der Konfiguration muss der Server neu gestartet werden. Ändert sich der Entity Descriptor am Fabasoft Mindbreeze Enterprise Master muss Shibboleth ebenfalls neu gestartet werden.

Zusätzlich muss in der Datei relying-party.xml das SAML2SSOProfil das Attribut encryptNameIds wie im folgenden Beispiel dargestellt auf "never" gesetzt werden:

Shibboleth Single Sign On ausschalten

Shibboleth verwendet HTML Cookies für Single Sign On. Wird lediglich Fabasoft Mindbreeze Enterprise mit diesem Identity Provider betrieben, kann man diese Option ausschalten. Dadurch ist gewährleistet, dass die Gültigkeit einer Sitzung lediglich durch die Mindbreeze Client Service Sessiondauer gesteuert wird. Dazu müssen folgende Zeilen in handler.xml auskommentiert oder gelöscht werden:

<LoginHandler xsi:type="PreviousSession">
    <AuthenticationMethod>
        urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
    </AuthenticationMethod>
</LoginHandler>

Name des angemeldeten Benutzers als Assertion Subject verwenden

Shibboleth verwendet in der Standardeinstellung eine generierte ID als Assertion Subject. Da einige Funktionen in Fabasoft Mindbreeze Enterprise (z.B. die Suche im Dateisystem) den Namen des angemeldeten Benutzers benötigen, wird Shibboleth so konfiguriert, dass dieser als Assertion Subject übergeben wird. Folgende Änderungen müssen dazu an attribute-resolver.xml und attribute-filter.xml vorgenommen werden:

Fügen Sie in attribute-resolver.xml die folgenden Zeilen hinzu:

<resolver:AttributeDefinition id="principal"
xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad">

      <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
        xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
        nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
      />
    </resolver:AttributeDefinition>

Ändern Sie in attribute-filter.xml die "releaseTransientIdToAnyone" Filter Policy. Der Wert des Attributs attributeId muss von "transientId" auf "principal" geändert werden. Nach der Änderung sollte die Filter Policy wie folgt aussehen:

Authentifizierung mit HTML Formular und Kerberos

Um formularbasierte Authentifizierung zu aktivieren muss der UsernamePassword-Handler in handler.xml konfiguriert sein.

<LoginHandler xsi:type="UsernamePassword"
    jaasConfigurationLocation="file:///C:/Shibboleth-idp/conf/login.config">
    <AuthenticationMethod>
      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    </AuthenticationMethod>
</LoginHandler>

Der Handler erlaubt den Benutzern die Anmeldung über Anmeldeformular. Das Attribut jaasConfigurationLocation gibt die Konfigurationsdatei von Java Authentication and Auhtorization (JAAS) an. In dieser Konfigurationsdatei (C:/Shibboleth-idp/conf/login.config) muss das Kerberos Login Modul, wie in folgendem Beispiel, eingetragen werden:

ShibUserPassAuth {

com.sun.security.auth.module.Krb5LoginModule required

useKeyTab="true"

keyTab="C:\Shibboleth-IDP-2.1.5\mindidpsh2.keytab";

};

Der Name des Login Moduls muss "ShibUserPassAuth" lauten. Die keytab-Datei enthält die Anmeldedaten des Servicebenutzers von Shibboleth.

Zusätzlich müssen, bei Verwendung von Tomcat, in der Konfigurationsdatei <TOMCAT_HOME>/conf/catalina.properties folgende Zeilen hinzugefügt werden:

java.security.krb5.realm=<REALM>

java.security.krb5.kdc=<domain_controller>

<REALM> ist dabei durch den Kerberos REALM zu ersetzen und <domain_controller> durch den vollqualifizierten Domain Namen des Kerberos Domain Controllers (z.B. dc1.mydomain.com).

Authentifizierung mit HTTPS Client-Zertifikaten

Die Validierung der Client-Zertifikate erfolgt über den Servlet-Container. Um das Assertion Subject zu bekommen, verwendet Shibboleth den RemoteUser Login-Handler. Dieser wird in handler.xml konfiguriert, z.B.:

<LoginHandler xsi:type="RemoteUser">
  <AuthenticationMethod>
    urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
  </AuthenticationMethod>
</LoginHandler>

Als Benutzername wird das Common Name (CN) Feld des Zertifikats verwendet. Zusätzlich muss der SSLAuthFilter im Servlet-Container eingespielt und konfiguriert werden. Kopieren Sie dazu das auf dem Installationsmedium unter Server/(CPU_ARCH)/prerequisites verfügbare SSLAuthFilter.jar-Archiv in das WEB-INF/lib-Verzeichnis der Shibboleth Web-Anwendung und fügen Sie folgende Zeilen in den entsprechenden Abschnitt von web.xml ein:

<filter>
  <filter-name>SSLAuthFilter</filter-name>
  <filter-class>
    com.mindbreeze.tomcat.filters.ClientCertificateFilter
  </filter-class>
</filter>

<filter-mapping>
<filter-name>SSLAuthFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Außerdem muss der Standard-Connector von Tomcat umkonfiguriert werden. Das Attribute clientAuth muss von "want" auf "true" geändert und das truststoreAlgorithm-Attribut gelöscht werden. Nach den Änderungen sollte der Connector wir folgt aussehen:

Die für die Validierung verwendeten CA-Zertifikate müssen in den Truststore eingespielt werden. Verwenden Sie dazu z.B. das Programm keytool, das mit Java installiert wird:

keytool –importcert –alias <certificate_alias> -keystore <idp_keystore> -file <certificate file>

<certificate_alias> wird dem importieren Zertifikat als eindeutiger Name zugewiesen. Beim Aufruf des Kommandos muss das Keystore-Passwort eingegeben werden.

Um ein Zertifikat aus dem Keystore zu entfernen, führen Sie folgendes Kommando aus:

keytool –delete –alias <certificate_alias> -keystore <idp_keystore>

Zuletzt muss der Identity Provider neu gestartet werden.

Authentifizierung mittels HTTP BASIC gegen LDAP

Um SAML-basierte Authentifizierung für Benutzer aus einem LDAP Verzeichnis zu aktivieren, muss der Identity Provider entsprechend konfiguriert werden, dass er das Benutzername/Passwort Paar gegen den LDAP Server prüft.

Um einen LDAP Benutzer zu authentifizieren, wird ein spezieller Servlet-Filter benötigt (analog zum Szenario mit SSL Client-Side-Certificates in Kapitel ). Dieser Filter schickt dem Client eine HTTP BASIC Challenge und prüft die eingegebenen Daten mittels JAAS Login gegen einen LDAP Server. Ist diese Anmeldung erfolgreich, so wird dem Client eine Antwort mit dem eingegebenen Benutzernamen als "Assertion Subject" geschickt. Wie im obigen Szenario muss auch hier der RemoteUser Login Handler aktiviert werden.

Zur weiteren Konfiguration des Identity Provider sind folgende Schritte nötig:

Hinzufügen und Konfigurieren des Servlet Filters
Konfiguration des JAAS Login-Moduls für den Authenticator

Hinzufügen des Servlet Filters

Der Wert für das "remoteUser" Attribut, das vom Shibboleth RemoteUser Login Handler benötigt wird, wird direkt aus dem Benutzernamen der HTTP Basic Challenge übernommen. Dies wird von einem Servlet Filter namens BasicLDAPAuthFilter erledigt, der im Paket MindbreezeAuthenticationFilters.jar enthalten ist. Die Shibboleth-Servlet-Konfigurationsdatei web.xml muss entsprechend angepasst werden, so dass der oben genannte Filter in der normalen Filter Chain eingehängt wird. Folgende Zeilen werden hierfür in der Datei <tomcat_home>/webapps/idp/web.xml benötigt:

  <filter-name>BasicLDAPAuthFilter</filter-name>
  <filter-class>
    com.mindbreeze.tomcat.filters.BasicLDAPAuthFilter
  </filter-class>

  <init-param>
    <param-name>LoginConfPath</param-name>
    <param-value><JAAS configuration path></param-value>
  </init-param>

</filter>

<filter-mapping>
<filter-name> BasicLDAPAuthFilter </filter-name>
<url-pattern>/Authn/*</url-pattern>
</filter-mapping>

Zusätzlich muss der Pfad zu einer JAAS Login-Konfigurationsdatei beim Parameter LoginConfPath eingestellt werden.

Konfiguration eines JAAS Login-Moduls für LDAP Authentifizierung

In der JAAS Login-Konfigurationsdatei (wie oben beschrieben) wird ein JAAS Login-Modul für den Identity Provider konfiguriert. Das Modul muss den Namen ShibUserPassAuth tragen, als Klasse für den LDAP Login kann com.sun.security.auth.module.LdapLoginModule verwendet werden. Eine Beispielkonfiguration sieht wie folgt aus:

ShibUserPassAuth {
    com.sun.security.auth.module.LdapLoginModule required
    userProvider="<ldap_url>”
    useSSL="false"
    userFilter="(&(cn={USERNAME})(objectClass=person))";
};

Als userProvider muss hier eine LDAP URL eingetragen werden, die auf die im LDAP verwalteten Benutzerobjekte zeigt. Ein Beispiel:

ldap://ldapserv.mydomain.com:389/ou=people,dc=myfolder,dc=mydomain,dc=com

Der Parameter userFilter spezifiziert einen Suchfilter um den Benutzereintrag im LDAP-Verzeichnis zu finden und wird verwendet, um den DN des Benutzers zu isolieren. Die Syntax ist analog zu LDAP Filter Strings (RFC 2254). Der Teilstring {USERNAME} wird hierbei durch den Benutzernamen, der beim Basic Dialog eingegeben wird, ersetzt, bevor der Filter angewendet wird.

Die Login-Klasse com.sun.security.auth.module.LdapLoginModule verwendet standardmässig SSL-verschlüsselte Verbindungen um sich am LDAP Server anzumelden. Sollte eine SSL-Verbindung nicht möglich sein, so kann man dies mit dem useSSL Parameter deaktivieren.

Nähere Informationen zur Konfiguration finden sich unter:

http://java.sun.com/javase/6/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/LdapLoginModule.html

Identity Provider Konfiguration für Shibboleth 4.x

Principal Attribut Freigabe für Mindbreeze

Mit Shibboleth 4.x ist es wichtig, dass das Attribut welches als SAML NameID verwendet wird, für die Mindbreeze InSpire Relying Party freigegeben ist. Dafür fügen Sie folgende Zeilen in die <idp_home>/conf/attribute-filter.xml Konfigurationsdatei ein:

</AttributeRule>

</AttributeFilterPolicy>

Ersetzen Sie "<mes_relying_party_id>" mit die SAML Entity ID des Mindbreeze InSpire Client Services. In diesem Beispiel wird das „uid“ Attribut als SAML Principal verwendet.

SAML Subject NameID Generator konfigurieren

Für die freigegebene „uid“ Attribut muss noch ein NameID Generator definiert werden. In der Konfigurationsdatei <idp_home>/conf/saml-nameid.xml finden Sie das „<util:list id="shibboleth.SAML2NameIDGenerators">“ Element. Fügen Sie in die Liste ein

„shibboleth.SAML2AttributeSourcedGenerator“-Element ein mit folgenden Settings:

<util:list id="shibboleth.SAML2NameIDGenerators">

<!--

-->

<bean parent="shibboleth.SAML2AttributeSourcedGenerator"

p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"

p:attributeSourceIds="#{ {'uid'} }" />

</util:list>

Es wird hier als Quelle das vorher freigegebene „uid“ Attribut verwendet.

SAML NameID Format für Mindbreeze InSpire setzen

In <idp_home>/conf/relying-party.xml fügen Sie folgendes Element in die „shibboleth.RelyingPartyOverrides“ Liste ein:

<list>

</list>

</property>

</bean>

Ersetzen Sie "<mes_relying_party_id>" mit der SAML Entity ID des Mindbreeze InSpire Client Services.

Metadata-Provider in Shibboleth hochladen und konfigurieren

Folgen Sie zunächst den Schritten im Abschnitt „Hochladen der IdP Metadaten“ und laden Sie den Entity Descriptor von Shibboleth (metadata/idp-metadata.xml) auf Ihre Mindbreeze InSpire Appliance. Nach dem Hochladen des Shibboleth Entity Descriptors starten sich die Mindbreeze InSpire Services automatisch neu. Bitte warten Sie kurz, bis der Entity Descriptor von Mindbreeze generiert wurde. Diesen können Sie dann unter <inspire_url>:8443/saml20/sp/entitiesdescriptor finden. Den Entity Descriptor können Sie anschließend auf Ihrem Shibboleth Server unter beispielsweise metadata/mindbreeze.xml hochladen. Letztendlich ist der Pfad zu dem Mindbreeze Entity Descriptor unter conf/metadata-providers.xml entsprechend zu setzen:

…

…

Konfiguration mit Microsoft Active Directory Federation Services (ADFS)

Um SAML mit ADFS (Active Directory Federation Services) in Mindbreeze zu verwenden, müssen folgende Schritte durchgeführt werden:

Fügen Sie ein Relying Party Trust in Ihrer ADFS Konfiguration. Hierzu Rechtsklick auf „Relying Party Trust“ danach „Add Relying Party Trust…“. Im nachfolgenden Wizard Einstellungen vornehmen und Relying Party Trust hinzufügen.

Hier die Mindbreeze Service Provider Entities Descriptor Datei hochladen. Der Entities Descriptor der Mindbreeze InSpire Services ist über den Fabasoft Mindbreeze InSpire Management Center, unter der URL <inspire_host>:8443/saml20/sp/entitiesdescriptor, erreichbar wenn die SAML Konfiguration auf dem Mindbreeze InSpire Server fertig ist.

Setzen Sie einen Namen für die Relying Party. Wenn gewünscht ist, kann Multi-Faktor Authentisierung auch konfiguriert werden.

Setzen Sie die Berechtigungen auf die Relying Party auf „Alle Benutzer“ (Permit all users to access this relying party).

Zum Schluss müssen Sie noch ein Claim in Ihrer ADFS Konfiguration hinzufügen. Falls sich nachfolgender Wizard nicht automatisch öffnet, den zuvor erstellten Relying Party Trust anwählen und mit rechter Maustaste oder auf der rechten Seite im Menü Feld „Edit Claim Rules…“ auswählen.

Hier wählen Sie „Transform an Incoming Claim“ aus. Geben Sie einen Namen für das Claim. Um die Konfiguration abzuschließen müssen Sie noch für „Outgoing claim type“ „Name ID“ angeben und für Outgoing name ID format“ „Unspecified“.

Konfiguration mit Microsoft Azure Active Directory

Für die Konfiguration von Microsoft Azure Active Directory als SAML-Identitätsprovider muss für den Mindbreeze InSpire Client Service eine Enterprise-Applikation erstellt werden.

Melden Sie sich beim Azure-Portal als Cloud Application Admin oder als Application Admin für Ihren Azure AD-Tenant an.

Navigieren Sie zu "Azure Active Directory" > "Enterprise applications" und fügen Sie eine neue Applikation hinzu, indem Sie auf die Schaltfläche "New application" klicken.

Wählen Sie " Non-gallery application " als Anwendungstyp, legen Sie den Namen der neuen Applikation fest und klicken Sie auf "Add".

Navigieren Sie zu “Manage” > “Single Sign-on” und wählen Sie dann "SAML", um eine SAML-basierte SSO für die erstellte Anwendung einzurichten.

Laden Sie nun die generierten SAML Federation Metadata XML für den IDP im Abschnitt "SAML Signing Certificate" herunter.

Installieren Sie die IDP-Metadaten in Mindbreeze wie im Abschnitt "Konfiguration von SAML in Mindbreeze" beschrieben und rufen Sie die SAML-Metadaten des Service Providers von der Mindbreeze InSpire-Appliance über den Link <inspire_url>:8443/saml20/sp/entitiesdescriptor ab

Wenn der Service Provider Metadaten File nur die Entity Descriptor eines Mindbreeze InSpire-ClientService enthält, kann die Metadatendatei des Dienstanbieters direkt hochgeladen werden, indem Sie auf "Upload metadata file" klicken.

Überprüfen Sie, ob die Einstellungen im Abschnitt "Basic SAML Configuration" nach dem Hochladen der Metadatendatei korrekt sind.

Wenn der Service Provider Metadaten File mehrere Entity Descriptoren für Mindbreeze InSpire-ClientServices enthält, müssen die "EntityID" und die "Assertion Consumer Service-URL" Parameter manuell von dem ClientService eingestellt werden, der dieser Enterprise Applikation zugeordnet ist.

Weisen Sie schließlich die Benutzer zu, die mit dieser Anwendung authentifiziert werden können. Navigieren Sie zu "Manage" > "Users and groups" im Applikation Menü.

Die Enterprise Applikation sollte damit bereit für die SAML-Authentifizierung mit einem Mindbreeze InSpire-ClientService sein.

Konfiguration von SAML in Mindbreeze

Die Konfiguration von SAML in Mindbreeze erfolgt in vier Schritten:

Hinzufügen eines SSL Zertifikats, das zur Erzeugung der Service Provider Metadaten verwendet wird
Konfiguration des SAML Authenticators
Konfiguration der Parameter (“Session timeout” und ”Metadata timeout”)
Aktivieren von SAML für einzelne Services

Die Konfiguration erfolgt in der Registerkarte "Authentication".

Hinzufügen eines SSL Zertifikats

Im Tab-Reiter Certificates ist es möglich, SSL Zertifikate hinzuzufügen. Das hinzuzufügende Zertifikat muss ein leeres "Import Password" haben und wird nach dem Hinzufügen in der Liste der Available SSL Certificates angezeigt.

Hochladen der IdP Metadaten

Nach der Installation von Shibboleth liegt der Entity Descriptor des IdP im Installationsverzeichnis unter metadata/idp-metadata.xml. Dadurch können die Fabasoft Mindbreeze Enterprise Services auf den IdP zugreifen. Kontrollieren Sie vor dem Hochladen die Korrektheit der http(s)://host:port Einträge, diese werden bei der Installation von Shibboleth nicht immer korrekt angepasst. Beim Hochladen wird geprüft ob das Dokument dem SAML 2.0 Standard genügt. Nach erfolgreicher Prüfung erscheint "A valid SAML identity file is installed." bei "SAML ID status". Benutzen Sie die „Choose Cert“ Auswahlbox, um das SSL Zertifikat des entsprechenden Sibboleth Servers zu wählen (neue SSL Zertifikate können Sie in der Registerkarte „Certificates“ einspielen).

Anmerkung für Shibboleth 4.x:

Die IDP Metadaten für Shibboleth 4.x können mehrere Zertifikate enthalten die für Assertion Signierung oder Verschlüsselung verwendet werden können. Mindbreeze unterstützt nur jeweils ein Zertifikat für Signierung und Verschlüsselung. Es ist wichtig, dass die IDP Metadaten (idp-metadata.xml) vor dem Hochladen editiert werden. Dort müssen im IDPSSODescriptor-Element die KeyDescriptor-Einträge, die nicht für die Mindbreeze Relying Party verwendet sind, entfernt werden. Die verwendeten Zertifikate finden Sie unter shibboleth-idp/credentials. Bis auf die Zertifikate credentials/idp-encryption.crt (use =“encryption“) und credentials/idp-signing.crt (use=“signing“) sind die restlichen KeyDescriptor-Einträge aus dem idp-metadata.xml vor dem Hochladen auf Mindbreeze zu entfernen.

Anmerkung für Microsoft ADFS:

Die IDP Metadaten sind unter die URL <ADFS Server>/FederationMetadata/2007-06/FederationMetadata.xml erreichbar. Die IDP Metadaten können auch hier mehrere Zertifikate enthalten. Für die Signierung und Verschlüsselung der Anfragen kann Mindbreeze nur jeweils ein Zertifikat verarbeiten. Daher müssen in dieser Datei alle KeyDescriptor-Einträge bis auf jeweils einen entfernt werden. Bestehen bleiben müssen die KeyDescriptor-Einträge im IDPSSODescriptor mit den Attributen use=“signing“ bzw use=“encryption“.

...

...

</IDPSSODescriptor>

Konfiguration der SAML Parameter

Im Abschnitt "SAML Settings" können die Parameter "Session timeout" und "Metadata timeout" gesetzt werden. "Session timeout" legt die Lebensdauer einer SAML-Session in Minuten fest. Nach Ablauf dieser Zeit wird die Assertion erneuert. "Metadata timeout" dient dazu, die Anzahl der Tage fest, die die Metadaten der Service Provider für den Identity Provider gültig sind. Die Standardkonfiguration liegt bei fünf Minuten für "Session timeout" und sieben Tage für "Metadata timeout".

„Authenticator“ Liste

Diese Liste zeigt alle verfügbaren „Authenticator” IDs. Ein „Authenticator“ entspricht einem für die Authentifizierung verfügbaren Identity Provider Service. Verwenden Sie die „Certificate“ Auswahlbox, um das verwendete Zertifikat zu wählen.

Aktivieren von SAML für einzelne Services

Für Index Services und Client Services kann im Abschnitt "Enable/Disable SAML Authentication" die Verwendung von SAML über Checkboxen aktiviert werden. Wählen Sie für jedes aktivierte Client-Service in der Auswahlbox den entsprechenden „Authenticator“ aus.

Wenn für ein Client Service SAML Authentisierung aktiviert ist, muss der Parameter „External URL“ in die Client Service Konfiguration auf die externe URL des Client Services gesetzt sein. Der „External URL“ Parameter bestimmt die Basis URL für die SAML Service Provider Endpunkte.

Wichtige Bemerkungen

Indizes, die von einem mit SAML konfigurierten Client Service kontaktiert werden sollen, müssen "Use SAML Authentication" aktiviert haben.
Nach einem Update von Fabasoft Mindbreeze Enterprise 2009 Fall Release oder früher, bei der SAML Authentisierung in Verwendung war, werden die bestehenden IDP Metadaten sowie Standardwerte für die Zertifikate verwendet. Es wird jedoch kein Authenticator in der Konfiguration angezeigt. Dies kann durch erneutes Laden der Metadaten geändert werden.
In Umgebungen, in der ein Client Service auf Query Services einer entfernten Mindbreeze Installation verweist, muss der SAML IdP und das Zertifikat (gemeinsam als Authenticator bezeichnet) des Client Service auch in der Konfiguration der Gegenstelle eingerichtet werden. Das Query Service akzeptiert alle konfigurierten SAML IdPs, womit hier keine weitere Konfiguration notwendig ist. Bitte beachten Sie, dass beide Endpunkte den gleichen IdP und identische Zertifikate verwenden müssen, daher sollte das „Default SSL Zeritfikat“ nicht verwendet werden.
Wird ein SSL Zertifikat hinzugefügt und bei einem Authenticator geändert, so sollte der Identity Provider neu gestartet werden, damit die dadurch geänderten Metadaten neu geladen werden.
Andere SAML IDPs als die hier erwähnten werden möglicherweise nicht unterstützt. Wenn Sie einen anderen SAML IDP verwenden, kontaktieren Sie uns bitte. Wir sind sehr daran interessiert, welche IDPs unsere Kunden verwenden, um die Unterstützung dieser IDPs zu verbessern. Ein Grund, warum die SAML-Konfiguration Ihres IDPs nicht funktioniert wie dokumentiert, können CORS-Einstellungen sein. In der Dokumentation Konfiguration – Mindbreeze InSpire – CORS bei SAML finden Sie weitere Informationen dazu und mögliche Lösung des Problems.

Konfiguration eines Principals mittels SAML-Attributen

Mindbreeze unterstützt die Konfiguration von Mindbreeze-Principals nach einer erfolgreichen SAML-Anmeldung mittels SAML-Attributen. Dadurch kann die Authentifizierung an Ihre individuellen Anforderungen angepasst werden. Wenn sich ein Benutzer am Client Service anmeldet, können zusätzliche Rollen oder Aliase in den Attributen der SAML-XML-Datei mitgeschickt werden.

Darüber hinaus ist es möglich, die Identität des suchenden Benutzers zu überschreiben. Mit Hilfe von Regex-Regeln kann sichergestellt werden, dass nur gewünschte Attribute und Attributwerte zu einer erfolgreichen Authentifizierung führen.

Vorbereitung

Es ist notwendig, den SAML IDP so zu konfigurieren, dass die gewünschten Rollen oder Aliase im saml:AttributeStatement Block der SAML-Antwort an den Mindbreeze Client Service enthalten sind.

Dabei werden auch mehrere Attributwerte pro Attribut, bzw. mehrere Attribute mit dem gleichen Namen unterstützt. Hier sehen Sie einen Auszug aus einer Beispiel-XML-Datei:

<saml:AttributeStatement>

<saml:Attribute Name="Principal"

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">

<saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"