SAML Authentifizierung mit Mindbreeze

Installation und Einrichtung

Copyright ©

Mindbreeze GmbH, A-4020 Linz, .

Alle Rechte vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen und/oder Marken der jeweiligen Hersteller.

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 MindbreezePermanenter Link zu dieser Überschrift

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.xPermanenter Link zu dieser Überschrift

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 PartiesPermanenter Link zu dieser Überschrift

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:

<ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
    includeAttributeStatement="true" assertionLifetime="300000"
    assertionProxyCount="0" signResponses="conditional"
    signAssertions="never" encryptAssertions="conditional"
    encryptNameIds="never" />

Shibboleth Single Sign On ausschaltenPermanenter Link zu dieser Überschrift

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 verwendenPermanenter Link zu dieser Überschrift

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:

    <AttributeFilterPolicy id="releaseTransientIdToAnyone">
  
    <PolicyRequirementRule xsi:type="basic:ANY" />
      
<AttributeRule attributeID="principal">
        
<PermitValueRule xsi:type="basic:ANY" />
      
</AttributeRule>
    
</AttributeFilterPolicy>

Authentifizierung mit HTML Formular und KerberosPermanenter Link zu dieser Überschrift

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-ZertifikatenPermanenter Link zu dieser Überschrift

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:

<Connector port="8443" maxHttpHeaderSize="8192" maxSpareThreads="75"
  scheme="https" secure="true" clientAuth="true"
  
SSLEnabled="true" sslProtocol="TLS"
  keystoreFile="IDP_HOME/credentials/idp.jks" keystorePass="PASSWORD"
  truststoreFile="IDP_HOME/credentials/idp.jks" truststorePass="PASSWORD"/>

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 LDAPPermanenter Link zu dieser Überschrift

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 FiltersPermanenter Link zu dieser Überschrift

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>

  <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 AuthentifizierungPermanenter Link zu dieser Überschrift

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 3.xPermanenter Link zu dieser Überschrift

Principal Attribut Freigabe für MindbreezePermanenter Link zu dieser Überschrift

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

<AttributeFilterPolicy id="mesuid">

        <PolicyRequirementRule xsi:type="Requester" value="<mes_relying_party_id>" />

        <AttributeRule attributeID="uid">

            <PermitValueRule xsi:type="ANY" />

        </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 verwendet als SAML Principal.

SAML Subject NameID Generator KonfigurierenPermanenter Link zu dieser Überschrift

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

„shibboleth.SAML2AttributeSourcedGenerator“ ein mit folgende Settings:

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

        <ref bean="shibboleth.SAML2TransientGenerator" />

        <!-- Uncommenting this bean requires configuration in saml-nameid.properties. -->

        <!--

        <ref bean="shibboleth.SAML2PersistentGenerator" />

        -->

        <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 SetzenPermanenter Link zu dieser Überschrift

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

    <bean parent="RelyingPartyByName" c:relyingPartyIds="<mes_relying_party_id>">

            <property name="profileConfigurations">

                <list>

                    <bean parent="SAML2.SSO" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

                </list>

            </property>

     </bean>

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

Konfiguration mit Microsoft Active Directory Federation Services (ADFS)Permanenter Link zu dieser Überschrift

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

  1. 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).

  1. 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 von SAML in MindbreezePermanenter Link zu dieser Überschrift

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 ZertifikatsPermanenter Link zu dieser Überschrift

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 MetadatenPermanenter Link zu dieser Überschrift

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 3.x:

Die IDP Metadaten für Shibboleth 3.x können mehrere Zertifikate enthalten die für Assertion Signierung oder Verschlüsselung verwendet werden können. Es ist wichtig, dass vor Hochladen die IDP Metadaten editiert werden und von die IDPSSODescriptor Element die KeyDescriptor Einträge die nicht für die Mindbreeze Relying Party verwendet sind, entfernt werden.

Anmerkung für Microsoft ADFS:

  1. 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. Da Mindbreeze für Signierung und Verschlüsselung der Anfragen nur ein Zertifikat verwendet, müssen in dieser Datei alle KeyDescriptor Einträge bis auf einen entfernt werden. Bestehen bleiben muss der Eintrag im IDPSSODescriptor mit dem Attribut use=“signing“.

<IDPSSODescriptor protocolSupportEnumeration=“urn:oasis:names:tc:SAML:2.0:protocol“>

...

<KeyDescriptor use="signing">…</KeyDescriptor>

...

</IDPSSODescriptor>

Konfiguration der SAML ParameterPermanenter Link zu dieser Überschrift

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“ ListePermanenter Link zu dieser Überschrift

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 ServicesPermanenter Link zu dieser Überschrift

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 BemerkungenPermanenter Link zu dieser Überschrift

  • 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.