SAML-Web-Browser-SSO in Liberty konfigurieren
Sie können einen Liberty-Server so konfigurieren, dass er als Service-Provider für SAML-Web-Browser-SSO (Single Sign-on) fungiert.
Informationen zu diesem Vorgang
Sie können einen Liberty-Server als SAML-Web-SSO-Service-Provider konfigurieren, indem Sie neben weiteren Konfigurationsdaten das Feature samlWeb-2.0 in Liberty aktivieren.
Vorgehensweise
- Fügen Sie das Liberty-Feature samlWeb-2.0 der Datei
server.xml hinzu, indem Sie die folgende Elementdeklaration im Element featureManager hinzufügen.
<feature>samlWeb-2.0</feature>
- Liberty stellt ein samlWebSso20-Standardelement bereit.
<samlWebSso20 id="defaultSP"> </samlWebSso20>
In dieser Standardkonfiguration wird von den folgenden Standardwerten ausgegangen:- AssertionConsumerService-URL:
https://<Hostname>:<SSL-Port> /ibm/saml20/defaultSP/acs
- SP-Metadaten-URL (Service-Provider):
https://<Hostname>:<SSL-Port> /ibm/saml20/defaultSP/samlmetadata
Sie können einen Browser verwenden, um die Metadaten für diesen Service-Provider (SP) unter dieser URL herunterzuladen, und die URL dem SAML-Identitätsprovider bereitstellen, um diesen SP und Identitätsprovider (IdP) einzubinden.
- Die IdP-Metadatendatei muss in das Verzeichnis resources/security auf dem Server kopiert und idpMetadata.xml genannt werden.
- Der Name des Ausstellers für die SAML-Zusicherung wird als Sicherheitsrealm verwendet und NameID wird als Principal zum Erstellen eines authentifizierten Subjekts aus der SAML-Zusicherung verwendet.
- Die SAML-Authentifizierungsanforderung (AuthnRequest) wird mit einem privaten Schlüssel im Standardkeystore des Servers signiert, wenn das Attribut KeyStoreRef nicht angegeben ist. Wenn keyAlias nicht konfiguriert ist, ist samlsp der Standardschlüsselalias. Ist keyAlias nicht konfiguriert und enthält der Keystore nur einen einzigen privaten Schlüssel, wird der private Schlüssel in der Signatur verwendet.
Anmerkung: Wenn Sie eine neue Service-Provider-Instanz erstellt und defaultSP nicht mehr erforderlich ist, müssen Sie die Instanz defaultSP explizit inaktivieren, indem Sie der Datei server.xml Folgendes hinzufügen.<samlWebSso20 id="defaultSP" enabled="false"> </samlWebSso20>
Anmerkung: Sie müssen eine sichere URL-Zeichenfolge ungleich null als ID für samlWebSso20 angeben. Fehlt die ID, wird das Konfigurationselement ausgelassen und nicht als defaultSP behandelt.Anmerkung: Wenn SAML konfiguriert und aktiviert ist, verwenden alle nicht authentifizierten Anforderung die SAML-Authentifizierung. Um die Anforderungstypen zu konfigurieren, die die SAML-Authentifizierung verwenden bzw. nicht verwenden sollen, müssen Sie, wie in Schritt 15 beschrieben, einen Authentifizierungsfilter konfigurieren. - AssertionConsumerService-URL:
- Optional: Sie können <samlWebSso20 id="defaultSP"> der Datei
server.xml hinzufügen und den Service-Provider defaultSP anpassen. Beispiel:
- idpMetadata: Fügen Sie diesen Parameter hinzu, um anstelle der Standardposition und des Standarddateinamens (${server.config.dir}/resources/security/idpMetadata.xml) eine andere IdP-Metadatenposition und einen anderen Dateinamen anzugeben.
- userIdentifier: Fügen Sie diesen Parameter hinzu, um einen SAML-Attributnamen auszuwählen, dessen Wert als Principalname verwendet wird.
- groupIdentifier: Fügen Sie diesen Parameter hinzu, um einen SAML-Attributnamen auszuwählen, dessen Werte als Gruppenmember im Subjekt eingeschlossen werden.
- realmName: Verwenden Sie diesen Parameter, um den Realmnamen für die Identifizierung eines SAML-Principals in diesem Service-Provider explizit anzugeben. Der Standardrealmname ist der Name des SAML-Ausstellers.
- Optional: Sie können neue samlWebSso20-Elemente mit einer anderen ID
erstellen. Wenn Sie beispielsweise ein neues Element mit einer ID mySP erstellen, erstellen Sie effektiv eine neue SAML-SP-Instanz
mit einer neuen AssertionConsumerService-URL:
https://<Hostname>:<SSL-Port>/ibm/saml20/mySP/acs
Anmerkung: Die ID, die Sie für samlWebSso20 auswählen, ist in der URL des SP enthalten, z. B. in der AssertionConsumerService-URL und in der Metadaten-URL. Die ID samlWebSso20 darf nicht leer sein und keine nicht sicheren URL-Zeichen enthalten. - Optional: Sie können eine Trust-Engine konfigurieren. Der Liberty-SAML-SP unterstützt zwei Trust-Engine-Typen:
- Metadaten-Trust-Engine: Validiert die Signatur anhand der in den konfigurierten IdP-Metadaten bereitgestellten Informationen.
- PKIX-Trust-Engine: Validiert die Vertrauenswürdigkeit des Zertifikats in der Signatur mit PKIX-Validierung. Zertifikate, die diese Validierung bestehen, werden als vertrauenswürdig anerkannt.
Die Metadaten-Trust-Engine ist die Standard-Trust-Engine. Wenn Sie die PKIX-Trust-Engine verwenden möchten, müssen Sie das Element PKIXTrustEngine hinzufügen und den richtigen Vertrauensanker (trustAnchor) definieren.
- Optional: Sie können konfigurieren, wie ein authentifiziertes Subjekt aus SAML erstellt wird.
Der Liberty-SP erstellt ein Subjekt standardmäßig direkt aus einer SAML-Zusicherung,
ohne dass eine lokale Benutzerregistry erforderlich ist. Dies entspricht der Konfiguration mapToUserRegistry=No.
Weitere Konfigurationsoptionen sind mapToUserRegistry=User und mapToUserRegistry=Group.
- mapToUserRegistry=No: Der Name des SAML-Ausstellers ist ein Realm und die NameID wird zum Erstellen eines Principalnamens und eindeutigen Sicherheitsnamens im Subjekt verwendet. Es wird kein Gruppenmember eingeschlossen. Sie können die Attribute userIdentifier, realmIdentifier, groupIdentifier und userUniqueIdentifier konfigurieren, um ein authentifiziertes Subjekt mit angepasstem Benutzernamen, Realmnamen, Gruppenzugehörigkeit und eindeutiger Sicherheits-ID zu erstellen.
- mapToUserRegistry=User: Wählen Sie diese Option aus, wenn Sie einen SAML-Benutzer anhand Ihrer lokalen Benutzerregistry validieren und das Benutzersubjekt basierend auf der lokalen Registry erstellen möchten.
- mapToUserRegistry=Group: Wählen Sie diese Option aus, wenn Sie eine SAML-Gruppe anhand Ihrer lokalen Benutzerregistry validieren und ein Subjekt erstellen möchten, das diese validierten Gruppen enthält. Diese Option ähnelt der Option mapToUserRegistry=No, aber bei dieser Option werden die Gruppenzugehörigkeiten anhand der lokalen Benutzerregistry überprüft.
- Optional: Sie können die Liberty-SAML-SPI com.ibm.wsspi.security.saml2.UserCredentialResolver als Benutzerfeature für die dynamische Zuordnung einer SAML-Zusicherung und eines Liberty-Subjekts implementieren.
- Optional: Sie können Regeln definieren, die dem IdP vorgeben, wie ein Benutzer authentifiziert werden soll, indem Sie mindestens eines der folgenden Attribute bei Verwendung eines vom SP eingeleiteten Web-SSO-Ablaufs konfigurieren: forceAuthn, isPassive, allowCreate, authnContextClassRef und authnContextComparisonType.
- Optional: Sie können ein erforderliches NameID-Format in der AuthnRequest mit dem Attribut nameIDFormat definieren. Sie können ein NameID-Format angeben, das in der SAML-Spezifikation definiert ist, oder das Schlüsselwort customize verwenden, um das angepasste NameId-Format anzugeben.
- Optional: Sie können mehrere SP- und IdP-Einbindungspartner konfigurieren, indem Sie mehrere samlWebSso20-Elemente erstellen, wobei sich jedes samlWebSso20-Element auf ein eindeutiges authFilter-Element bezieht. Alle authFilters müssen einander ausschließen. Sind mehrere samlWebSso20-Elemente konfiguriert, kann jedes dieser Element Single Sign-on bei seinem eingebundenen Identitätsprovider durchführen und hat eine eigene Authentifizierungsrichtlinie und Verarbeitungsregeln.
- Optional: Fügen Sie Unterstützung für vom IdP eingeleitetes nicht angefordertes SSO hinzu.
Der Liberty-SAML-SP unterstützt vom IdP eingeleitetes nicht angefordertes SSO mit und ohne die Voraussetzung von lokalen IdP-Metadaten. Wenn Sie keine IdP-Metadaten haben
oder wenn Sie nicht angefordertes SSO verwenden möchten, um eine Einbindung mehrerer Identitätsprovider mit einem einzigen Liberty-SP zu ermöglichen,
müssen Sie die folgenden Konfigurationen hinzufügen:
- Konfigurieren Sie <PKIXTrustEngine> und importieren Sie alle IdP-Unterzeichnerzertifikate in den Standardtruststore des Liberty-Servers oder in den trustAnchor der PKIXTrustEngine.
- Konfigurieren Sie trustedIssuers, um den Namen des Ausstellers des IdP wie in der SAML-Zusicherung anzugeben. Der Name des Ausstellers wird als EntityID in den Metadaten verwendet.
- Wenn Sie möchten, dass nur nicht angefordertes SSO unterstützt wird, können Sie vom SP eingeleitetes nicht angefordertes SSO, wie im nächsten Schritt beschrieben, konfigurieren. Dieses Szenario ist hilfreich, wenn der Sicherheitskontext des Benutzers im SP, der SAML zugeordnet ist, ungültig wird. Der SP kann den Benutzer dann wieder an den IdP umleiten, um nicht angefordertes SSO automatisch erneut zu starten.
- Optional: Fügen Sie Unterstützung für vom SP eingeleitetes nicht angefordertes SSO hinzu. Der Liberty-SAML-SP verwendet konfigurierte IdP-Metadaten, um eine angeforderte SAML-Authentifizierungsanforderung (AuthnRequest) durchzuführen. Der Liberty-SP kann nicht authentifizierte Anforderungen an eine vorkonfigurierte Anmeldeanwendung weiterleiten, ohne AuthnRequest zu verwenden. Dieses Szenario ist hilfreich, wenn eine Geschäftsanwendung Vorabauthentifizierungsverarbeitung durchführt, bevor sich ein Benutzer beim SAML-IdP authentifizieren kann, oder wenn der SAML-IdP vor dem Liberty-SP verborgen werden muss. Zum Konfigurieren dieses Szenarios fügen Sie das Attribut loginPageURL hinzu und legen als Wert eine URL fest, die einen Benutzer anweisen kann, sich beim SAML-IdP zu authentifizieren.
- Optional: Konfigurieren Sie Signaturvoraussetzungen unter Berücksichtigung der folgenden Aspekte:
- SAML-Zusicherung. Alle SAML-Zusicherungen müssen digital vom SAML-IdP signiert sein. In dem seltenen Fall, dass Sie eine nicht signierte Zusicherung akzeptieren möchten, können Sie wantAssertionsSigned=false explizit konfigurieren.
- Der Standardsignaturalgorithmus ist SHA256. Wenn Sie den Algorithmus ändern müssen, verwenden Sie dazu das Attribut signatureMethodAlgorithm.
- Wenn Sie die SAML-Authentifizierungsanforderung (AuthnRequest) nicht signieren möchten, können Sie authnRequestsSigned=false festlegen.
- Optional: Sie können eine SP-Authentifizierungssitzung und ein entsprechendes Cookie
konfigurieren. Nach der Prüfung und Verarbeitung der SAML-Zusicherung behält der Liberty-SAML-SP eine authentifizierte Sitzung zwischen dem Browser und dem SPI bei, ohne
ein LTPA-Cookie zu verwenden. Das Zeitlimit für die authentifizierte Sitzung
ist in <saml:AuthnStatement> (sofern vorhanden) auf SessionNotOnOrAfter oder
wie in der Datei server.xml konfiguriert auf sessionNotOnOrAfter gesetzt. Dabei ist der Standardwert
120 Minuten. Der Name des Sitzungscookies wird automatisch generiert und Sie können den Cookienamen mit dem Attribut spCookieName anpassen, um
den gewünschten Namen anzugeben.
Wenn Sie möchten, dass der Liberty-SP ein LTPA-Cookie aus der SAML-Zusicherung erstellt und das LTPA-Cookie für nachfolgende Authentifizierungsanforderungen verwendet, können Sie die Konfiguration disableLtpaCookie=false hinzufügen. Wenn das LTPA-Cookie von anderen Servern gemeinsam genutzt werden soll, müssen Sie das Konfigurationsattribut allowCustomCacheKey="false" hinzufügen.
Anmerkung: Wenn Sie disableLtpaCookie="false" und allowCustomCacheKey="false" konfigurieren, stellen Sie sicher, dass sich ein SAML-Benutzername nicht direkt bei einer lokalen Benutzerregistry authentifiziert, die verhindert, dass ein Benutzer zwei Accounts hat. - Konfigurieren Sie bei Bedarf den Authentifizierungsfilter.
Wenn das Feature samlWeb-2.0 aktiviert ist, wird jede authentifizierte Anforderung von einem einzigen SAML-SP authentifiziert. Wenn Sie ein angepasstes samlWebSso20-Element definieren, werden alle Authentifizierungsanforderungen von dieser samlWebSso20-SP-Instanz bearbeitet. Andernfalls wird die gesamte Authentifizierung von der Standardinstanz defaultSP bearbeitet. Sie können authnFilter verwenden, um zu definieren, welche SP-Instanz die Authentifizierungsanforderung bearbeiten soll.
Weitere Informationen zum Konfigurieren des Authentifizierungsfilters finden Sie unter Authentifizierungsfilter.
- Optional: Konfigurieren Sie den SAML-SP in einem Cluster.
Wenn Anwendungsserver Cluster-Member sind und Sie einen Router oder Reverse-Proxy-Server verwenden, um Ihre Anforderungen weiterzuleiten, müssen Sie die folgenden Aufgaben ausführen:
- Der Router und der Proxy-Server müssen so konfiguriert werden, dass sie die Sitzungsaffinität unterstützen.
- Fügen Sie das Konfigurationsattribut spHostAndPort jedem Anwendungsserver hinzu und legen Sie als Wert den Hostnamen und Port des Routers und Proxy-Servers fest, z. B. spHostAndPort="https://myRouter.com:443".
- Generieren Sie ein X509-Zertifikat zum Signieren der SAML-Authentifizierungsanforderung (AuthnRequest) und verwenden Sie dieses Zertifikat in allen Anwendungsservern. Sie können beispielsweise einen Keystore erstellen, der nur dieses Zertifikat enthalten soll, und KeyStoreRef hinzufügen, um diesen Keystore in allen Anwendungsservern zu referenzieren.
- Wenn createSession="true" in einer Clusterumgebung nicht definiert ist, tritt bei der Belastungsausführung der folgende Fehler auf:
E CWWKS5029E: Der Relay-Status [sp_initial_KGe22fCWKG1lD9VkOMuDz0Ji8pBxFPnU] in der Antwort des Identitätsproviders (IdP) wurde nicht erkannt.
Im Folgenden finden Sie eine Beispielclusterkonfiguration:<keyStore id="samlKeyStore" password="<password>" location="${server.config.dir}/resources/security/<samlKey.jks>" /> <samlWebSso20 id="defaultSP" spHostAndPort="https://<IHS host>:<port>" keyStoreRef="samlKeyStore" createSession="true" allowCustomCacheKey="false" disableLtpaCookie="false" mapToUserRegistry="User"> </samlWebSso20>
Ergebnisse


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=twlp_config_saml_web_sso
Dateiname: twlp_config_saml_web_sso.html