Anwendungsintegration (Vertrauende Seite)
casso126figsbrde
HID_application-integration
Im Dialogfeld "Anwendungsintegration" können Sie konfigurieren, wie das Federation-System die folgenden Aufgaben verarbeitet:
- Weiterleiten von Benutzern auf die Zielanwendung auf der vertrauenden Seite.
- Zuordnen von Assertionsattributen zu Attributen, die die Zielanwendung verwendet.
- Erstellen von Benutzerkonten durch eine Bereitstellungsanwendung eines Drittanbieters.
- Umleiten von Benutzern, wenn die Authentifizierung fehlschlägt.
Konfiguration der Zielanwendung (SAML, WSFED|OAuth)
Im Abschnitt "Zielanwendung" können Sie die Zielanwendung angeben, und Sie könne angeben, wie Benutzer auf die Zielanwendung weitergeleitet werden.
- UmleitungsmodusGibt die Methode an, nach der die vertrauende Seite den Benutzer an die Zielressource umleitet.Standard:Keine DatenDie Optionen für dieses Feld sind Folgende:
- Keine Daten (Standard)Der Benutzer wird an die Zielanwendung umgeleitet, indem eine HTTP-302-Umleitung mit einem Sitzungs-Cookie und ohne andere Daten durchgeführt wird.
- Cookie-DatenDer Benutzer wird durch eine HTTP 302-Weiterleitung an die Zielanwendung geleitet. Diese Weiterleitung umfasst ein Sitzungs-Cookie und zusätzliche Cookie-Daten, die an der behauptenden Seite konfiguriert werden.Für SAML 1.1 und 2.0 werden durch das Aktivieren dieser Option folgende zusätzliche Feld angezeigt:Cookie-Daten des URL-VerschlüsselungsattributsLegt fest, dass das Attribut, das im Cookie gesendet wird, URL-verschlüsselt ist. Das Attribut ist URL-verschlüsselt, weil die Zeichen in der URL einen eindeutigen Zweck erfüllen, anders als der Standard für eine URL. Diese Einstellung ist nur gültig, wenn "Cookie-Daten" als Umleitungsmodus festgelegt wird.Wenn Sie ein Sonderzeichen in der Attributtabelle der Anwendung angeben, wählen Sie diese Option aus. Prüfen Sie zum Beispiel diese Einstellung für Attribute mit japanischen Zeichen. Sonderzeichen können aus der Drop-down-Liste hinzugefügt oder manuell eingegeben werden. Zusätzlich muss die Zielanwendung den Namen und den Wert des empfangenen Anwendungsattributs URL-dekodieren.
- Quelloffenes CookieDer Benutzer wird an die Zielanwendung umgeleitet, indem eine HTTP-302-Umleitung mit dem quelloffenen Cookie und ohne andere Daten durchgeführt wird. Die Kundenanwendung entschlüsselt das verschlüsselte Cookie, um die Benutzerinformationen abzurufen.Wenn die vertrauende Seite eine Assertion mit mehreren Attributwerten empfängt, werden alle Werte an die Zielanwendung übergeben.
- Quelloffener Cookie-PostDer Benutzer wird an die Zielanwendung umgeleitet, indem eine HTTP-302-Umleitung mit dem quelloffenen Cookie durchgeführt wird. Allerdings werden die Daten in einer HTTP-POST-Anforderung gesendet. Wenn Sie besorgt sind, dass Daten aufgrund der Längenbegrenzung für Cookie-Daten verloren gehen können, wählen Sie diese Option aus.Wenn Sie die Option "Quelloffenes Cookie" oder "Quelloffener Cookie-Post" auswählen, zeigt die Benutzeroberfläche die folgenden zusätzlichen Felder an:
- Name des quelloffenen CookiesGibt den Namen des quelloffenen Cookies ein.
- VerschlüsselungstransformationZeigt den Verschlüsselungsalgorithmus an, der das quelloffene Cookie verschlüsselt.Wenn Sie einen der FIPS-kompatiblen Algorithmen (AES-Algorithmen) auswählen, muss das Zielsystem einenCA SiteMinder® Federation-SDK verwenden, um das Cookie zu verwenden. Das SDK muss sich auf dem gleichen Server wie die Zielanwendung befinden.Wenn Sie das .NET SDK verwenden, um das Cookie zu verbrauchen, dann verwenden Sie den Verschlüsselungsalgorithmus "AES128/CBC/PKCS5Padding".
- VerschlüsselungskennwortZeigt das Kennwort an, das verwendet wird, um das Cookie zu verschlüsseln. Die Felder "Verschlüsselungskennwort" und "Kennwort bestätigen" sind für das quelloffene Cookie erforderlich. Allerdings ist das Kennwort für das Legacy-Cookie optional.Wichtig!Wenn Sie ein Kennwort für das Legacy-Cookie angeben, definieren Sie den gleichen Wert für denCA SiteMinder® Federation-Java-SDK. Durch das Kennwort kann das SDK das Cookie entschlüsseln. Die Werte werden in einer Out-Of-Band-Kommunikation freigegeben.
- Kennwort bestätigenBestätigt den Eintrag für das Verschlüsselungskennwort.
- HMAC aktivierenLegt fest, dass ein HMAC (Hash Message Authentication Code) mithilfe des Verschlüsselungskennworts in diesem Dialogfeld generiert wird.MACs (Message authentication codes) können die Integrität der Informationen prüfen, die zwischen zwei Parteien gesendet werden. Die zwei Parteien nutzen gemeinsam einen geheimen Schlüssel für die Berechnung und Prüfung der Meldungsauthentifizierungswerte. Ein HMAC (Hash Message Authentication Code) ist ein MAC-Mechanismus, der auf kryptografischen Hash-Funktionen basiert. HMACs haben eine Meldungseingabe und einen geheimen Schlüssel, den nur der Absender und der zukünftige Empfänger der Meldung kennen.Wenn Sie das Kontrollkästchen "HMAC aktivieren" auswählen, generiert das System einen HMAC-Wert für das quelloffene Cookie. Der HMAC-Wert wird dann dem Wert des quelloffenen Cookies vorangestellt, und anschließend wird die gesamte Zeichenfolge verschlüsselt. Das System fügt die verschlüsselte Zeichenfolge in das quelloffene Cookie ein, das dann an die Zielanwendung übergeben wird.
- Angegebenes Cookie aktivierenGibt an, dass der Wert des quelloffenen Cookies in doppelte Anführungszeichen eingeschlossen wird. Diese Angabe ermöglicht die Verarbeitung des Cookies, wenn nicht unterstützte Zeichen in den Cookie-Wert eingeschlossen sind.
- HTTP-Header (nur SAML 1.1 und 2.0)Der Benutzer wird an die Zielanwendung mit HTTP-Headern und ohne andere Daten umgeleitet. Der Richtlinienserver kann mehrere Attributwerte in einem einzelnen Header bereitstellen, indem die einzelnen Werte durch Kommas getrennt werden.
- Dauerhafte AttributeDer Benutzer wird mit einer HTTP-302-Umleitung und einem Sitzungs-Cookie und ohne andere Daten umgeleitet. Dieser Modus weist den Richtlinienserver auch an, Attribute zu speichern, die aus einer Assertion im Sitzungsspeicher extrahiert wurden.CA Single Sign-onkann dann die Attribute als HTTP-Header-Variablen bereitstellen.Wichtig!Um diese Option anzuzeigen, aktivieren Sie den Sitzungsspeicher mithilfe der Richtlinienserver-Verwaltungskonsole von .Wenn Sie dauerhafte Attribute auswählen und die Assertion leere Attribute enthält, wird der Wert NULL in den Sitzungsspeicher geschrieben. Der Wert NULL agiert als Platzhalter für das leere Attribut und wird mithilfe des Attributs an die Anwendung übergeben.
- casso126figsbrdeServer-UmleitungWeist das Federation-System an, in der Assertion empfangene Header- und Cookie-Informationen an die Zielanwendung weiterzugeben. Der Service, der Assertionen nutzt, erfasst die Benutzeranmeldeinformationen und leitet den Benutzer dann an die Zielanwendungs-URL mithilfe Java-Serverseitiger Umleitungen weiter.Befolgen Sie zum Verwenden dieses Modus folgende Anforderungen:
- Alle Zielanwendungsdateien müssen im Anwendungsstammverzeichnis sein. Dieses Verzeichnis ist entweder:
- Web-Agent:web_agent_home\webagent\affwebservices
- SPS-Federation-Gateway:sps_home\secure-proxy\Tomcat\webapps\affwebservices
- Die Ziel-URL, die Sie angeben, mussrelativzum Kontext des Servlets sein, das die Assertion in Anspruch nimmt. Der Kontext ist/affwebservices/public/, und der Stamm des Kontexts ist/affwebservices/, der den Stamm der Federation-WebServices-Anwendung bildet. Schließen Sie den Kontext nicht in der URL ein. Die Ziel-URL kann beispielsweise/applications/doc1.htmlsein.
- Definieren Sie Bereiche, Regeln und Richtlinien, um Zielressourcen zu schützen. Die Bereiche müssen mindestens den Wert "/affwebservices/" im Ressourcenfilter enthalten.
- Installieren Sie eine benutzerdefinierte Java- oder JSP-Anwendung auf dem Server, auf dem die Federation-Webservices-Anwendung bereitgestellt wird. Das Web-Agent-Optionspaket oder das SPS-Federation-Gateway installiert die Federation-Webservices.Die Java-Servlet-Technologie ermöglicht Anwendungen, Informationen zwischen zwei Ressourcenanfragen mithilfe der setAttribute-Methode auf der ServletRequest-Schnittstelle weiterzugeben.Der Service, der Assertionen nutzt, sendet die Benutzerattribute an die Zielanwendung, bevor der Benutzer an das Ziel umgeleitet wird. Der Service sendet die Attribute durch das Erstellen eines java.util.HashMap-Objekts. Das Attribut, das das HashMap von SAML-Attributen enthält, lautet Netegrity.AttributeInfo.Der Service, der Assertionen nutzt, gibt zwei andere Java.lang.String-Attribute an die benutzerdefinierte Anwendung weiter:
- Das "Netegrity.smSessionID"-Attribut stellt die Sitzungs-ID dar.
- Das "Netegrity.userDN"-Attribut stellt den Benutzer-DN dar.
Die Zielanwendung liest diese Objekte aus der HTTP-Anforderung und verwendet die in den Hashzuordnungsobjekten gefundenen Daten.
- ZielGibt die URL der Zielanwendung auf der vertrauenden Seite an. Der Wert, den Sie hier eingeben, wird die standardmäßige Zielressource. Diese URL muss einen voll qualifizierten Domänennamen enthalten, es sei denn, Sie wählen "Server-Umleitung" als Umleitungsmodus aus. Für "Server-Umleitung" muss die Ziel-URL, die Sie angeben,relativzum Kontext des Servlets sein, das die Assertion in Anspruch nimmt. Der Kontext ist/affwebservices/public/. Schließen Sie den Kontext nicht in der URL ein. Die Ziel-URL kann beispielsweise/applications/doc1.htmlsein.Wenn ein Proxy sich vor dem Server mit der Zielressource befindet, geben Sie die URL für den Proxy-Host ein. Der Proxy verarbeitet alle Federation-Anforderungen lokal. Der Proxy-Host kann ein System sein, das sich vor dem Zielserver befindet. Der Proxy-Host kann auchSingle Sign-Onselbst sein, sofern Sie direkt über das Internet darauf zugreifen. Wenn Sie mit einem Proxy arbeiten, muss die URL, die Sie als Ziel angeben, letztendlich durchSingle Sign-Ongehen. Wenn die Basis-URL beispielsweise "fed.demo.com" ist und die Backend-Serverressource "mytarget/target.jsp" ist, dann ist der Wert für dieses Feld "http://fed.demo.com:5555/mytarget/target.jsp".Bei SAML 2.0 können Sie dieses Feld leer lassen, wenn Sie es mit dem Abfrageparameter "RelayState" überschreiben. Der Abfrageparameter "RelayState" kann ein Teil der URL sein, die Single Sign-On auslöst. Um diese Übersteuerung zu aktivieren, wählen Sie das Kontrollkästchen "Relay-Status überschreibt Ziel" aus.
- Zeitlimit des LeerlaufsBestimmt die Zeit, die eine autorisierte Benutzersitzung inaktiv bleiben kann, bevor der Agent die Sitzung beendet. Wenn Sie besorgt sind, dass Benutzer nach dem Zugriff auf eine geschützte Ressource ihre Workstations verlassen lassen, dann legen Sie das Zeitlimit des Leerlaufs auf einen kurzen Zeitraum fest. Wenn die Sitzung das Zeitlimit überschreitet, müssen Benutzer erneut authentifiziert werden, bevor Sie wieder auf die Ressourcen zugreifen.Diese Einstellung ist standardmäßig aktiviert. Deaktivieren Sie das Kontrollkästchen, um kein Zeitlimit des Leerlaufs anzugeben. Das standardmäßige Zeitlimit des Leerlaufs ist eine Stunde.Hinweis:Die Sitzung läuft tatsächlich innerhalb eines bestimmten Wartungszeitraums, nach dem angegebenen Zeitlimit des Leerlaufs, ab. Die Sekundenanzahl, die im folgenden Registrierungsschlüssel angegeben ist, legt den Zeitraum fest:HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\CA Single Sign-on\CurrentVersion\SessionServer\MaintenancePeriodZum Beispiel legen Sie das Zeitlimit des Leerlaufs auf 10 Minuten fest. Sie legen auch die Registrierung für den Wartungszeitraum auf den Standardwert fest. Der längste Zeitraum, bevor eine Sitzung das Zeitlimit aufgrund von Inaktivität überschreitet, ist 11 Minuten (Zeitlimit + Wartungszeitraum).Um diese Funktion mit dem standardmäßigen Authentifizierungsschema zu verwenden, muss der Web-Agent auf "Cookie-Anforderung" konfiguriert sein.Beachten Sie folgende Probleme:
- Aktivieren Sie bei dauerhaften Sitzungen das Zeitlimit des Leerlaufs, und legen Sie es auf einen Wert fest, der höher ist als der Validierungszeitraum.
- Sie können diese globale Einstellung überschreiben, indem Sie das Antwortattribut "WebAgent-OnAuthAccept-Session-Idle-Timeout" verwenden. Ein Nullwert gibt an, dass die Sitzung nicht aufgrund von Inaktivität beendet wird.
Standard: 60 SekundenStundenGibt die Stundenanzahl für das Zeitlimit des Leerlaufs an.MinutenGibt die Minutenanzahl für das Zeitlimit des Leerlaufs an.Maximales ZeitlimitBestimmt die Zeit, die eine Benutzersitzung maximal aktiv sein kann, bevor der Agent den Benutzer zur erneuten Authentifizierung auffordert.Diese Einstellung ist standardmäßig aktiviert. Deaktivieren Sie das Kontrollkästchen, um keine maximale Sitzungsdauer anzugeben. Die maximale Sitzungsdauer ist standardmäßig auf zwei Stunden festgelegt.- StundenGibt die Stundenanzahl für die maximale Sitzungsdauer an.
- MinutenGibt die Minutenanzahl für die maximale Sitzungsdauer an.
Um diese Funktion mit dem standardmäßigen Authentifizierungsschema zu verwenden, konfigurieren Sie den Web-Agenten auf "Require Cookies" (Cookies sind erforderlich).Hinweis:Sie können diese Einstellung überschreiben, indem Sie das Antwortattribut "WebAgent-OnAuthAccept-Session-Max-Timeout" verwenden. - Relay-Status überschreibt Ziel (Nur SAML 2.0)(Optional) Ersetzt den Wert des Felds "Ziel" mit dem Wert für den Abfrageparameter "Relay-Status" in der Anforderung, die Single Sign-On initiiert. Wenn Sie dieses Kontrollkästchen auswählen, haben Sie eine größere Kontrolle über das Ziel, da Sie mithilfe des Abfrageparameters "Relay-Status" das Ziel dynamisch definieren können.
- Domäne der Ziel-URL validieren(Nur SAML 2.0) Weist den Richtlinienserver an, den Wert des Felds "Ziel" oder das Ziel im Abfrageparameter "RelayState" mit dem Parameter "ValidFedTargetDomain" im Agent-Konfigurationsobjekt zu vergleichen. Diese Einstellung stellt sicher, dass die vertrauende Seite den Zugriff auf die angeforderte Zieldomäne erlaubt.
- Variable der Authentifizierungssitzung beibehaltenErmöglicht es, dass Informationen aus einer Assertion in den Sitzungsspeicher gespeichert und in den Sitzungskontext geschrieben werden. Wenn Sie Assertionsinformationen im Sitzungsspeicher speichern, können Sie die Informationen für Funktionen, wie z. B. aktive Antworten und Richtlinienausdrücke, verwenden. Wenn Sie dieses Kontrollkästchen aktivieren, enthalten die gespeicherten Assertionsinformationen die Werte "NameID", "NameIDFormat", "ProviderID" und "AuthnContext".Diese Einstellung unterscheidet sich von Option "Dauerhafte Attribute" für den Umleitungsmodus zur Zielanwendung. Wenn Sie Variablen der Authentifizierungssitzung beibehalten, dann können die verfügbaren Informationen nicht nur als einfache HTTP-Header verwendet werden.Wichtig!Um dieses Kontrollkästchen anzuzeigen, aktivieren Sie den Sitzungsspeicher mithilfe der Richtlinienserver-Verwaltungskonsole. Aktivieren Sie auch das Kontrollkästchen "Dauerhafte Sitzung verwenden" in den SSO-Einstellungen der Partnerschaftskonfiguration.
- Abfrageparameter überschreibt Standardziel (Nur SAML 1.1)(Optional) Ersetzt den Wert des Felds "Ziel" mit dem Wert für den Abfrageparameter "Ziel" in der Anforderung, die Single Sign-On initiiert. Wenn Sie dieses Kontrollkästchen auswählen, haben Sie eine größere Kontrolle über das Ziel, da Sie mithilfe des Abfrageparameters das Ziel dynamisch definieren können.
- Gültigkeitszeitraum des CookiesLegt die Zeitdauer fest, die das quelloffene Cookie gültig ist. Der Gültigkeitszeitraum wird im Cookie platziert, sodass die Zielanwendung prüfen kann, ob das Cookie gültig ist, bevor die Daten verbraucht werden. Sie können diesen Wert für das quelloffene Cookie und für Umleitungsmodi der HTTP-Header festlegen (HTTP-Header verwenden das quelloffene Cookie). Bei quelloffenem Cookie legt die Anwendung fest, wie vorgegangen werden soll, wenn das Cookie abläuft. Bei HTTP-Headern hörtCA Single Sign-onauf, das abgelaufene Cookie zu senden.Geben Sie einen Zeitraum in Stunden, Minuten und Sekunden ein. Der Wert "00:00:00" gibt an, dass das Cookie nie abläuft.
Konfiguration der Zielanwendung (OAuth)
Im Abschnitt "Zielanwendung" können Sie die Zielanwendung angeben, und Sie könne angeben, wie Benutzer auf die Zielanwendung weitergeleitet werden.
- UmleitungsmodusGibt die Methode an, nach der die vertrauende Seite den Benutzer an die Zielressource umleitet. Folgende Werte stehen zur Verfügung:
- Keine DatenGibt an, dass der Benutzer an die Zielanwendung umgeleitet wird, indem eine HTTP-302-Umleitung mit einem Sitzungs-Cookie und ohne andere Daten durchgeführt wird.
- Cookie-DatenGibt an, dass der Benutzer an die Zielanwendung über eine HTTP-302-Umleitung mit einem Sitzungs-Cookie und mit zusätzlichen Cookie-Daten umgeleitet wird, die auf der behauptenden Seite konfiguriert werden. Wenn Sie diese Option auswählen, ist folgende Option verfügbar:
- Cookie-Daten des URL-VerschlüsselungsattributsLegt fest, dass das Attribut, das im Cookie gesendet wird, URL-verschlüsselt ist. Die URL-verschlüsselte Bezeichnung ist notwendig, weil die Zeichen in der URL einen eindeutigen Zweck erfüllen, anders als der Standard für eine URL. Diese Einstellung ist nur gültig, wenn "Cookie-Daten" als Umleitungsmodus festgelegt wird. Wenn die Cookie-Daten Ansprüche mit mehreren Werten enthalten, müssen Sie diese Option auswählen.Wenn Sie ein Sonderzeichen in der Attributtabelle der Anwendung angeben, wählen Sie diese Option aus. Wählen Sie zum Beispiel diese Einstellung für Attribute mit japanischen Zeichen aus. Sonderzeichen können aus der Drop-down-Liste hinzugefügt oder manuell eingegeben werden. Zusätzlich muss die Zielanwendung den Namen und den Wert des empfangenen Anwendungsattributs URL-dekodieren.
- Quelloffenes CookieGibt an, dass der Benutzer an die Zielanwendung umgeleitet wird, indem eine HTTP-302-Umleitung mit dem quelloffenen Cookie und ohne andere Daten durchgeführt wird. Die Kundenanwendung entschlüsselt das verschlüsselte Cookie, um die Benutzerinformationen abzurufen.Wenn die vertrauende Seite einen Anspruch mit mehreren Attributwerten empfängt, werden alle Werte an die Zielanwendung übergeben.
- Quelloffener Cookie-PostDer Benutzer wird an die Zielanwendung umgeleitet, indem eine HTTP-302-Umleitung mit dem quelloffenen Cookie durchgeführt wird. Allerdings werden die Daten in einer HTTP-POST-Anforderung gesendet. Wenn Sie besorgt sind, dass Daten aufgrund der Längenbegrenzung für Cookie-Daten verloren gehen können, wählen Sie diese Option aus.
- Name des quelloffenen CookiesGibt den Namen des quelloffenen Cookies ein.
- VerschlüsselungstransformationZeigt den Verschlüsselungsalgorithmus an, der verwendet werden soll, um das quelloffene Cookie zu verschlüsseln.Wenn Sie einen der FIPS-kompatiblen Algorithmen (AES-Algorithmen) auswählen, muss das Zielsystem einen System-SDK verwenden, um das Cookie zu verwenden. Das SDK muss sich auf dem gleichen Server wie die Zielanwendung befinden.Wenn Sie das .NET SDK verwenden, um das Cookie zu verbrauchen, dann verwenden Sie den Verschlüsselungsalgorithmus "AES128/CBC/PKCS5Padding".
- VerschlüsselungskennwortZeigt das Kennwort an, das verwendet wird, um das Cookie zu verschlüsseln.
- Kennwort bestätigenBestätigt den Eintrag für das Verschlüsselungskennwort.
- HMAC aktivierenLegt fest, dass ein HMAC (Hash Message Authentication Code) mithilfe des Verschlüsselungskennworts in diesem Dialogfeld generiert wird.MACs (Message authentication codes) können die Integrität der Informationen prüfen, die zwischen zwei Parteien gesendet werden. Die zwei Parteien nutzen gemeinsam einen geheimen Schlüssel für die Berechnung und Prüfung der Meldungsauthentifizierungswerte. Ein HMAC (Hash Message Authentication Code) ist ein MAC-Mechanismus, der auf kryptografischen Hash-Funktionen basiert. HMACs haben eine Meldungseingabe und einen geheimen Schlüssel, den nur der Absender und der zukünftige Empfänger der Meldung kennen.Wenn Sie das Kontrollkästchen "HMAC aktivieren" auswählen, generiert das System einen HMAC-Wert für das quelloffene Cookie. Der HMAC-Wert wird dann dem Wert des quelloffenen Cookies vorangestellt, und anschließend wird die gesamte Zeichenfolge verschlüsselt. Das System fügt die verschlüsselte Zeichenfolge in das quelloffene Cookie ein, das dann an die Zielanwendung übergeben wird.
- Angegebenes Cookie aktivierenGibt an, dass der Wert des quelloffenen Cookies in doppelte Anführungszeichen eingeschlossen wird. Diese Angabe ermöglicht die Verarbeitung des Cookies, wenn nicht unterstützte Zeichen in den Cookie-Wert eingeschlossen sind.
- Gültigkeitszeitraum des CookiesLegt die Zeitdauer fest, die das quelloffene Cookie gültig ist. Der Gültigkeitszeitraum wird im Cookie platziert, sodass die Zielanwendung prüfen kann, ob das Cookie gültig ist, bevor die Daten verbraucht werden. Die Anwendung bestimmt, was geschieht, wenn das Cookie abläuft.Geben Sie einen Zeitraum in Stunden, Minuten und Sekunden ein.
- HTTP-Header (nur Proxy-Modus)Der Benutzer wird an die Zielanwendung mit HTTP-Headern und ohne andere Daten umgeleitet.
- Dauerhafte Ansprüche an SitzungsspeicherDer Benutzer wird mit einer HTTP-302-Umleitung und einem Sitzungs-Cookie und ohne andere Daten umgeleitet. Dieser Modus weist den Richtlinienserver auch an, Attribute zu speichern, die aus einer Assertion im Sitzungsspeicher extrahiert wurden. Das System kann dann die Attribute als HTTP-Header-Variablen angeben.Hinweis:Sie können "PersistClaims" auswählen, und die Assertion, die Attribute enthalten, wird leer gelassen. In diesem Fall wird ein Wert von NULL in den Sitzungsspeicher geschrieben. Dieser Wert agiert als Platzhalter für das leere Attribut und wird mithilfe des Attributs an die Anwendung übergeben.
- ZielGibt die URL der Zielanwendung auf der vertrauenden Seite an. Der Wert, den Sie hier eingeben, wird die standardmäßige Zielressource. Die URL muss einen voll qualifizierten Domänennamen enthalten.Wenn ein Proxy sich vor dem Server mit der Zielressource befindet, geben Sie die URL für den Proxy-Host ein. Der Proxy verarbeitet alle Federation-Anforderungen lokal. Der Proxy-Host kann ein System sein, das sich vor dem Zielserver befindet. Der Proxy-Host kann auch das System selbst sein, sofern direkt über das Internet darauf zugegriffen wird. Wenn Sie mit einem Proxy arbeiten, muss die URL, die Sie als Ziel angeben, letztendlich durch das Federation-System gehen. Wenn die Basis-URL beispielsweise "fed.demo.com" ist und die Backend-Serverressource "mytarget/target.jsp" ist, dann ist der Wert für dieses Feld "http://fed.demo.com:5555/mytarget/target.jsp".Lassen Sie dieses Feld leer, wenn Sie es mit dem Abfrageparameter "RelayState" überschreiben. Der Abfrageparameter "RelayState" kann ein Teil der URL sein, die Single Sign-On auslöst. Um diese Übersteuerung zu aktivieren, wählen Sie das Kontrollkästchen "Relay-Status überschreibt Ziel" aus.
- Zeitlimit des LeerlaufsBestimmt die Zeit, während derer eine autorisierte Benutzersitzung inaktiv bleiben kann, bevor das Federation-System die Sitzung beendet. Wenn Sie besorgt sind, dass Benutzer nach dem Zugriff auf eine geschützte Ressource ihre Workstations verlassen lassen, dann legen Sie das Zeitlimit des Leerlaufs auf einen kurzen Zeitraum fest. Wenn die Sitzung das Zeitlimit überschreitet, müssen Benutzer erneut authentifiziert werden, bevor Sie wieder auf die Ressourcen zugreifen.Diese Einstellung ist standardmäßig aktiviert. Deaktivieren Sie das Kontrollkästchen, um kein Zeitlimit des Leerlaufs anzugeben. Das standardmäßige Zeitlimit des Leerlaufs ist eine Stunde.Hinweis:Aktivieren Sie bei dauerhaften Sitzungen das Zeitlimit des Leerlaufs, und legen Sie es auf einen Wert fest, der höher als der Validierungszeitraum ist.Standard:1 StundeStundenGibt die Stundenanzahl für das Zeitlimit des Leerlaufs an.MinutenGibt die Minutenanzahl für das Zeitlimit des Leerlaufs an.Maximales ZeitlimitBestimmt die Zeit, während derer eine Benutzersitzung maximal aktiv sein kann, bevor das Federation-System den Benutzer zur erneuten Authentifizierung auffordert.Diese Einstellung ist standardmäßig aktiviert. Deaktivieren Sie das Kontrollkästchen, um keine maximale Sitzungsdauer anzugeben.Standard: 2 Stunden
- StundenGibt die Stundenanzahl für die maximale Sitzungsdauer an.
- MinutenGibt die Minutenanzahl für die maximale Sitzungsdauer an.
- Relay-Status überschreibt Ziel(Optional) Ersetzt den Wert des Felds "Ziel" mit dem Wert für den Abfrageparameter "Relay-Status" in der Anforderung, die Single Sign-On initiiert. Wenn Sie dieses Kontrollkästchen auswählen, haben Sie eine größere Kontrolle über das Ziel, da Sie mithilfe des Abfrageparameters "Relay-Status" das Ziel dynamisch definieren können.
- Domäne der Ziel-URL validierenWeist das Federation-System an, den Wert des Felds "Ziel" oder das Ziel, das im Abfrageparameter "RelayState" angegeben ist, mit dem Parameter "ValidFedTargetDomain" im Agent-Konfigurationsobjekt zu vergleichen. Diese Einstellung stellt sicher, dass die vertrauende Seite den Zugriff auf die angeforderte Zieldomäne erlaubt.
Anwendungsattributen zuordnen (SAML, WSFED)
Der Abschnitt "An Anwendungsattribute zuordnen" bestimmt, wie Assertionsattribute zu Attributen zugeordnet werden, die die Zielanwendung verwendet.
- An Anwendungsattribute zuordnenLegt fest, dass die Attributzuordnung aktiviert ist. Wenn Sie Kontrollkästchen "Enable Application Attributes" (Anwendungsattribute aktivieren) auswählen, dann wird die Tabelle "Definitionen des Anwendungsattributs" angezeigt. Mit dieser Tabelle können Sie angeben, wie Anwendungsattribute zu Assertionsattributen zugeordnet werden.In den folgenden Spalten der Tabelle müssen Einträge vorgenommen werden:AnwendungsattributListet das Attribut auf, das die Zielanwendung verwendet. Der Anwendungsattributname und der Assertionsattributname sind standardmäßig identisch. Sie können den Anwendungsattributnamen in einen beliebigen Namen ändern, der für die Anwendung erforderlich ist.AssertionsattributeGibt die Attribute aus der Assertion an, die Sie als Grundlage für die Zuordnung eines Anwendungsattributs verwenden möchten.Wenn Sie die Schaltfläche "<<" auswählen, wird das Feld "Anfügen" angezeigt. In der Pull-down-Liste "Anfügen" können Sie verfügbare Assertionsattribute und spezielle Sonderzeichen auswählen, die in die Zuordnungsregel eingeschlossen werden sollen.
Zuordnung zu Anwendungsattributen (OAuth)
Der Abschnitt "An Anwendungsattribute zuordnen" bestimmt, wie Anspruchsattribute zu Attributen zugeordnet werden, die die Zielanwendung verwendet.
- An Anwendungsattribute zuordnenLegt fest, dass die Attributzuordnung aktiviert ist. Wenn Sie das Kontrollkästchen "Attributzuordnung aktivieren" aktivieren, wird die Definitionstabelle für Anwendungsattribute angezeigt. Mit dieser Tabelle können Sie angeben, wie Anwendungsattribute zu Assertionsattributen zugeordnet werden.In den folgenden Spalten der Tabelle müssen Einträge vorgenommen werden:AnwendungsattributListet das Attribut auf, das die Zielanwendung verwendet. Der Anwendungsattributname und der Assertionsattributname sind standardmäßig identisch. Sie können den Anwendungsattributnamen in einen beliebigen Namen ändern, der für die Anwendung erforderlich ist.AnspruchsattributeGibt die Attribute der Ansprüche an, die Sie als Grundlage für die Zuordnung eines Anwendungsattributs verwenden möchten.Wenn Sie die Schaltfläche "<<" auswählen, wird das Feld "Anfügen" angezeigt. In der Pull-down-Liste "Anfügen" können Sie spezielle Sonderzeichen auswählen, die in die Zuordnungsregel eingeschlossen werden sollen.
Benutzerbereitstellung (SAML, WSFED)
Im Abschnitt "Benutzerbereitstellung" können Sie festlegen, wie eine Bereitstellungsanwendung eines Drittanbieters Benutzerkonten erstellen soll.
- BenutzerbereitstellungIn diesem Abschnitt können Sie festlegen, wie die Benutzerbereitstellung ausgeführt wird.
- BereitstellungstypLegt fest, ob eine Remote-Bereitstellungsanwendung Benutzerkonten erstellt. Wenn der Richtlinienserver mit einer Bereitstellungsanwendung arbeitet, wählen Sie "Remote" aus.Standard:KeineOptionen: Keine, RemoteHinweisSie können "Remote" als Bereitstellungstyp auswählen. Konfigurieren Sie in diesem Fall eine Übermittlungsoption, die die Assertionsdaten an die Bereitstellungsanwendung übergibt.
- Übermittlungsoption(Nur Remote-Bereitstellung) Definiert, wie der Browser mit den Assertionsdaten zur Bereitstellungsanwendung weitergeleitet wird. Assertionsdaten können in einem Cookie oder HTTP-Header weitergegeben werden.Optionen:
- Quelloffenes CookieÜbermittelt SAML-Assertionsinformationen in einem quelloffenen Cookie. Wenn ein quelloffenes Cookie verwendet wird, kann die Bereitstellungsanwendung das Cookie lesen, ohne ein SDK zu verwenden. Wenn die Bereitstellungsanwendung ".NET" verwendet, dann kann ".NET SDK" auf dem Bereitstellungsserver installiert und anschließend verwendet werden, um das quelloffene Cookie zu lesen.
- Quelloffener Cookie-PostGibt die Assertionsinformationen in einem quelloffenen Cookie an. Allerdings werden die Daten in einer HTTP-POST-Anforderung gesendet. Wenn Sie besorgt sind, dass Daten aufgrund der Längenbegrenzung für Cookie-Daten verloren gehen können, wählen Sie diese Option aus.
- HTTP-HeaderDer Richtlinienserver übermittelt Assertionsdaten in HTTP-Headern.
- URL des BereitstellungsserversIdentifiziert die URL des Servers des Drittanbieters, der die Bereitstellungsanwendung hostet.Wert:Eine gültige URL
Wenn Sie die Option "Quelloffenes Cookie" auswählen, füllen Sie folgende zusätzliche Felder aus:
Name des quelloffenen Cookies
Gibt den Namen des quelloffenen Cookies ein.
- VerschlüsselungstransformationZeigt den Verschlüsselungsalgorithmus an, der das quelloffene Cookie verschlüsselt.
- VerschlüsselungskennwortZeigt das Kennwort an, das verwendet wird, um das Cookie zu verschlüsseln. Die Felder "Verschlüsselungskennwort" und "Kennwort bestätigen" sind für das quelloffene Cookie erforderlich. Allerdings sind die Parameter für das Legacy-Cookie optional.Wichtig! Wenn Sie ein Kennwort für das Legacy-Cookie angeben, definieren Sie den gleichen Wert für dasCA SiteMinder® Federation-Java-SDK. Das SDK benötigt das Kennwort, um das Cookie zu entschlüsseln. Die Werte werden in einer Out-Of-Band-Kommunikation freigegeben.
- Kennwort bestätigenBestätigt den Eintrag für das Verschlüsselungskennwort.
- HMAC aktivierenZeigt an, dass das System einen HMAC (Hash Message Authentication Code) mithilfe des Verschlüsselungskennworts generiert, das in diesem Dialogfeld angegeben ist.MACs (Message authentication codes) können die Integrität der Informationen prüfen, die zwischen zwei Parteien gesendet werden. Die zwei Parteien nutzen gemeinsam einen geheimen Schlüssel für die Berechnung und Prüfung der Meldungsauthentifizierungswerte. Ein HMAC (Hash Message Authentication Code) ist ein MAC-Mechanismus, der auf kryptografischen Hash-Funktionen basiert. HMACs haben eine Meldungseingabe und einen geheimen Schlüssel, den nur der Absender und der zukünftige Empfänger der Meldung kennen.Wenn Sie das Kontrollkästchen "HMAC aktivieren" auswählen, generiert das System einen HMAC-Wert für das quelloffene Cookie. Der HMAC-Wert wird dann dem Wert des quelloffenen Cookies vorangestellt, und anschließend wird die gesamte Zeichenfolge verschlüsselt.CA Single Sign-onfügt die verschlüsselte Zeichenfolge in das quelloffene Cookie ein, das dann an die Zielanwendung übergeben wird.
- Angegebenes Cookie aktivierenGibt an, dass der Wert des quelloffenen Cookies in doppelte Anführungszeichen eingeschlossen wird. Diese Angabe ermöglicht die Verarbeitung des Cookies, wenn nicht unterstützte Zeichen in den Cookie-Wert eingeschlossen sind.
Gültigkeitszeitraum des Cookies
Legt die Zeitdauer fest, die das quelloffene Cookie gültig ist. Der Gültigkeitszeitraum wird im Cookie platziert, sodass die Zielanwendung prüfen kann, ob das Cookie gültig ist, bevor die Daten verbraucht werden. Sie können diesen Wert für das quelloffene Cookie und für Umleitungsmodi der HTTP-Header festlegen (HTTP-Header verwenden das quelloffene Cookie). Bei quelloffenem Cookie legt die Anwendung fest, wie vorgegangen werden soll, wenn das Cookie abläuft. Bei HTTP-Headern hört der Agent auf, das abgelaufene Cookie zu senden.
Geben Sie einen Zeitraum in Stunden, Minuten und Sekunden ein.
Benutzerbereitstellung (OAuth)
Im Abschnitt "Benutzerbereitstellung" können Sie festlegen, wie eine Bereitstellungsanwendung eines Drittanbieters Benutzerkonten erstellen soll.
- BereitstellungstypLegt fest, ob eine Remote-Bereitstellungsanwendung Benutzerkonten erstellt.
- ÜbermittlungsoptionGibt an, wie ein Browser mit den Benutzerdaten an die Bereitstellungsanwendung weitergeleitet wird. Das Federation-System kann die Benutzerdaten mithilfe von einem Cookie oder von HTTP-Headern übergeben. Folgende Optionen stehen zur Verfügung:
- Quelloffenes CookieÜbermittelt OAuth-Benutzerinformationen in einem quelloffenen Cookie. Wenn ein quelloffenes Cookie verwendet wird, kann die Bereitstellungsanwendung das Cookie lesen, ohne ein SDK zu verwenden. Wenn die Bereitstellungsanwendung ".NET" verwendet, installieren Sie den .NET SDK auf dem Bereitstellungsserver. Er wird verwendet, um das quelloffene Cookie zu lesen.
- Quelloffener Cookie-PostGibt die OAuth-Benutzerinformationen in einem quelloffenen Cookie an. Allerdings werden die Daten in einer HTTP-POST-Anforderung gesendet. Wenn Sie besorgt sind, dass Daten aufgrund der Längenbegrenzung für Cookie-Daten verloren gehen können, wählen Sie diese Option aus.
- Name des quelloffenen CookiesGibt den Namen des quelloffenen Cookies ein.
- VerschlüsselungstransformationZeigt den Verschlüsselungsalgorithmus an, der verwendet werden soll, um das quelloffene Cookie zu verschlüsseln.
- "Verschlüsselungskennwort" und "Kennwort bestätigen"Zeigt das Kennwort an, das verwendet wird, um das Cookie zu verschlüsseln. Die Felder "Verschlüsselungskennwort" und der "Kennwort bestätigen" sind für das quelloffene Cookie erforderlich.
- HMAC aktivierenLegt fest, dass ein HMAC (Hash Message Authentication Code) mithilfe des Verschlüsselungskennworts in diesem Dialogfeld generiert wird.MACs (Message authentication codes) können die Integrität der Informationen prüfen, die zwischen zwei Parteien gesendet werden. Die zwei Parteien nutzen gemeinsam einen geheimen Schlüssel für die Berechnung und Prüfung der Meldungsauthentifizierungswerte. Ein HMAC (Hash Message Authentication Code) ist ein MAC-Mechanismus, der auf kryptografischen Hash-Funktionen basiert. HMACs haben eine Meldungseingabe und einen geheimen Schlüssel, den nur der Absender und der zukünftige Empfänger der Meldung kennen.Wenn Sie das Kontrollkästchen "HMAC aktivieren" auswählen, generiert das System einen HMAC-Wert für das quelloffene Cookie. Der HMAC-Wert wird dann dem Wert des quelloffenen Cookies vorangestellt, und anschließend wird die gesamte Zeichenfolge verschlüsselt. Das Federation-System fügt die verschlüsselte Zeichenfolge in das quelloffene Cookie ein, das dann an die Zielanwendung übergeben wird.
- Angegebenes Cookie aktivierenGibt an, dass der Wert des quelloffenen Cookies in doppelte Anführungszeichen eingeschlossen wird. Diese Angabe ermöglicht die Verarbeitung des Cookies, wenn nicht unterstützte Zeichen in den Cookie-Wert eingeschlossen sind.
HTTP-Header (nur Proxy-Modus)
- Wenn das System im Proxy-Modus eingesetzt wird, übermittelt es Assertionsdaten in HTTP-Headern.
- URL des BereitstellungsserversIdentifiziert die URL des Servers des Drittanbieters, der die Bereitstellungsanwendung hostet.
- Gültigkeitszeitraum des CookiesLegt die Zeitdauer fest, die das quelloffene Cookie gültig ist. Der Gültigkeitszeitraum wird im Cookie platziert, sodass die Zielanwendung prüfen kann, ob das Cookie gültig ist, bevor die Daten verbraucht werden. Sie können diesen Wert für das quelloffene Cookie und für Umleitungsmodi für HTTP-Header festlegen. HTTP-Header verwenden das quelloffene Cookie. Bei quelloffenem Cookie legt die Anwendung fest, wie vorgegangen werden soll, wenn das Cookie abläuft. Bei HTTP-Headern hört das System auf, das abgelaufene Cookie zu senden.
URLs der Status-Umleitung (SAML, WSFED)
Im Abschnitt "URL der Status-Umleitung" können Sie festlegen, wie
CA Single Sign-on
einen Benutzer umleitet, wenn die Authentifizierung fehlschlägt.Assertionsbasierte Authentifizierung kann auf der Site fehlschlagen, die Assertionen verbraucht. Wenn die Authentifizierung fehlschlägt, stellt das Federation-System Funktionen bereit, um den Benutzer zur weiteren Verarbeitung an andere Anwendungen (URLs) zu leiten. Wenn beispielsweise die Begriffsklärung des Benutzers fehlschlägt, können Sie
CA Single Sign-on
so konfigurieren, dass der Benutzer an ein Bereitstellungssystem gesendet wird. Das Bereitstellungssystem kann ein Benutzerkonto erstellen, das auf Informationen basiert, die sich in der SAML-Assertion befinden.Sie können eine oder mehrere dieser Optionen konfigurieren. Wenn die Bedingung eintritt, die den Fehler verursacht hat, leitet
CA Single Sign-on
den Benutzer auf die konfigurierte URL um.Hinweis:
Fehlerumleitung geschieht nur, wenn das System die Anforderung erfolgreich analysieren kann und die Informationen erhält, die notwendig sind, um die gültigen und vertrauenden Partner zu identifizieren.Die Einstellungen sind:
- Benutzer nicht gefundenIdentifiziert die URL, an die das System den Benutzer unter einer der folgenden Bedingungen umleitet:
- Die Single Sign-On-Meldung verpasst eine Anmelde-ID
- Das Benutzerverzeichnis enthält nicht die Anmelde-ID mit der definierten Suchzeichenfolge.
- Ungültige SSO-MeldungIdentifiziert die URL, an dieCA Single Sign-onden Benutzer unter einer der folgenden Bedingungen umleitet:
- Die Single Sign-On-Meldung ist basierend auf Regeln in den SAML-Schemen ungültig.
- Der Consumer benötigt eine verschlüsselte Assertion, aber die Single Sign-On-Meldung enthält keine verschlüsselte Assertion.
- Nicht akzeptierte Benutzeranmeldeinformationen (SSO-Meldung)Identifiziert die URL, an dieCA Single Sign-onden Benutzer bei den meisten Fehlerbedingungen umleitet. Die Fehlerbedingungen, die Ausnahmen sind, sind, wenn ein Benutzer nicht gefunden wird oder wenn die Single Sign-On-Meldung ungültig ist. Die Assertion kann gültig sein, jedoch akzeptiertCA Single Sign-ondie Meldung aus verschiedenen Gründen nicht, wie z. B.:
- Fehler bei der Validierung der digitalen XML-Signatur
- (SAML 2.0) Fehler beim XML-Entschlüsselungsvorgang
- Die XML-Validierung von Bedingungen schlägt fehl, wie z. B. eine abgelaufene Meldung oder eine nicht übereinstimmende Zielgruppe.
- Keine der Assertionen in der SSO-Meldung enthält eine Authentifizierungsanweisung.
- 302 - Keine Daten (Standard)Leitet den Benutzer über eine HTTP-302-Umleitung mit einem Sitzungs-Cookie und ohne andere Daten um.
- HTTP POSTLeitet den Benutzer mithilfe eines "HTTP POST"-Protokolls um.
Zusätzliche Weiterleitungs-URLS (SAML 2.0)
Bei einem SAML 2.0-Service Provider können Sie auch Umleitungs-URLs für HTTP 500-, HTTP 400- und HTTP 405-Fehler angeben. Wählen Sie die Umleitungsoptionen aus, die Sie aktivieren möchten, und geben Sie anschließend eine zugeordnete URL ein. Die Optionen sind:
- Umleitung des Serverfehlers aktivierenServerfehler-URL:Gibt die URL an, an die der Benutzer umgeleitet wird, wenn ein HTTP 500-Serverfehler auftritt. Bei einem Benutzer kann ein 500-Fehler auftreten, da eine unerwartete Bedingung verhindert, dass der Webserver die Client-Anforderung erfüllt. Wenn dieser Fehlertyp auftritt, wird der Benutzer zur weiteren Verarbeitung an die angegebene URL gesendet.Beispiel: http://www.redirectmachine.com/error_pages/server_error.html
- Umleitung der ungültigen Anforderung aktivierenUngültige Anforderungs-URL:Gibt die URL an, an die der Benutzer umgeleitet wird, wenn ein "HTTP 400 Bad Request"- oder "405 Method Not Allowed"-Fehler auftritt. Bei einem Benutzer kann ein 400-Fehler auftreten, wenn eine Anforderung fehlerhaft ist. Bei einem Benutzer kann auch ein 405-Fehler auftreten, weil der Webserver nicht zulässt, dass eine bestimmte Methode oder Aktion ausgeführt wird. Wenn diese Fehlertypen auftreten, wird der Benutzer zur weiteren Verarbeitung an die angegebene URL gesendet.Beispiel: http://www.redirectmachine.com/error_pages/invalidreq_error.html
- Umleitung des nicht autorisierten Zugriffs aktivierenURL des nicht autorisierten Zugriffs:Gibt die URL an, an die der Benutzer umgeleitet wird, wenn ein "HTTP 403 Forbidden"-Fehler auftritt. Ein 403-Fehler kann auftreten, weil die URL in einer Anforderung auf das falsche Ziel verweist, wie z. B. auf ein Verzeichnis statt auf eine Datei. Wenn dieser Fehler auftritt, wird der Benutzer zur weiteren Verarbeitung an die angegebene URL gesendet.Beispiel: http://www.redirectmachine.com/error_pages/unauthorized_error.html
URLs der Status-Umleitung (OAuth)
Im Abschnitt "URL der Status-Umleitung" können Sie festlegen, wie
CA Single Sign-on
einen Benutzer umleitet, wenn die Authentifizierung fehlschlägt.Assertionsbasierte Authentifizierung kann auf der Site fehlschlagen, die Assertionen verbraucht. Wenn die Authentifizierung fehlschlägt, stellt "Federation Standalone" Funktionen bereit, um den Benutzer zur weiteren Verarbeitung an verschiedene Anwendungen (URLs) zu leiten. Wenn beispielsweise die Begriffsklärung des Benutzers fehlschlägt, können Sie
CA Single Sign-on
so konfigurieren, dass der Benutzer an ein Bereitstellungssystem gesendet wird. Das Bereitstellungssystem kann ein Benutzerkonto erstellen, das auf Informationen basiert, die sich in der SAML-Assertion befinden.Sie können eine oder mehrere dieser Optionen konfigurieren. Wenn die Bedingung eintritt, die den Fehler verursacht hat, leitet
CA Single Sign-on
den Benutzer auf die konfigurierte URL um.Die Einstellungen sind:
- Remoteserverfehler
- OAuth 2.0Identifiziert die URL, an die das System den Benutzer bei folgenden OAuth 2.0- Fehlern verweist:
- Der Autorisierungserver hat eine unerwartete Bedingung festgestellt, die ihn davon abhält, die Benutzeraufforderung zu erfüllen.
- Der Autorisierungserver kann die Benutzeraufforderung aufgrund einer temporären Überladung oder Wartung des Servers nicht bearbeiten.
- OAuth 1.0aIdentifiziert die URL, an die das System den Benutzer verweist, wenn der Autorisierungserver einen HTTP 500-Fehler sendet.
- Ungültige Anfragemeldung
- OAuth 2.0Identifiziert die URL, an die das System den Benutzer bei folgenden OAuth 2.0- Fehlern verweist:
- Die Benutzeraufforderung verwendet eine falsche Syntax.
- Der vom Benutzer angeforderte Bereich ist ungültig, unbekannt oder fehlerhaft.
- Der Autorisierungserver unterstützt nicht das Abrufen eines Autorisierungscodes mit der angegebenen Methode.
- OAuth 1.0aIdentifiziert die URL, an die das System den Benutzer verweist, wenn der Autorisierungserver einen HTTP 400- oder 404-Fehler sendet.
- Nicht akzeptierte Anmeldeinformationen
- OAuth 2.0Identifiziert die URL, an die CACA Single Sign-onFederation Standalone den Benutzer bei folgenden OAuth 2.0- Fehlern verweist:
- Der Client ist nicht dazu autorisiert, einen Autorisierungscode unter Verwendung der angegebenen Methode anzufordern.
- Der Autorisierungserver hat die Anforderung abgelehnt.
- OAuth 1.0aIdentifiziert die URL, an die das System den Benutzer verweist, wenn der Autorisierungserver einen HTTP 401- oder 403-Fehler sendet.
- 302 - Keine Daten (Standard)Leitet den Benutzer über eine HTTP-302-Umleitung mit einem Sitzungs-Cookie und ohne andere Daten um.
- HTTP POSTLeitet den Benutzer mithilfe eines "HTTP POST"-Protokolls um.