Anwendungsintegration (Vertrauende Seite)

casso127figsbrde
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.
  • Umleitungsmodus
    Gibt die Methode an, nach der die vertrauende Seite den Benutzer an die Zielressource umleitet.
    Standard:
    Keine Daten
    Die 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-Daten
      Der 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üsselungsattributs
      Legt 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 Cookie
      Der 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-Post
      Der 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 Cookies
        Gibt den Namen des quelloffenen Cookies ein.
      • Verschlüsselungstransformation
        Zeigt den Verschlüsselungsalgorithmus an, der das quelloffene Cookie verschlüsselt.
        Wenn Sie einen der FIPS-kompatiblen Algorithmen (AES-Algorithmen) auswählen, muss das Zielsystem einen
        CA 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üsselungskennwort
        Zeigt 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 den
        CA 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ätigen
        Bestätigt den Eintrag für das Verschlüsselungskennwort.
      • HMAC aktivieren
        Legt 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 aktivieren
        Gibt 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 Attribute
      Der 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-on
      kann 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.
    • casso127figsbrde
      Server-Umleitung
      Weist 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, muss
        relativ
        zum 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.html
        sein.
      • 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.
  • Ziel
    Gibt 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,
    relativ
    zum 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.html
    sein.
    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
    Single Sign-On
    selbst sein, sofern Sie direkt über das Internet darauf zugreifen. Wenn Sie mit einem Proxy arbeiten, muss die URL, die Sie als Ziel angeben, letztendlich durch
    Single Sign-On
    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".
    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 Leerlaufs
    Bestimmt 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\MaintenancePeriod
    Zum 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 Sekunden
    Stunden
    Gibt die Stundenanzahl für das Zeitlimit des Leerlaufs an.
    Minuten
    Gibt die Minutenanzahl für das Zeitlimit des Leerlaufs an.
    Maximales Zeitlimit
    Bestimmt 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.
    • Stunden
      Gibt die Stundenanzahl für die maximale Sitzungsdauer an.
    • Minuten
      Gibt 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 beibehalten
    Ermö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 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
    CA Single Sign-on
    auf, 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.
  • Umleitungsmodus
    Gibt die Methode an, nach der die vertrauende Seite den Benutzer an die Zielressource umleitet. Folgende Werte stehen zur Verfügung:
    • Keine Daten
      Gibt 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-Daten
      Gibt 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üsselungsattributs
        Legt 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 Cookie
      Gibt 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-Post
      Der 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" auswählen, zeigt die Benutzeroberfläche die folgenden zusätzlichen Felder an:
  • Name des quelloffenen Cookies
    Gibt den Namen des quelloffenen Cookies ein.
  • Verschlüsselungstransformation
    Zeigt 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üsselungskennwort
    Zeigt das Kennwort an, das verwendet wird, um das Cookie zu verschlüsseln.
  • Kennwort bestätigen
    Bestätigt den Eintrag für das Verschlüsselungskennwort.
  • HMAC aktivieren
    Legt 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 aktivieren
    Gibt 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. 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 Sitzungsspeicher
    Der 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.
  • Ziel
    Gibt 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 Leerlaufs
    Bestimmt 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 Stunde
    Stunden
    Gibt die Stundenanzahl für das Zeitlimit des Leerlaufs an.
    Minuten
    Gibt die Minutenanzahl für das Zeitlimit des Leerlaufs an.
    Maximales Zeitlimit
    Bestimmt 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
    • Stunden
      Gibt die Stundenanzahl für die maximale Sitzungsdauer an.
    • Minuten
      Gibt 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 validieren
    Weist 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 zuordnen
    Legt 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:
    Anwendungsattribut
    Listet 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.
    Assertionsattribute
    Gibt 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 zuordnen
    Legt 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:
    Anwendungsattribut
    Listet 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.
    Anspruchsattribute
    Gibt 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.
  • Benutzerbereitstellung
    In diesem Abschnitt können Sie festlegen, wie die Benutzerbereitstellung ausgeführt wird.
  • Bereitstellungstyp
    Legt fest, ob eine Remote-Bereitstellungsanwendung Benutzerkonten erstellt. Wenn der Richtlinienserver mit einer Bereitstellungsanwendung arbeitet, wählen Sie "Remote" aus.
    Standard:
    Keine
    Optionen
    : Keine, Remote
    Hinweis
    Sie 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-Post
      Gibt 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-Header
      Der Richtlinienserver übermittelt Assertionsdaten in HTTP-Headern.
  • URL des Bereitstellungsservers
    Identifiziert 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üsselungstransformation
    Zeigt den Verschlüsselungsalgorithmus an, der das quelloffene Cookie verschlüsselt.
  • Verschlüsselungskennwort
    Zeigt 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 das
    CA 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ätigen
    Bestätigt den Eintrag für das Verschlüsselungskennwort.
  • HMAC aktivieren
    Zeigt 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-on
    fügt die verschlüsselte Zeichenfolge in das quelloffene Cookie ein, das dann an die Zielanwendung übergeben wird.
  • Angegebenes Cookie aktivieren
    Gibt 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.
    • Bereitstellungstyp
      Legt fest, ob eine Remote-Bereitstellungsanwendung Benutzerkonten erstellt.
    • Übermittlungsoption
      Gibt 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-Post
        Gibt 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.
      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üsselungstransformation
      Zeigt 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 aktivieren
      Legt 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 aktivieren
      Gibt 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 Bereitstellungsservers
    Identifiziert die URL des Servers des Drittanbieters, der die Bereitstellungsanwendung hostet.
  • 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 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 gefunden
    Identifiziert 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-Meldung
    Identifiziert die URL, an die
    CA Single Sign-on
    den 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 die
    CA Single Sign-on
    den 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 akzeptiert
    CA Single Sign-on
    die 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 POST
    Leitet 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 aktivieren
    Serverfehler-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 aktivieren
    Ungü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 aktivieren
    URL 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.0
      Identifiziert 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.0a
      Identifiziert die URL, an die das System den Benutzer verweist, wenn der Autorisierungserver einen HTTP 500-Fehler sendet.
  • Ungültige Anfragemeldung
    • OAuth 2.0
      Identifiziert 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.0a
      Identifiziert die URL, an die das System den Benutzer verweist, wenn der Autorisierungserver einen HTTP 400- oder 404-Fehler sendet.
  • Nicht akzeptierte Anmeldeinformationen
    • OAuth 2.0
      Identifiziert die URL, an die CA
      CA Single Sign-on
      Federation 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.0a
      Identifiziert 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 POST
    Leitet den Benutzer mithilfe eines "HTTP POST"-Protokolls um.