Weitergabe eingehender SAML-Web-Token in Liberty konfigurieren
Sie können einen Liberty-Server so konfigurieren, dass er ein SAML-Token in einem HTTP-Header als Authentifizierungstoken akzeptiert. Dieses Feature wird gewöhnlich für einen Proxy- oder REST-konformen Client verwendet, der SAML für einen authentifizierten Benutzer verwendet.
Informationen zu diesem Vorgang
Sie können einen Liberty-Server so konfigurieren, dass er ein SAML-Token in einem HTTP-Header als Authentifizierungstoken akzeptiert, indem Sie das Feature samlWeb-2.0 in Liberty aktivieren und inboundPropagation=required zusätzlich zu anderen Konfigurationsdaten festlegen. Die Konfiguration für die Eingangsweitergabe gleicht der Konfiguration des SAML-Web-Browser-SSO in Liberty.
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>
- Aktivieren Sie die Weitergabe eingehender SAML-Token. Dieser Liberty-Server stellt ein Standardelement
samlWebSso20 bereit.
<samlWebSso20 id="defaultSP"> </samlWebSso20>
Sie können dieses Standardelement samlWebSso20 verwenden oder ein neues Element samlWebSso20 erstellen, um die Weitergabe eingehender SAML-Token durch Hinzufügen von inboundPropagation=required zu aktivieren.<samlWebSso20 id="defaultSP" inboundPropagation="required" > </samlWebSso20>
Anmerkung: Wenn SAML konfiguriert und aktiviert ist, verwenden alle nicht authentifizierten Anforderung die SAML-Authentifizierung. Sie müssen einen Authentifizierungsfilter gemäß der Beschreibung in diesem Abschnitt konfigurieren, um festzulegen, welche Typen von Anforderungen die SAML-Authentifizierung verwenden können und welche nicht. - Sie müssen die PKIX-Trust-Engine konfigurieren, um die Vertrauenswürdigkeit des Zertifikats
in der Signatur durch PKIX-Validierung zu überprüfen. Zertifikate, die diese Validierung bestehen, werden als vertrauenswürdig anerkannt.
- Konfigurieren Sie <PKIXTrustEngine> und importieren Sie alle anerkannten SAML-Unterzeichnerzertifikate in den Standardtruststore des Liberty-Servers oder in den trustAnchor der PKIXTrustEngine.
- Optional: Konfigurieren Sie trustedIssuers, um den Namen des Ausstellers des SAML-Tokens wie in der SAML-Zusicherung angegeben aufzulisten, wenn das Zertifikat nicht vertrauenswürdig genug ist.
Nachfolgend ist eine Beispielkonfiguration aufgeführt:<samlWebSso20 id="defaultSP" inboundPropagation="required" headerName="saml_token" signatureMethodAlgorithm="SHA1"> <pkixTrustEngine trustAnchor="serverStore" /> </samlWebSso20>
- Optional: Sie können ein Element headerName hinzufügen, um den Namen eines HTTP-Anforderungsheaders
zu definieren, der ein SAML-Token enthält. Wenn dieses Konfigurationsattribut nicht definiert ist, sucht der Liberty-Server
nach dem Headernamen saml, Saml und SAML, um das SAML-Token zu ermitteln. Der SAML-Token-Header
in der HTTP-Anforderung kann eines der folgenden Formate haben:
Authorization=[<headerName>=<SAML_HERE>] Authorization=[<headerName>="<SAML_HERE>"] Authorization=[<headerName> <SAML_HERE>] <headerName>=[<SAML_HERE>]
Das SAML-Token muss Base-64- oder UTF-8-codiert und kann im GZIP-Format komprimiert sein.
Anmerkung: Der Name des SAML-Token-Headers muss eine URL-sichere Zeichenfolge sein und darf keine führenden und abschließenden Leerzeichen enthalten. - Optional: Sie können konfigurieren, wie ein authentifiziertes Subjekt aus SAML erstellt wird.
Der Liberty-Service-Provider 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 der NameID-Wert 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 mehrere samlWebSso20-Elemente konfigurieren und jedes samlWebSso20-Element verweist auf ein eindeutiges authFilter-Element. Alle authFilter-Elemente müssen einander ausschließen. Wenn mehrere samlWebSso20-Elemente konfiguriert sind, hat jedes Element eine eigene Authentifizierungsrichtlinie und eigene Verwendungsregeln.
- Optional: Konfigurieren Sie Signaturvoraussetzungen unter Berücksichtigung der folgenden Aspekte:
Der Standardsignaturalgorithmus ist SHA256. Wenn Sie den Algorithmus ändern müssen, verwenden Sie dazu das Attribut signatureMethodAlgorithm.
- 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
Client 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 den Authentifizierungsfilter. Mit authnFilter können Sie definieren, welches
samlWebSso20-Element die Authentifizierungsanforderung für die Weitergabe eingehender Token
verarbeitet.
Weitere Informationen zum Konfigurieren des Authentifizierungsfilters finden Sie unter Authentifizierungsfilter.
Ergebnisse


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