Konfiguration von Proxy-Regeln

Inhalt
casso128figsbrde
HID_proxy-rules
Inhalt
3
CA Access Gateway
verwendet die serverinterne Proxy-Engine, um Anforderungen an geeignete Server im Unternehmen zu leiten. Die Proxy-Engine interpretiert Proxy-Regeln und bietet sowohl einen Weiterleitungs- als auch einen Umleitungsdienst, um die Anordnung aller Benutzeranforderungen für Back-End-Ressourcen zu verarbeiten.
Proxy-Regeln definieren, auf welche Weise die Anforderungen an Ressourcen auf den Zielservern weitergeleitet oder umgeleitet werden. Ein Satz von Proxy-Regeln wird entsprechend der standardmäßig installierten DTD der Proxy-Regeln definiert und in einer Konfigurationsdatei namens "proxyrules.xml" gespeichert. Standardmäßig wird während der Installation der folgende relative Pfad zur Datei "proxyrules.xml" generiert und im Parameter "rules_file" des Abschnitts <ServiceDispatcher> der Datei "server.conf" verwendet:
sps_home
/secure-proxy/proxy-engine/conf/proxyrules.xml
Alle Einträge in der Datei "proxyrules.xml" müssen korrekt formatiert sein und die Syntaxregeln der XML-Spezifikationen erfüllen. Änderungen an der Datei "proxyrules.xml" werden automatisch erkannt.
CA Access Gateway
unterstützt das Abwickeln von Anforderungen, die an die Multibyte-Zeichensatz-URL (MBCS) des Back-End-Servers, der die Anforderung abwickelt, gesendet werden.
Wenn beim Analysieren der Regeln ein Fehler in den Proxy-Regeln erkannt wird, schreibt
CA Access Gateway
den Fehler in das in der Datei "logger.properties" konfigurierte Protokoll, ignoriert die Änderungen und verwendet die vorhandenen Proxy-Regeln.
Die Datei "proxyrules.xml" enthält eine Standardregel, die Anforderungen an http://www.ca.com$0 weiterleitet. Durch "$0" wird der vollständige URI der ursprünglichen Anforderung (in diesem Fall www.ca.com) an das Ziel angehängt. Sie müssen diese Regel ändern, um sie an Ihre Umgebung anzupassen.
Planung von Umleitungen und Weiterleitungen für eingehende Anforderungen
Bevor Sie die Datei "proxyrules.xml" konfigurieren, ordnen Sie Um- und Weiterleitungen für eingehende Anforderungen zu. Abhängig vom virtuellen Host, der die angeforderte Ressource enthält, kann die Proxy-Regel ein Standardziel verwenden, eine Anforderung basierend auf dem Typ des Benutzeragenten weiterleiten oder den Zielserver, der die Anforderung verarbeiten wird, anhand des Werts eines HTTP-Header ermitteln.  
CA Access Gateway
bietet Zugriff auf verschiedene virtuelle Hosts.
Folgende Abbildung veranschaulicht, wie Proxy-Regeln verwendet werden können, um Anforderungen an den geeigneten Zielserver zu leiten:
Designing Proxy Rules
 
Die Datei "proxyrules.xml" wird von oben nach unten verarbeitet. Die erste Bedingung, die von einer eingehenden Anforderung erfüllt wird, bestimmt das Verhalten der Proxy-Engine. Wenn eine Proxy-Regel beispielsweise zwei Bedingungen enthält, die auf einer Zeichenfolge basieren, die im URI der Anforderung enthalten ist, und ein Teil des URI einer eingehenden Anforderung mit beiden Zeichenfolgen übereinstimmt, wird die erste in der Datei "proxyrules.xml" aufgeführte Bedingung zum Weiterleiten der Anforderung herangezogen.
Proxy-Regeln können auch verwendet werden, um komplexere Bedingungen für das Umleiten und Weiterleiten von Anforderungen an Zielserver zu steuern.
Die folgende Abbildung veranschaulicht, wie Proxy-Regeln mit einer zusätzlichen Bedingungsebene verwendet werden können, die innerhalb von übergeordneten Bedingungen geschachtelt sind:
Designing Proxy Rules with Nested Conditions
 
Terminologie im Zusammenhang mit Proxy-Regel
Folgende Begriffe werden bei der Beschreibung von Proxy-Regeln verwendet:
  • Ziele
    Definiert eine Ziel-URL, die eine Anforderung erfüllt.  
    CA Access Gateway
    leitet eine Anforderung an ein Ziel oder sendet eine Umleitungsantwort an einen Benutzer, der ein Ziel angibt. Ein Satz von Proxy-Regeln muss Ziele enthalten, die anhand der in den Proxy-Regeln definierten Bedingungen und Fällen erreicht werden können.
  • Bedingungen
    Definiert ein Bedingungsattribut, das das Ziel der Anforderung bestimmt. Bedingungen können verschiedene Fälle enthalten, die ausgewertet werden müssen, damit die Anforderung an ein geeignetes Ziel geleitet wird. Jede Bedingung muss ein Standardelement enthalten, das definiert, welches Verhalten eintritt, wenn eine Anforderung keinem der in der Bedingung definierten Fälle entspricht.
    Bedingungen können folgende Optionen enthalten:
    • URI
      Gibt an, dass der Teil der angeforderten URL hinter dem Hostnamen herangezogen werden muss, um zu bestimmen, auf welche Weise eine Anforderung um- oder weitergeleitet wird. Entsprechend der in der DTD beschriebenen Kriterien wird ein Teil eines URI, z. B. die Dateierweiterung der angeforderten Ressource, zum Weiterleiten oder Umleiten von Anforderungen verwendet.
    • Abfragezeichenfolge
      Gibt an, dass der Abfrageteil einer URI-Zeichenfolge verwendet werden muss, um zu bestimmen, auf welche Weise eine Anforderung um- oder weitergeleitet wird. Die Abfragezeichenfolge enthält sämtliche Zeichen, die in der Anforderung auf "?" folgen.
    • Host
      Gibt an, dass der angeforderte Serverhostname verwendet werden muss, um zu bestimmen, auf welche Weise eine Anforderung um- oder weitergeleitet wird. Auch die Portnummer des Hostnamens kann als Kriterium für das Umleiten oder Weiterleiten von Anforderungen verwendet werden. Diese Bedingung wird verwendet, wenn der Proxy über mehr als einen virtuellen Server verfügt.
    • Header
      Gibt an, dass der Wert eines HTTP-Header verwendet werden muss, um zu bestimmen, auf welche Weise eine Anforderung um- oder weitergeleitet wird. Unter Heranziehung des HTTP-Header USER_AGENT können Anforderungen basierend auf dem Gerätetyp, anhand dessen auf Ressourcen zugegriffen wird, umgeleitet oder weitergeleitet werden.
      Aus
      CA Single Sign-on
      -Antworten abgeleitete HTTP-Header können herangezogen werden, um zu bestimmen, auf welche Weise eine Anforderung um- oder weitergeleitet wird.
    • Cookie
      Gibt an, dass das Vorhandensein oder der Wert eines Cookie verwendet werden muss, um zu bestimmen, auf welche Weise eine Anforderung um- oder weitergeleitet wird. Wenn ein Cookie-Wert codiert ist, geben Sie das Codierungsschema im Parameter "encoding" ein. Es wird ausschließlich das base64-Codierungsschema unterstützt.
  • Fälle
    Definiert einen Satz von Werten für Bedingungen, die Informationen zum Bestimmen des Ziels einer Anforderung enthalten. Wenn ein Satz von Proxy-Regeln beispielsweise die Host-Bedingung verwendet, umfassen die Fälle die für das System konfigurierten virtuellen Hosts, beispielsweise home.company.com und banking.company.com.
DTD für Proxy-Regeln
Verwenden Sie die DTD für Proxy-Regeln, um die Proxy-Regeln zu konfigurieren. Die DTD-Datei ist an folgendem Speicherort verfügbar:
sps_home
\secure-proxy\proxy-engine\conf\dtd
Folgende Elemente können in DTD konfiguriert werden:
  • nete:proxyrules
  • nete:description
  • nete:case
  • nete:cond
  • nete:default
  • nete:forward
  • nete:redirect
  • nete:local
  • nete:xprcond
nete proxyrules
"nete:proxyrules" ist das obligatorische Stammelement in "proxyrules.xml" und verwendet folgende Syntax:
<!ELEMENT nete:proxyrules (nete:description?,(nete:cond | nete:forward | nete:redirect | nete:local)) >
Sie können optional ein nete:description-Element und eines der folgenden Elemente definieren:
  • nete:cond
  • nete:xprcond
  • nete:forward
  • nete:redirect
  • nete:local
Attribut "debug"
Mit dem debug-Attribut können Sie die Protokollierung verwalten und Proxy-Regeln debuggen. Es verwendet folgende Syntax:
<ATTLIST nete:proxyrules debug (yes|no) "no"
Setzen Sie den Wert auf "yes", um die Protokollierung zu aktivieren. Der Speicherort der Protokolldatei wird durch den Parameter "TraceFileName" im Agent-Konfigurationsobjekt bestimmt, das Sie für
CA Access Gateway
konfiguriert haben. Der Parameter "TraceConfigFile" in diesem Agent-Konfigurationsobjekt muss auf die Konfigurationsdatei der spezifischen Nachverfolgungs-Protokollierung für den sicheren Proxy verweisen. Die Datei befindet sich standardmäßig unter <Installationsverzeichnis>\proxy-engine\conf\defaultagent\SecureProxyTrace.conf.
Beispiel: <nete:proxyrules xmlns:nete="http://www.ca.com/" debug="yes">
nete description
Das Element "nete:description" ist ein optionales Feld, das eine Beschreibung der analysierten Zeichendaten (PCDATA) eines anderen Elements enthält.
PCDATA ist ein beliebiger Text, bei dem es sich nicht um Markup-Text handelt.
Es verwendet folgende Syntax:
<!ELEMENT nete:description (#PCDATA)>
Es kann ein untergeordnetes Element von "nete:proxyrules" sein und eine beliebige Beschreibung enthalten.
nete case
Das Element "nete:case" definiert das Ziel, das einem bestimmten Wert für eine im übergeordneten Element "nete:cond" definierten Bedingung zugeordnet ist.  
CA Access Gateway
verwendet den Wert des Elements "nete:case", um eine Anforderung auszuwerten.
Es verwendet folgende Syntax:
<!ELEMENT nete:case (nete:cond | nete:xprcond | nete:forward | nete:redirect | nete:local)>
Alle Elemente des Typs "nete:case" müssen eines der folgenden untergeordneten Elemente enthalten:
  • nete:cond
    Ermöglicht es Ihnen, in einem Satz von Proxy-Regeln mehrere Bedingungen zu verschachteln.
  • nete:xprcond
    Ermöglicht es Ihnen, eine Bedingung in Form eines regulären Ausdrucks in einem Satz anderer Bedingungen zu verschachteln.
  • nete:forward
    Enthält ein Ziel, an das Anforderungen, die dem Vergleich mit "nete:case" entsprechen, weitergeleitet werden.
  • nete:redirect
    Enthält ein Ziel, an das Anforderungen, die dem Vergleich mit "nete:case" entsprechen, umgeleitet werden. Nach der Umleitung werden Anforderungen direkt vom Zielserver und nicht über
    CA Access Gateway
    abgewickelt.
Im folgenden Beispiel legt "nete:cond" URI-Übereinstimmung fest, und die nete:case-Elemente zeigen mögliche Verwendungen des Vergleichstypsattributs.
 
<nete:cond type="uri" criteria="beginswith">
<nete:case value="/hr">
<nete:forward>http://hr.company.com$0</nete:forward> </nete:case> <nete:case value="/employee"> <nete:forward>http://employees.company.com$1 </nete:forward>
</nete:case> </nete:cond>
Die <nete:forward>URL</nete:forward>-Elemente müssen sich in derselben Zeile befinden. In diesem Beispiel erscheinen die Schließungs-Tags </nete:forward> aufgrund von Platzbeschränkungen manchmal in neuen Zeilen. Zeilenumbrüche in realen Proxy-Regel-Dateien führen jedoch zu Fehlern.
CA Access Gateway
interpretiert Zeilenumbrüche vor dem Schließungs-Tag </nete:forward> als Zeichen, die zur URL im Element "nete:forward" gehören.
Weiterleitungs- und Umleitungssyntax
Beim Weiterleiten oder Umleiten einer Anforderung verwendet
CA Access Gateway
ein System, um den vom Benutzer angegebenen URI vollständig oder teilweise beizubehalten. Der URI verweist auf eine Ressource, die sich auf einem Zielserver befindet und für die Abwicklung einer Anforderung interpretiert werden muss.
Eines der folgenden Elemente kann an die in einem Weiterleitungs- oder Umleitungsziel angegebenen URL angefügt werden:
  • $0
    Fügt die gesamte URI-Zeichenfolge aus der Benutzeranforderung an das in der Proxy-Regel angegebene Ziel an.
    Wenn eine Proxy-Regel beispielsweise alle Anforderungen für www.company.com an proxy.company.com$0 weiterleitet und ein Benutzer www.company.com/employees/hr/index.html anfordert, wird diese Anforderung an proxy.company.com/employees/hr/index.html weitergeleitet.
  • $1
    Gibt an, dass alles rechts vom übereinstimmenden Text an die weitergeleitete oder umgeleitete Anforderung angehängt wird. Verwenden Sie dies in nete:case Elementen, in denen das übergeordnete nete:cond-Element eine Übereinstimmung mit einer URI-Teilzeichenfolge angibt, die mit einem Vergleich beginnt. 
    Ein Beispiel ist eine Konfigurationsdatei für Proxy-Regeln mit folgendem nete:cond-Element:
    <nete:cond type="uri" criteria="beginswith">
    Nehmen Sie an, dass es sich bei dieser Bedingung um ein untergeordnetes Element einer Bedingung handelt, die URIs für den Hostnamen www.company.com und folgendes nete:case-Element auswertet:
    <nete:case value="/hr"> <nete:forward>http://hr.company.com$1</nete:forward> </nete:case>
    Bei folgender Benutzeranforderung:
    Wird die Anforderung folgendermaßen weitergeleitet:
    Da im Beispiel wird der Parameter "$1" angegeben ist, wird Teil "/hr" des URI bei der Weiterleitung der Anforderung an hr.company.com weggelassen.
nete cond
Das Element "nete:cond" gibt eine Bedingung an, die ausgewertet wird, um festzustellen, wie eingehende Anforderungen verarbeitet werden. Sie müssen ein Attribut einschließen, das ausgewertet werden muss.
Es verwendet folgende Syntax:
<!ELEMENT nete:cond (nete:case+,nete:default)>
Sie können folgende Attribute definieren:
<!ATTLIST nete:cond type (header | host | uri | query | cookie) #REQUIRED criteria (equals | beginswith | endswith | contains | exists) "equals" headername CDATA #IMPLIED>
  • header
    Gibt an, dass ein HTTP-Header verwendet wird, um das Ziel einer Anforderung zu bestimmen. Sie müssen auch einen Header-Namen definieren. Bedingungen, die für den Vergleich Header verwenden, benötigen das zusätzliche Argument headername="Wert", wobei "Wert" der HTTP-Header oder
    CA Single Sign-on
    -Header ist.
    In den nete:cond-Elementen können durch
    CA Single Sign-on
    -Antworten generierte HTTP-Header angegeben werden.
    Beispiel:
    <nete:cond type="header" headername="USER_AGENT">
    Dieses Element gibt an, dass ein Header verwendet wird, und dass es sich beim auszuwertenden Header um USER_AGENT handelt.
  • Host
    Gibt in Bereitstellungen, in denen mehrere virtuelle Hosts verwendet werden, einen Hostnamen an. Da Portnummern als Teil des Hosts behandelt werden, können Sie das später beschriebene endswith-Kriterium gemeinsam mit der Host-Bedingung verwenden, um Anforderungen anhand von Portnummern um- oder weiterzuleiten.
  • Abfrage
    Gibt den Abfrageteil einer URI-Zeichenfolge an, die auf das Zeichen "?" folgt. Dies ist vergleichbar mit einem nete:cond-Element, das den URI folgendermaßen verwendet:
    • URI
      Gibt den auf den Servernamen folgenden einheitlichen Ressourcenbezeichner an, der Teil einer angeforderten URL ist. Die endswith-Kriterien können in Verbindung mit der URI-Bedingung verwendet werden, um Anforderungen nach Dateierweiterung um- bzw. weiterzuleiten.
    • cookie
      Gibt an, dass ein Cookie-Attribut verwendet wird, um zu bestimmen, auf welche Weise eine Anforderung um- oder weitergeleitet wird. Wenn ein Cookie-Wert codiert ist, geben Sie das Codierungsschema im Parameter "encoding" ein. Es wird ausschließlich das base64-Codierungsschema unterstützt. Die Erstellung von Cookies wird nicht unterstützt. Mögliche Fälle codierter Cookies:
      • Wenn ein Cookie mit base64 codiert ist, geben Sie im nete:case-Element den Cookie-Wert im Wertattribut und base64 als Codierungsparameter ein. Der base64-Codierungsalgorithmus wird verwendet, um den von einer HTTP-Anforderung empfangenen Cookie-Wert zu entschlüsseln. Das Ergebnis des entschlüsselten Werts wird mit dem im Wertattribut angegebenen Wert verglichen.
      • Wenn ein Cookie nicht codiert ist, geben Sie den Cookie-Wert als reinen Text ins Wertattribut ein. Im nete:case-Element können Sie für den Codierungsparameter "blank" angeben. Den angegebene reine Text wird als Cookie-Wert akzeptiert, und "nete:cond" wird überprüft.
      • Wenn ein Cookie mit einem anderen Codierungsschema codiert ist, geben Sie den codierten Cookie-Wert im Wertattribut ein, und setzen Sie den Codierungsparameter im Element "nete:case" auf "blank". Der angegebene codierte Cookie-Wert wird als reiner Text akzeptiert und wird herangezogen, um "nete:cond" zu überprüfen.
    Eines der oben beschriebenen Typattribute muss im Element "nete:cond" enthalten sein. Darüber hinaus muss das Element "nete:cond" ein Kriterium aufweisen, das den Vergleich definiert, den die Proxy-Engine für den Wert der Bedingungen für eine eingehende Anforderung ausführt. Mögliche Kriterien:
  • EQUALS
    Gibt an, dass der Wert des Typattributs des übergeordneten nete:cond-Elements mit dem Inhalt des Wertattributs des nete:case-Elements übereinstimmen muss, damit auf eine Anforderung reagiert wird.
    Wenn keine Kriterien angegeben sind, wird "equals" als Standardkriterium verwendet.
  • beginswith
    Gibt an, dass der Wert des Typattributs des übergeordneten nete:cond-Elements mit dem Inhalt des Wertattributs des nete:case-Elements beginnen muss, damit auf eine Anforderung reagiert wird.
  • endswith
    Gibt an, dass der Wert des Typattributs des übergeordneten nete:cond-Elements mit dem Inhalt des Wertattributs des nete:case-Elements enden muss, damit auf eine Anforderung reagiert wird.
  • enthält
    Gibt an, dass der Wert des Typattributs des übergeordneten nete:cond-Elements den Inhalt des Wertattributs des nete:case-Elements enthalten muss, damit auf eine Anforderung reagiert wird.
  • Vorhanden
    Gibt an, dass das übergeordnete nete:cond-Element vorhanden sein und das Wertattribut des nete:case-Elements "true" sein muss, damit auf eine Anforderung reagiert wird. Sie können das Kriterium "exists" nur mit Header- und Cookie-Attributen verwenden.
Jedes nete:cond-Element benötigt mindestens ein untergeordnetes nete:case-Element. Die untergeordneten nete:case-Elemente enthalten die eindeutigen Werte, die verwendet werden, um Anforderungen an die entsprechenden Ziele um- oder weiterzuleiten.
nete default
Definition des Elements "nete:default":
<!ELEMENT nete:default (nete:cond | nete:xprcond | nete:forward | nete:redirect | nete:local)>
Dieses Element ist erforderlich und muss ein untergeordnetes Element jedes nete:cond-Elements sein. Wenn eine Anforderung keinem in einem nete:cond-Elementen enthaltenen nete:case-Element entspricht, bestimmt das nete:default-Element, auf welche Weise die Anforderung verarbeitet wird.
Dem nete:default-Element können jene Elemente als untergeordnete Elemente zugeordnet sein, die für ein nete_case-Element verfügbar sind. Wenn Sie nete:cond-Elemente als untergeordnete Elemente eines nete:default-Elements erstellen, achten Sie bei Standardfällen darauf, dass alle möglichen Client-Anforderungen von
CA Access Gateway
verarbeitet werden können.
Im folgenden Beispiel leitet das Element "nete:default" alle Anforderungen, die nicht den Kriterien einer der anderen Proxy-Regeln entsprechen, an eine Homepage mit allgemeinen Informationen weiter.
<nete:default> <nete:forward>http://home.company.com/index.html </nete:forward> </nete:default>
Die öffnenden und schließenden Tags (<nete:forward>
URL
</nete:forward>) müssen sich in derselben Zeile befinden. In diesem Beispiel erscheinen die Schließungs-Tags </nete:forward> aufgrund von Platzbeschränkungen manchmal in neuen Zeilen. Zeilenumbrüche in realen Proxy-Regel-Dateien führen jedoch zu Fehlern.
CA Access Gateway
interpretiert Zeilenumbrüche vor dem Schließungs-Tag </nete:forward> als Zeichen, die zur URL im Element "nete:forward" gehören.
nete forward
Definition des Elements "nete:forward":
<!ELEMENT nete:forward (#PCDATA)>
Das Element "nete:forward" leitet eine Anforderung an eine bestimmte URL weiter.
Hinweis
: Die Tags <nete:forward> und </nete:forward> müssen sich in derselben Zeile befinden. Wenn sie sich nicht in derselben Zeile befinden, interpretiert
CA Access Gateway
Zeilenumbrüche vor dem Schließungs-Tag als Zeichen, die zur URL im Element gehören. Dies führt dazu, dass der Weiterleitungsdienst fehlschlägt.
Im folgenden Beispiel leitet das Element "nete:forward" Anforderungen weiter und behält dabei den vom Benutzer angeforderten URI bei.
Wenn die Anforderung des Benutzers die Kriterien des übergeordneten nete:case-Elements erfüllt, wird sie an home.company.com weitergeleitet. Aus diesem Grund wird eine Anforderung für http://server.company.com/hr/benefits/index.html, die durch das vorherige nete:forward-Element weitergeleitet wird, abgewickelt, indem sie an http://home.company.com/hr/benefits/index.html weitergeleitet wird.
Wenn Sie eine Anforderung über SSL weiterleiten möchten, achten Sie darauf, dass Sie https anstelle von http verwenden, wenn Sie das im <nete:forward>-Element enthaltene Ziel definieren.
Das Element "nete:forward" enthält das folgende Attribut:
<!ATTLIST nete:forward filter CDATA #IMPLIED>
Mit diesem Attribut können Sie den Namen einer Java-Filterklasse angeben, die im Zuge einer Weiterleitung von
CA Access Gateway
an einen Zielserver aufgerufen werden kann. Filter können mithilfe der Filter-API geschrieben werden.
Attribut "filter"
Das Element "nete:forward" enthält das folgende Attribut:
<!ATTLIST nete:forward filter CDATA #IMPLIED>
Mit diesem Attribut können Sie den Namen einer Java-Filterklasse angeben, die im Zuge einer Weiterleitung von
CA Access Gateway
an einen Zielserver aufgerufen werden kann. Filter können entsprechend der Filter-API geschrieben werden.
nete redirect
Definition des Elements "nete:redirect":
<!ELEMENT nete:redirect (#PCDATA)>
Das Element "nete:redirect" gibt eine an einen Benutzer zurückgegebene Antwort an, die die Benutzeranforderung an einen geeigneten Zielserver umleitet. Für PCDATA gilt die standardmäßige Weiterleitungs- und Umleitungssyntax. Nach der Umleitung wird die Fertigstellung der Anforderung nicht mehr über
CA Access Gateway
abgewickelt. Stattdessen wird die Anforderung von jenem Server verarbeitet, der das Ziel der Umleitung ist.
Die Tags <nete:redirect> und </nete:redirect> müssen sich in einer Zeile in der Proxy-Regeln-Datei befinden. Wenn sie sich nicht in derselben Zeile befinden, interpretiert
CA Access Gateway
Zeilenumbrüche vor dem Schließungs-Tag als Zeichen, die zur URL im Element gehören. Dies führt dazu, dass der Umleitungsdienst fehlschlägt.
Im folgenden Beispiel leitet das Element "nete:redirect" Anforderungen um und behält dabei den vom Benutzer angeforderten URI bei. Anders als bei nete:forward-Elementen wird
CA Access Gateway
nach der Umleitung aus der Transaktion entfernt, und die Ressourcen werden dem Benutzer direkt vom Zielserver verfügbar gemacht.
Wenn eine Benutzeranforderung für http://www.company.com/hr/index.html im obigen Beispiel die Kriterien eines übergeordneten nete:case-Elements erfüllt und umgeleitet wird, wird der Benutzer umgeleitet, und in seinem Browser erscheint die URL des Zielservers, der die Anforderung abwickelt:
Wenn Sie eine Anforderung über SSL weiterleiten möchten, achten Sie darauf, dass Sie https anstelle von http verwenden, wenn Sie das im <nete:redirect>-Element enthaltene Ziel definieren.
nete local
Das Element "nete:local" ist für zukünftige Funktionen konzipiert und sollte in Konfigurationsdateien für Proxy-Regeln nicht verwendet werden.
nete xprcond
Das Element "nete:xprcond" kann wie ein nete:cond-Element verwendet werden, wenn Sie in Ihren Proxy-Regeln reguläre Ausdrücke als Bedingungen verwenden möchten. Reguläre Ausdrücke können verwendet werden, um die URI-Zeichenfolge und andere Zeichenfolgen, die in Ihren Proxy-Regeln an die Abfragezeichenfolge angefügt sind, auszuwerten.
Definition des Elements "nete:xprcond":
<!ELEMENT nete:xprcond (nete:xpr+, nete:xpr-default)>
Dieses Element muss mindestens ein nete:xpr-Element und genau ein nete:xpr-default-Element enthalten.
nete xpr und nete xpr-default
Das Element "nete:xprcond" ähnelt dem nete:cond-Element und enthält weitere, auf einem regulären Ausdruck basierte Regelelemente sowie das gewünschte Verhalten, wenn
CA Access Gateway
eine Übereinstimmung mit dem Muster findet. Eine nete:xpr-default-Element enthält das Standardverhalten für Kombinationen von URIs oder Abfragezeichenfolgen, die mit keinem der regulären Ausdrücke in den nete:xpr-Elementen in einem nete:xprcond-Element übereinstimmen.
Definition des Elements "nete:xpr":
<!ELEMENT nete:xpr (nete:rule, nete:result)>
Ein nete:xpr-Element enthält ein nete:rule-Element, das einen regulären Ausdruck definiert, und ein nete:result-Element, das das Verhalten für Zeichenfolgen angibt, die mit dem regulären Ausdruck übereinstimmen.
Definition des Elements "nete:xpr-default":
<!ELEMENT nete:xpr-default (nete:forward|nete:redirect|nete:local)>
Das nete:xpr-default-Element gibt eine Weiterleitung oder Umleitung an, die ausgeführt werden soll, wenn der bzw. die von
CA Access Gateway
ausgewertete URI oder Abfragezeichenfolge nicht mit den Bedingungen eines im übergeordneten nete:xprcond-Element definierten nete:xpr-Elements übereinstimmt.
nete rule und nete result
Die Elemente "nete:rule" und "nete:result" müssen in einem nete:xpr-Element enthalten sein. Das Element "nete:cond" gibt den regulären Ausdruck an, den
CA Access Gateway
für eingehende Anforderungen auswertet. Das Element "nete:result" bestimmt das Verhalten für die Zuordnung von Anforderungen.
Definition des Elements "nete:rule":
<!ELEMENT nete:rule (#PCDATA)>
Dieses Element enthält eine Zeichenfolge, bei der es sich um einen regulären Ausdruck handelt. URI und Abfragezeichenfolge einer Anforderung werden mit diesem regulären Ausdruck verglichen, um zu bestimmen, ob die Anforderung die nete:xpr-Bedingung erfüllt.
Definition des Elements "nete:result":
<!ELEMENT nete:result (#PCDATA)>
Mögliche Attribute in nete:result-Elementen:
<!ATTLIST nete:result service (forward|redirect) "forward">
Dieses Element enthält eine Zeichenfolge, die aus einer Ersatzzeichenfolge (URL) besteht, anhand derer
CA Access Gateway
eine URL erstellt, die per Umleitung oder Weiterleitung an einen Dienst übergeben werden soll. Das Attribut "service" wird verwendet, um den Dienst anzugeben, der die URL empfangen soll. Der Standarddienst ist der Weiterleitungsdienst, der in der Konfigurationsdatei "server.conf" definiert ist.
Bei der Ersetzungs-URL im nete:result-Element sollte es sich um eine URL handeln, die optional $# enthalten kann, wobei # für 0, 1, 2 usw. steht.
  • "$0" bedeutet, dass URI und Abfragezeichenfolge vollständig ausgewertet werden.
  • $n ist jener Teil des angeforderten URI, der mit dem n-ten Satz von Klammern im regulären Ausdruck übereinstimmt, der im zugeordneten nete:rule-Element beschrieben ist.
Ein Satz von Proxy-Regeln kann z. B. Folgendes enthalten:
 
<nete:xprcond>
<nete:xpr>
<nete:rule>^/realma(.*)</nete:rule>
<nete:result>http://server1.company.com$1</nete:result>
</nete:xpr>
<nete:xpr-default>
<nete:forward>http://www.company.com$0</nete:forward>
</nete:xpr-default>
</nete:xprcond>
Die Tags <nete:result>URL</nete:result> müssen sich in einer Zeile in der Proxy-Regeln-Datei befinden. Wenn sie sich nicht in derselben Zeile befinden, interpretiert
Zeilenumbrüche vor dem Schließungs-Tag als Zeichen, die zur URL im Element gehören. Dies führt dazu, dass der Dienst fehlschlägt.
Beispielanforderung für die vorhergehende Proxy-Regel mit nete:xprcond:
Resultierende Weiterleitung:
Verarbeitung von Antworten
CA Access Gateway
verwendet
CA Single Sign-on
-Antworten, um das Ziel von Anforderungen zu ermitteln. Da Transaktionen, die über
CA Access Gateway
geleitet werden, eine Interaktion zwischen dem
CA Access Gateway
-Web-Agent und
CA Single Sign-on
involvieren, können alle
CA Single Sign-on
-Antworten, die im Zuge von Authentifizierung und Autorisierung erfasst wurden, von
CA Access Gateway
zum Bestimmen des Anforderungsziels herangezogen werden.
Wenn beispielsweise ein Benutzerverzeichnis Informationen zum Kontotyp für eine Bankwebsite enthält, kann
CA Access Gateway
Benutzer mit verschiedenen Kontotypen an verschiedene Proxy-Ziele leiten. Dadurch können Unternehmen wichtigen Kunden eine bessere Servicequalität bieten. Kunden mit Standardkonten können von einem Satz von Zielservern verarbeitet werden, während Kunden mit Premium-Konten durch einen eigenen Satz von Hochleistungs-Zielservern verarbeitet werden.
Funktionsweise von nete xprcond-Elementen
Die Verarbeitung eines nete:xprcond-Elements ähnelt der Verarbeitung sämtlicher anderer nete:cond-Elemente. Wenn
CA Access Gateway
bei der Verarbeitung von Anforderungen in einer Konfigurationsdatei einer Proxy-Regel auf ein nete:xprcond-Element stößt, geschieht Folgendes:
  1. CA Access Gateway
    das erste nete:xpr-Element im nete:xprcond-Element.
  2. Die Proxy-Engine wertet den regulären Ausdruck im nete:rule-Element für URI und Abfragezeichenfolge der Anforderung aus.
  3. Wenn URI und Abfragezeichenfolge der Anforderung mit dem regulären Ausdruck im nete:rule-Element übereinstimmen, löst
    CA Access Gateway
    die Ergebniszeichenfolge unter Verwendung des übereinstimmenden Ergebnisses auf. Die Anforderung wird an den angegebenen Dienst mit der aus dem nete:result-Element abgeleiteten URL weitergeleitet.
  4. Wenn URI und Abfragezeichenfolge der Anforderung nicht mit dem regulären Ausdruck im ersten nete:rule-Element übereinstimmen, wertet die Proxy-Regel-Engine das nächste nete:xpr-Element aus (Wiederholung der Schritte 2 und 3). Dieser Vorgang wird so lange fortgesetzt, bis die Regel-Engine eine Übereinstimmung findet oder zum Element "nete:xpr-default" gelangt.
  5. Wenn vor dem nete:xpr-default-Element keine Übereinstimmung gefunden wird, bestimmen die Inhalte von "nete:xpr-default", auf welche Weise die Anforderung umgeleitet oder weitergeleitet wird.
Syntax für reguläre Ausdrücke
In diesem Abschnitt wird die Syntax beschrieben, die bei der Erstellung von regulären Ausdrücken für nete:rule-Elemente verwendet werden sollte. Ein nete:xprcond-Element ist folgendermaßen aufgebaut:
<nete:xprcond> <nete:xpr> <nete:rule>regular_expression</nete:rule> <nete:result>result</nete:result> </nete:xpr> <nete:xpr-default>forward_destination</nete:xpr-default> </nete:xprcond>
Das Element "nete:rule" im nete:xpr-Element muss einem regulären Ausdrucks entsprechen, der die Syntax in der folgenden Tabelle verwendet. Diese Syntax ist konsistent mit der Syntax für reguläre Ausdrücken, die von Apache unterstützt wird. Eine Beschreibung finden Sie unter http://www.apache.org.
Zeichen
Ergebnisse
Unicode-Zeichen
Alle identischen Unicode-Zeichen
\
Escape-Zeichen für ein Metazeichen (z. B. *)
\\
Stimmt mit einem einzelnen '\'-Charakter überein
\0nnn
Bestimmtes Oktalzeichen
\xhh
8-Bit-Hexadezimalzeichen
\\uhhhh
16-Bit-Hexadezimalzeichen
\t
ASCII-Tabulatorzeichen
\n
ASCII-Zeilenumbruchszeichen
\r
ASCII-Rückgabezeichen
\f
ASCII-Seitenvorschubszeichen
[abc]
Einfache Zeichenklasse
[a-zA-Z]
Zeichenklasse mit Bereichen
[^abc]
Negierte Zeichenklasse
[:alnum:]
Alphanumerische Zeichen
[:alpha:]
Buchstaben
[:blank:]
Leerzeichen und Tabulatorzeichen
[:cntrl:]
Steuerzeichen
[:digit:]
Numerische Zeichen
[:graph:]
Druckbare. sichtbare Zeichen (Leerzeichen sind beispielsweise druckbar, aber nicht sichtbar; "a" ist beides)
[:lower:]
Kleinbuchstaben
[:print:]
Druckbare Zeichen (Zeichen, die keine Steuerzeichen sind)
[:punct:]
Interpunktionszeichen (Zeichen, die keine Buchstaben, Ziffern, Steuerzeichen oder Leerzeichen sind)
[:space:]
Leerzeichen (z. B. Leerzeichen, Tabulatur oder Seitenvorschub)
[:upper:]
Großbuchstaben
[:xdigit:]
Hexadezimale Ziffern
[:javastart:]
Beginn einer Java-Kennung
[:javapart:]
Teil einer Java-Kennung
hostet.
Stimmt mit jedem Zeichen außer 'neue Zeile' überein
\w
"Wort"-Zeichen (alphanumerisches Zeichen plus "_")
\W
Kein Wort-Zeichen
\s
Leerzeichen
\S
Kein Leerzeichen
\d
Ziffer
\D
Keine Ziffer
^
Übereinstimmungen nur am Anfang einer Zeile
$
Übereinstimmungen nur am Ende einer Zeile
\b
Wortgrenze
\B
Keine Wortgrenze
A*
Stimmt mit 0 oder mehr A überein ("gierig")
A+
Stimmt mit 1 oder mehr A überein ("gierig")
A?
Stimmt mit 1 oder 0 A überein ("gierig")
A{n}
Exakt n mal A (greedy)
A{n,}
Mindestens n Mal A (greedy)
A{n,m}
Mindestens n Mal und höchstens m Mal A (greedy)
A*?
Stimmt mit 0 oder mehr A überein ("zurückhaltend")
A+?
Stimmt mit 1 oder mehr A überein ("zurückhaltend")
A??
Stimmt mit 0 oder 1 A überein ("zurückhaltend")
AB
Stimmt mit A gefolgt von B überein
A|B
Stimmt mit A oder B überein
(A)
Wird für die Gruppierung von Teilausdrücken verwendet
\1
Rückverweis auf den 1. eingeklammerten Unterausdruck
\n
Rückverweis auf den n. eingeklammerten Unterausdruck
Alle Abschlussoperatoren (+, *, ?) sind standardmäßig "greedy". Das bedeutet, dass sie mit so vielen Elementen der Zeichenfolge wie möglich übereinstimmen, ohne die gesamte Übereinstimmung zu verhindern. Wenn Sie möchten, dass ein Abschluss "zurückhaltend" ist (nicht "gierig"), können Sie einfach ein ’?’ anfügen. Ein zurückhaltender Abschluss stimmt bei der Suche nach Übereinstimmungen mit so wenigen Elementen der Zeichenfolge wie möglich überein. Die Abschlusszeichen {m, n} unterstützen derzeit keine Reluctancy.
Beispiele für reguläre Ausdrücke in nete rule und nete result
Reguläre Ausdrücke sind ein sehr flexibles und leistungsstarkes Tool, das in
CA Access Gateway
-Proxy-Regeln eingesetzt werden kann. Dieser Abschnitt enthält einige Beispiele für nete:rule-Elemente in Proxy-Regeln. Die Beispiele enthalten auch verschiedene Verwendungen des nete:result-Elements, die veranschaulichen, wie Gruppierungen in einem nete:rule-Element verwendet werden können, um das Ziel, das durch ein untergeordnetes Element eines nete:xprcond-Elements generiert wird, zu beeinflussen.
Zuordnung derselben Regel zu mehreren Zielservern
Im folgenden Beispiel enthält ein nete:rule-Element einen regulären Ausdruck, der zum Weiterleiten von Anforderungen an mehrere, unterschiedliche Ziele verwendet werden kann. In diesem Beispiel wird angenommen, dass
CA Access Gateway
URIs empfängt, die folgendermaßen aufgebaut sind:
/GOTO=
Pfad oder Dateiname
Beachten Sie, dass ein nete:xprcond-Element folgende untergeordnete Elementen enthält:
<nete:xpr> <nete:rule>/GOTO=(.*)/(.*)</nete:rule> <nete:result>http://$1/$2</nete:result> </nete:xpr>
Der reguläre Ausdruck im nete:rule-Element und das zugehörige nete:result-Element stimmen mit URIs überein, die in "/GOTO=string" resultieren. Wenn eine Übereinstimmung gefunden wurde, verwendet
CA Access Gateway
die erste Zeichenfolge nach dem Zeichen "=" im URI als $1-Wert des Ergebnisses und den Wert nach dem ersten /-Zeichen nach dem = als $2-Ergebnis. Das Element "nete:result" kombiniert diese Elemente zum Erstellen einer URL. Standardmäßig verwenden nete:result-Elemente den
CA Access Gateway
-Weiterleitungsdienst.
Der URI einer Anforderung, die durch das oben beschriebene nete:xpr-Element ausgewertet wurde, kann beispielsweise folgendermaßen aussehen:
Anschließend findet der reguläre Ausdruck im nete:rule-Element eine Übereinstimmung und weist den Wert $1 als server1.company.com und den Wert $2 als "index.html" zu. Das nete:result-Element bildet aus diesen Werten folgende URL:
Diese URL ist das Ziel, das
CA Access Gateway
für die Auflösung der Anforderung verwendet.
Reguläre Ausdrücke zum Umleiten von Benutzern
Das Element "nete:result" kann auch verwendet werden, um eine Umleitungsantwort zu erstellen, die an den Benutzer, der die Ressource anfordert, zurückgegeben wird. Dadurch wird erzwungen, dass eine Anforderung nach der Authentifizierung und Autorisierung von einem anderen Server als
CA Access Gateway
verarbeitet wird. Das folgende Beispiel ist ein nete:xpr-Element, das im untergeordneten nete:result-Element eine Umleitung angibt.
<nete:xpr> <nete:rule>/REDIR=(.*)/(.*)</nete:rule> <nete:result service="redirect">http://$1/$2</nete:result> </nete:xpr>
Das Attribut "service" weist
CA Access Gateway
an, anstelle des standardmäßigen Weiterleitungsdiensts den Umleitungsdienst zu verwenden.
Header-Werte in Weiterleitungen, Umleitungen und Ergebnisfiltern
Der Wert eines HTTP-Header oder
CA Single Sign-on
-Antwort-Header kann in den Elementen "nete:forward", "nete:redirect" und "nete:result" direkt ersetzt werden. Wenn ein URl in einem Weiterleitungselement, einem Umleitungselement oder einer Regel in einem Element eines Ergebnisfilters {
{HEADER_NAM
E}} enthält, sucht die Proxy-Engine nach einem Header in einer Anforderung, die dem angegebenen Header entspricht, und ersetzt den Header-Wert vor der weiteren Verarbeitung der Weiterleitung, der Umleitung oder des Ergebnisses. Wenn kein übereinstimmender Header in einer Anforderung gefunden wird, ersetzt die Proxy-Engine anstelle des Header-Werts eine leere Zeichenfolge.
Bei Benutzernamen wird zwischen Groß- und Kleinschreibung unterschieden.
Dynamischer Header-Wert in nete forward
Um einen dynamischen Header-Wert als Teil eines nete:forward-Elements zu verwenden, fügen Sie zum URL-Teil der Weiterleitung einfach {{
HEADER_NAME
}} hinzu. Beispiel:
Sie können in einem nete:forward-Element mehrere Header verwenden. Beispiel:
Dynamischer Header-Wert in nete redirect
Um einen dynamischen Header-Wert als Teil eines nete:redirect-Elements zu verwenden, fügen Sie zum URL-Teil der Umleitung einfach {{
HEADER_NAME
}} hinzu. Beispiel:
Sie können in einem nete:redirect-Element mehrere Header verwenden. Beispiel:
Dynamischer Header-Wert in nete result
Um einen dynamischen Header-Wert als Teil eines nete:result-Elements zu verwenden, fügen Sie zum URL-Teil des Ergebnisses einfach {{
HEADER_NAME
}} hinzu. Beispiel:
Sie können anderen Funktionen von Proxy-Regeln wie z. B. Filter gemeinsam mit dynamischen Header-Werten verwenden. Beispiel:
<nete:result filter="filter1">http://$1/$2?{{HEADER_NAME}}</nete:result>
Verarbeitung von Antworten
CA Access Gateway
verwendet
CA Single Sign-on
-Antworten, um das Ziel von Anforderungen zu ermitteln. Da Transaktionen, die über
CA Access Gateway
geleitet werden, eine Interaktion zwischen dem
CA Access Gateway
-Web-Agent und
CA Single Sign-on
involvieren, können alle
CA Single Sign-on
-Antworten, die im Zuge von Authentifizierung und Autorisierung erfasst wurden, von
CA Access Gateway
zum Bestimmen des Anforderungsziels herangezogen werden.
Wenn beispielsweise ein Benutzerverzeichnis Informationen zum Kontotyp für eine Bankwebsite enthält, kann
CA Access Gateway
Benutzer mit verschiedenen Kontotypen an verschiedene Proxy-Ziele leiten. Dadurch können Unternehmen wichtigen Kunden eine bessere Servicequalität bieten. Kunden mit Standardkonten können von einem Satz von Zielservern verarbeitet werden, während Kunden mit Premium-Konten durch einen eigenen Satz von Hochleistungs-Zielservern verarbeitet werden.
Verwalten von Proxy-Regeln
Führen Sie zum Verwalten von Proxy-Regeln einer der folgenden Schritte aus:
  • Importieren Sie die Datei "proxyrules.xml", und bearbeiten Sie die Proxy-Regeln bei Bedarf, indem Sie folgende Schritte ausführen:
    1. Navigieren Sie zu "Proxy-Regeln", "Regeln".
    2. Klicken Sie auf "Import".
    3. Klicken Sie auf "Durchsuchen", um den Speicherort der Datei auszuwählen, und klicken Sie auf "Hochladen".
    4. Sie können die importierten Proxy-Regeln im Strukturmodus oder im Textmodus anzeigen.
    5. (Optional) Bearbeiten Sie die Proxy-Regeln, und klicken Sie auf "Speichern".
    6. (Optional) Bearbeiten Sie die vorhandenen Proxy-Regeln in einem Strukturmodus oder Textmodus.
  • Bearbeiten Sie die vorhandenen Proxy-Regeln in einem Strukturmodus oder einem Textmodus, indem Sie folgende Schritte durchführen:
    1. Navigieren Sie zu "Proxy-Regeln", "Regeln".
    2. Klicken Sie auf "Textmodus".
    3. Bearbeiten Sie die erforderlichen Proxy-Regeln für Ihre Umgebung.
    4. Klicken Sie auf "Speichern".
Hinzufügen von Filtern
Benutzerdefinierte Filter sind für den Bedarf des Kunden definierte Filter.  
CA Access Gateway
verwendet benutzerdefinierte Filter, um eine Anforderung zu manipulieren, bevor sie an einen Back-End-Server weitergeleitet wird, sowie dazu, die Antwort des Back-End-Servers an den Benutzer-Client zu manipulieren.
Um auf der Admin-Benutzeroberfläche Filter zu "proxyrules.xml" oder im Textmodus hinzuzufügen, geben Sie den Filter entsprechend der Proxy-Regeln ein.
Beispiel
:
<nete:forward filter="filter1"http://FQDN$0</nete:forward>
Um Filter auf der Admin-Benutzeroberfläche im Strukturmodus hinzuzufügen, führen Sie die folgenden Schritte aus:
  1. Klicken Sie auf "Proxy-Regeln", "Filter".
  2. Klicken Sie auf Hinzufügen.
  3. Geben Sie den Filternamen und den Java-Klassennamen in "Name" und "Klasse" ein.
  4. (Optional) Um Filterparameter hinzuzufügen, klicken Sie in der Tabelle "Parameter" auf "Hinzufügen", und geben Sie die Details ein.
  5. Klicken Sie auf "OK".
Um einen Filter auf der Admin-Benutzeroberfläche im Strukturmodus anzuwenden, geben Sie den Namen des Filters ein, den Sie anwenden wollen, wenn Sie eine Proxy-Regel für eine Aktion erstellen.
Validieren der Proxy-Regeln
Sie können die neuen Proxy-Regeln durch Abgleichen mit der DTD für Proxy-Regeln validieren. Die Validierung stellt sicher, dass die neuen Proxy-Regeln in den richtigen XML-Datei-Konfigurationen gemäß der DTD definiert sind.
Um die neuen Proxy-Regeln zu validieren, klicken Sie auf der Seite "Proxy-Regeln" in einem beliebigen Modus auf "Bestätigen", nachdem Sie die Proxy-Regeln gespeichert haben.
Testen der Proxy-Regeln
Sie können die Proxy-Regeln testen, um zu überprüfen, ob sie korrekt funktionieren.
Folgen Sie diesen Schritten:
  1. Klicken Sie auf "Proxy-Regeln", "Test der Proxy-Regeln".
  2. Geben Sie zum Testen eine Beispielabfrage ein, die den Proxy-Regeln, die Sie definiert haben, entspricht.
  3. Klicken Sie auf "Proxy-Regeln testen".
  4. Überprüfen Sie, ob das Ergebnis, das in "Ergebnis" angezeigt wird, den definierten Proxy-Regeln entspricht.
Exportieren der Proxy-Regeln
Sie können die neuen Proxy-Regeln über die Admin-Benutzeroberfläche für zukünftige Referenz exportieren.
Folgen Sie diesen Schritten:
  1. Klicken Sie in einem beliebigen Modus auf "Exportieren".
  2. Klicken Sie im Dialogfeld "Dateidownload" auf "Speichern", und geben Sie den Speicherort für die Datei "proxyrules.xml" an.
  3. Klicken Sie auf "OK".
Beispiel für Konfigurationsdateien für Proxy-Regeln
Mit
CA Access Gateway
werden mehrere Beispiele für Konfigurationsdateien für Proxy-Regeln installiert. Sie können diese Beispiel-XML-Dateien als Grundlage für Ihre eigenen Proxy-Regeldateien verwenden.
Sie finden diese Dateien unter
SPS-Installationsverzeichnis
\secure-proxy\proxy-engine\examples\proxyrules. Es wird empfohlen, dass Sie sich die Beispieldatei ansehen, während Sie die Beschreibungen in diesem Handbuch lesen.
Sie können diese Dateien kopieren und an Ihre Bedürfnisse anpassen.
So passen Sie eine Proxy-Regeldatei an und stellen sie bereit
  1. Navigieren Sie zum Verzeichnis
    SPS-Installationsverzeichnis
    \secure-proxy\proxy-engine\examples\proxyrules.
  2. Erstellen Sie eine Kopie der Beispieldatei, die Sie verwenden möchten.
  3. Passen Sie den Inhalt an, und speichern Sie die neue Datei unter einem eindeutigen Namen.
  4. Kopieren Sie die geänderte Datei in das Verzeichnis
    SPS-Installationsverzeichnis
    /secure-proxy/proxy-engine/conf.
  5. Öffnen Sie die Datei "server.conf", um die Abschnitt mit den Proxy-Regeln der Datei so zu ändern, dass er auf die benutzerdefinierte Datei verweist.
Beispiel für Proxy-Regeln: Umleitungs- und Weiterleitungsanforderungen nach virtuellen Hosts
Die Beispieldatei "proxyrules_example1.xml" leitet Anforderungen auf Grundlage des in der Anforderung angegebenen Hostnamens um oder weiter. Die Beispieldatei "proxyrules_example10.xml" leitet
CA Access Gateway
-Anforderungen auch auf Grundlage des in der Anforderung angegebenen Hostnamens weiter.
CA Access Gateway
verwendet die PID in der Proxy-Regel, um die Auslösungen der Proxy-Regel zu zählen. Wenn Sie CA Wily Introscope für die Überwachung von
CA Access Gateway
konfiguriert haben, wird die Anzahl in CA Wily Introscope in den Datenkennzahlen angezeigt.
In dieser Datei leitet ein einfacher Satz von Proxy-Regeln Anforderungen auf Grundlage des in der angeforderten Ressource angegebenen virtuellen Hosts um oder weiter. Alle Anforderungen an den Server bondtrading.company.com werden an server2 weitergeleitet. Alle Anforderungen an banking.company.com werden an server1 weitergeleitet. Alle anderen Anforderungen werden an den Stammserver des Unternehmens weitergeleitet. Dieser ist der Standard für Anforderungen, die keinen Kriterien in einem nete:cond-Element entsprechen.
Die nete:case-Elemente müssen einen Port beinhalten, da die Portnummer als Teil des vom Benutzer angeforderten virtuellen Hosts behandelt werden. Verwenden Sie das Kriterium "beginswith", um den Bedarf von Portnummern zu vermeiden.
Angeforderte URL
Weitergeleitete URL
 
Beispiel für Proxy-Regeln: Umleitungs- und Weiterleitungsanforderungen nach Header-Werten
Die Beispieldatei "proxyrules_example2.xml" leitet
CA Access Gateway
-Anforderungen auf Grundlage des Werts eines HTTP-Header um oder weiter. Der HTTP-Header kann ein Standard-Header sein oder über eine
CA Single Sign-on
-Antwort erstellt werden.
In diesem Beispiel wird davon ausgegangen, dass
CA Access Gateway
Anforderungen an einen standardmäßigen virtuellen Host von www.company.com um- oder weiterleitet.
In dieser Datei bestimmt der Wert der HTTP-Header-Variable "HEADER" das Ziel für die Anforderung.
Die folgende Tabelle veranschaulicht die Ergebnisse von Anforderungen, die Proxy-Regeln basierend auf einem HTTP-Header verwenden.
Angeforderte URL
Weitergeleitete URL
http://www.company.com/index.html
HTTP_HEADER enthält folgende Werte:
HTTP_HEADER="Wert1"
http://www.company.com/index.html
HTTP_HEADER enthält folgende Werte:
HTTP_HEADER="Wert2"
http://www.company.com/index.html
HTTP_HEADER enthält einen anderen Wert als Wert1 oder Wert2.
Der Teil "HTTP_" des Header-Variablennamen im nete:cond-Element muss nicht mit eingeschlossen werden.
CA Access Gateway
geht davon aus, dass "HTTP_" in Header-Variablennamen enthalten ist.
Proxy-Regeln, die Header-Werte verwenden, sind eine hervorragende Möglichkeit zum Weiterleiten von Anforderungen auf Grundlage eines gewünschten Service Level. Zum Beispiel können Sie den Wert der HTTP-Header-Variable, die eine Benutzerkontotyp enthält, verwenden, um Anforderungen für Kunden mit Premium-Konten zu Hochleistungsservern zuzuteilen.
Beispiel für Proxy-Regeln: Umleitungs- und Weiterleitungsanforderungen nach Gerätetyp
Die Beispieldatei "proxyrules_example3.xml" leitet
CA Access Gateway
-Anforderungen auf Grundlage des Typs des Geräts, das für den Zugriff auf die Ressource verwendet wird, um oder weiter.
Der Wert eines HTTP-Header "user-agent" wird verwendet, um zu bestimmen, auf welche Weise eine Anforderung um- oder weitergeleitet wird.
In der Datei werden Benutzer, die mithilfe eines Browsers auf Ressourcen zugreifen (der Benutzeragent enthält Mozilla für Webbrowser), an einen Webserver weitergeleitet, während sämtliche anderen Benutzer an einen Drahtlosserver weitergeleitet werden.
Die folgende Tabelle veranschaulicht die Ergebnisse von Anforderungen, die Proxy-Regeln basierend auf einem Gerätetyp verwenden.
Angeforderte URL
Weitergeleitete URL
http://www.company.com/index.html
Benutzerzugriff auf die Ressource über einen Webbrowser.
http://www.company.com/index.wml
Benutzerzugriff auf die Ressource über ein drahtloses Gerät.
 
Beispiel für Proxy-Regeln: Umleitungs- und Weiterleitungsanforderungen mit URIs
Die Beispieldatei "proxyrules_example4.xml" leitet
CA Access Gateway
-Anforderungen auf Grundlage des in der Benutzeranforderung angegebenen URI um oder weiter.
Die folgende Tabelle veranschaulicht die Ergebnisse von Anforderungen, die Proxy-Regeln basierend auf URIs verwenden.
Angeforderte URL
Weitergeleitete URL
 
Beispiel für Proxy-Regeln: Umleitungs- und Weiterleitungsanforderungen nach Dateierweiterung
Die Beispieldatei "proxyrules_example5.xml" leitet
CA Access Gateway
-Anforderungen auf Grundlage der vom Benutzer angeforderten Dateierweiterung um oder weiter. Dies geschieht durch die Verwendung der URI-Bedingung in Kombination mit dem Kriterium "endswith".
Die Tags <nete:forward> und </nete:forward> werden aufgrund von Platzbeschränkungen in separaten Zeilen angezeigt. In Ihren Konfigurationsdateien für Proxy-Regeln müssen sich die öffnenden und schließenden Tags eines <nete:forward>-Elements jedoch in derselben Zeile befinden. Wenn dies nicht der Fall ist, interpretiert
CA Access Gateway
Zeilenumbrüche als Teil der weitergeleiteten URL, wodurch Anforderungen nicht ordnungsgemäß weitergeleitet werden.
Im vorherigen Beispiel werden Benutzer, die auf JSP-Ressourcen zugreifen, an einen Anwendungsserver weitergeleitet, während Drahtlosbenutzer an einen Drahtlosserver weitergeleitet werden. Alle anderen Benutzer werden an der Startserver weitergeleitet.
Die folgende Tabelle veranschaulicht die Ergebnisse von Anforderungen, die Proxy-Regeln basierend auf Dateierweiterungen verwenden.
Angeforderte URL
Weitergeleitete URL
 
Beispiel für Proxy-Regeln: Umleitungs- und Weiterleitungsanforderungen mit eingebetteten Bedingungen
Die Beispieldatei "proxyrules_example6.xml" leitet
CA Access Gateway
-Anforderungen auf Grundlage von Hostnamen, bestimmten Bedingungen und Gerätetyp um oder weiter. Diese Datei veranschaulicht, wie
CA Access Gateway
komplexe Beziehungen in einer einzigen Konfigurationsdatei verarbeiten kann.
In der Datei müssen sich die <nete:forward>
URL
</nete:forward>-Elemente in derselben Zeile befinden. In diesem Beispiel erscheinen die Schließungs-Tags </nete:forward> aufgrund von Platzbeschränkungen manchmal in neuen Zeilen. Zeilenumbrüche in realen Proxy-Regel-Dateien führen jedoch zu Fehlern.
CA Access Gateway
interpretiert Zeilenumbrüche vor dem Schließungs-Tag </nete:forward> als Zeichen, die zur URL im Element "nete:forward" gehören.
Die folgende Tabelle veranschaulicht die Ergebnisse von Anforderungen, die Proxy-Regeln mit eingebetteten Bedingungen verwenden.
Angeforderte URL
Weitergeleitete URL
http://bondtrading.company.com/index.html
mit dem Header-Wert GOLD_USER="yes"
http://bondtrading.company.com/index.html
mit dem Header-Wert GOLD_USER="no"
http://www.company.com/index.wml
mit einem Header-Wert USER_AGENT, der den Namen eines Drahtlosgeräts enthält
http://home.company.com/
wireless/index.wml
http://www.company.com/index.html
mit einem Header-Wert USER_AGENT, der keinen Namen eines Drahtlosgeräts enthält
 
Beispiel für Proxy: Verwendung von regulären Ausdrücken in Proxy-Regeln
Die Beispieldatei "proxyrules_example7.xml" leitet
CA Access Gateway
-Anforderungen auf Grundlage von nete:xprcond-Elementen mit regulären Ausdrücken um oder weiter. Reguläre Ausdrücke werden anhand von URI und Abfragezeichenfolge einer Anforderung ausgewertet.
In der Datei werden URI und Abfragezeichenfolge der Anforderung mit den drei regulären Ausdrücken, die in den nete:xpr-Elementen definiert sind, abgeglichen. Wenn keine Übereinstimmung mit dem ersten nete:xpr-Element gefunden wird, versucht
CA Access Gateway
einen Abgleich mit dem zweiten und schließlich dem dritten regulären Ausdruck. Wenn keine Übereinstimmungen gefunden werden, wird die Bedingung "nete:xpr-default" verwendet, um die Anforderung zu verarbeiten.
Die folgende Tabelle veranschaulicht die Ergebnisse von Anforderungen, die Proxy-Regeln basierend auf regulären Ausdrücken verwenden.
Angeforderte URL
Weitergeleitete URL
http://server2.company.com/index.html
Der Benutzer wird umgeleitet, damit
server2.company.com die Benutzeranforderung direkt abwickeln muss.
 
Beispiel für Proxy-Regeln: Umleitungs- und Weiterleitungsanforderungen nach Vorhandensein von Cookies
Die Beispieldatei "proxyrules_example8.xml" leitet
CA Access Gateway
-Anforderungen auf Grundlage des Vorhandenseins eines Cookie um oder weiter.
Wenn in diesem Beispiel eine Anforderung den Cookie-Header "mycookie" enthält, leitet
CA Access Gateway
die Anforderung an www.company.com um oder weiter.
Beispiel für Proxy-Regeln: Umleitungs- und Weiterleitungsanforderungen nach Cookie-Werten
Die Beispieldatei "proxyrules_example9.xml" leitet
CA Access Gateway
-Anforderungen auf Grundlage des Werts eines Cookie um oder weiter.
Wenn in diesem Beispiel eine Anforderung den Cookie-Header "mycookie" enthält und kein Codierungsmechanismus angegeben ist, leitet
CA Access Gateway
die Anforderung an www.abcd.com um oder weiter. Wenn eine Anforderung den Cookie-Header "mycookie" sowie den base64-Codierungsmechanismus enthält, leitet
CA Access Gateway
die Anforderung an www.xyz.com um oder weiter.