Configuração das regras do proxy

Conteúdo
casso128figsbrbr
HID_proxy-rules
Conteúdo
3
As rotas do
CA Access Gateway
usam o mecanismo do proxy integrado no servidor para rotear solicitações para os servidores apropriados na empresa. O mecanismo de proxy interpreta as regras do proxy e fornece um serviço de encaminhamento e de redirecionamento, para lidar com a disposição de todas as solicitações do usuário para os recursos de back-end.
As regras do proxy definem como as solicitações são encaminhadas ou redirecionadas para os recursos que estão localizados nos servidores de destino. Um conjunto de regras do proxy é definido de acordo com a DTD das regras do proxy, instalada por padrão, e é armazenado em um arquivo de configuração proxyrules.xml. Por padrão, durante a instalação, o seguinte caminho relativo para o arquivo proxyrules.xml é gerado e usado no parâmetro rules_file da seção <ServiceDispatcher> do arquivo server.conf:
sps_home
/secure-proxy/proxy-engine/conf/proxyrules.xml
Todas as entradas no arquivo proxyrules.xml devem ser bem formadas e satisfazer as regras de sintaxe de acordo com as especificações XML. As alterações no arquivo proxyrules.xml são detectadas automaticamente.
O
CA Access Gateway
oferece suporte para atender solicitações enviadas ao URL MBCS (Multi-Byte Character Set – Conjunto de Caracteres Multibytes) do servidor back-end que satisfaz a solicitação.
Se for detectado um erro nas regras do proxy quando analisar as regras, o
CA Access Gateway
registra o erro no log do servidor que está configurado no arquivo logger.properties, ignora as alterações e usa as regras de proxy existentes.
O arquivo proxyrules.xml contém uma regra padrão que encaminha as solicitações para http://www.ca.com$0, em que $0 anexa o URI inteiro da solicitação original ao destino, que é www.ca.com nesse caso. Você deve alterar essa regra de acordo com seu ambiente.
Planejando rotas para solicitações de entrada
Antes de configurar o arquivo proxyrules.xml, mapeie o roteamento para solicitações de entrada. Dependendo do host virtual que contém o recurso solicitado, as regras do proxy podem usar um destino padrão, encaminhar uma solicitação com base no tipo de agente do usuário ou usar um valor de cabeçalho HTTP para determinar o servidor de destino que irá atender à solicitação.  O
CA Access Gateway
pode fornecer acesso a diversos hosts virtuais.
A ilustração a seguir mostra como as regras do proxy podem ser usadas para rotear solicitações para os servidores de destino apropriados:
Designing Proxy Rules
 
O arquivo proxyrules.xml é processado de cima para baixo. A primeira condição que é atingida por uma solicitação de entrada determina o comportamento do mecanismo de proxy. Por exemplo, se um conjunto de regras do proxy tiver duas condições com base em uma sequência de caracteres contida no URI de uma solicitação, e parte do URI de uma solicitação de entrada corresponde a ambas as sequências de caracteres, a primeira condição listada no arquivo proxyrules.xml será usada para rotear a solicitação.
Regras do proxy também podem ser usadas para controlar as condições mais complexas para direcionar solicitações para servidores de destino.
A ilustração a seguir mostra como as regras do proxy podem ser usadas com um segundo nível de condições aninhado em condições pai:
Designing Proxy Rules with Nested Conditions
 
Terminologia de regras do proxy
Os seguintes termos são usados para descrever as regras do proxy:
  • Destinos
    Define um URL de destino que satisfaz uma solicitação.  O
    CA Access Gateway
    encaminha uma solicitação para um destino ou envia uma resposta de redirecionamento para um usuário que especifica um destino. Um conjunto de regras do proxy deve conter destinos que podem ser alcançados de acordo com as condições e os casos definidos nas regras do proxy.
  • Condições
    Define os atributos de uma condição de uma solicitação que determina o destino da solicitação. Cada condição pode ter muitos casos que devem ser avaliados para direcionar a solicitação para um destino adequado. Cada condição deve conter um elemento padrão que define o comportamento se uma solicitação não corresponder a qualquer um dos casos definidos na condição.
    As condições podem incluir as seguintes opções:
    • URI
      Especifica que a parte do URL especificado depois do nome do host deve ser usada para determinar como rotear uma solicitação. Conforme os critérios descritos no DTD, use uma parte de um URI como a extensão do arquivo de recurso solicitado, para rotear solicitações.
    • Sequência de caracteres de consulta
      Especifica que a parte de sequência de caracteres de consulta de um URI deve ser usada para determinar como rotear uma solicitação. A sequência de caracteres de consulta inclui todos os caracteres após um '?' na solicitação.
    • Host
      Especifica que o nome do host do servidor solicitado deve ser usado para determinar como rotear uma solicitação. O número da porta do nome do host também pode ser usado como critério para solicitações de roteamento. Essa condição é usada quando o proxy tem mais de um servidor virtual.
    • Cabeçalho
      Especifica que o valor de qualquer cabeçalho HTTP deve ser usado para determinar como rotear uma solicitação. Para rotear solicitações de acordo com o tipo de dispositivo que está sendo usado para acessar recursos, as solicitações podem ser roteadas de acordo com o cabeçalho HTTP USER_AGENT.
      Os cabeçalhos HTTP derivados de respostas do
      CA Single Sign-on
      podem ser usados para determinar como rotear uma solicitação.
    • Cookie
      Especifica que a existência ou o valor de um cookie deve ser usada para determinar como rotear uma solicitação. Se um valor do cookie for codificado, especifique o esquema de codificação no parâmetro de codificação. Apenas o esquema de codificação base64 é suportado.
  • Casos
    Define um conjunto de valores para as condições que fornecem as informações para determinar o destino de uma solicitação. Por exemplo, se um conjunto de regras do proxy usa a condição de host, os casos incluem os hosts virtuais configurados para o sistema, como home.company.com e banking.company.com.
DTD de regras do proxy
Use o DTD de regras do proxy para configurar as regras do proxy. O arquivo DTD está disponível no seguinte local:
sps_home
\secure-proxy\proxy-engine\conf\dtd
Os seguintes elementos são configuráveis em DTD:
  • nete:proxyrules
  • nete:description
  • nete:case
  • nete:cond
  • nete:default
  • nete:forward
  • nete:redirect
  • nete:local
  • nete:xprcond
nete proxyrules
O nete:proxyrules é o elemento raiz obrigatório no proxyrules.xml e tem a seguinte sintaxe:
<!ELEMENT nete:proxyrules (nete:description?,(nete:cond | nete:forward | nete:redirect | nete:local)) >
É possível definir um elemento opcional nete:description e um dos seguintes elementos:
  • nete:cond
  • nete:xprcond
  • nete:forward
  • nete:redirect
  • nete:local
Atributo de depuração
O atributo de depuração permite gerenciar o registro em log e depurar as regras do proxy. Ele tem a seguinte sintaxe:
<ATTLIST nete:proxyrules debug (yes|no) "no"
Defina o valor como Sim para permitir o registro. O local do arquivo de log é determinado pelo parâmetro TraceFileName no objeto de configuração do agente que você configurou para
CA Access Gateway
. O parâmetro TraceConfigFile no mesmo objeto de configuração do agente deve apontar para o arquivo de configuração de registro do rastreamento específico do Secure Proxy. Por padrão, o arquivo está localizado em <install-dir>\proxy-engine\conf\defaultagent\SecureProxyTrace.conf.
Por exemplo: <nete:proxyrules xmlns:nete ="http://www.ca.com/" debug ="yes">
nete description
O elemento nete:description é um elemento opcional que contém uma descrição de PCDATA (Parsed Character Data – Dados de Caracteres Analisados) de outro elemento.
PCDATA é qualquer texto que não seja o texto de marcação.
Ele tem a seguinte sintaxe:
<!ELEMENT nete:description (#PCDATA)>
Pode ser um filho do elemento nete:proxyrules e pode conter qualquer descrição.
nete case
O elemento nete:case define o destino associado a um valor específico para uma condição definida no elemento nete:cond pai.  O
CA Access Gateway
usa o valor do elemento nete:case para avaliar um caso.
Ele tem a seguinte sintaxe:
<!ELEMENT nete:case (nete:cond | nete:xprcond | nete:forward | nete:redirect | nete:local)>
Todos os elementos de nete:case devem conter um dos seguintes elementos filho:
  • nete:cond
    Permite que você aninhe várias condições em um conjunto de regras do proxy.
  • nete:xprcond
    Permite que você aninhe uma condição de expressão regular em um conjunto de outras condições.
  • nete:forward
    Fornece um destino para o qual as solicitações que satisfazem a comparação nete:case serão encaminhadas.
  • nete:redirect
    Fornece um destino para o qual as solicitações que satisfazem a comparação nete:case serão redirecionadas. Uma vez redirecionadas, solicitações são processadas diretamente pelo servidor de destino, em vez de ser por meio do
    CA Access Gateway
    .
No exemplo a seguir, um elemento nete:cond especifica a correspondência de URI, e os elementos nete:case demonstram possíveis usos do atributo de tipo de comparação.
 
<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>
Os elementos de <nete:forward>URL</nete:forward> devem estar localizados na mesma linha. No exemplo, as marcas de fechamento </nete:forward>, às vezes, são exibidas em uma linha separada devido a restrições de espaço, no entanto, uma quebra de linha em um arquivo de regras do proxy real causa um erro. O
CA Access Gateway
interpreta as quebras de linha antes da marca de fechamento </nete:forward> como caracteres que fazem parte do URL contido no elemento nete:forward.
Encaminhar e redirecionar sintaxe
Quando encaminhar ou redirecionar uma solicitação, o
CA Access Gateway
usa um sistema para manter alguma parte ou todo o URI especificado por um usuário. O URI aponta para um recurso que reside em um servidor de destino e deve ser interpretado para processar uma solicitação.
Qualquer uma das seguintes ações podem ser anexadas ao URL especificado em um destino para encaminhamento ou redirecionamento:
nete cond
O elemento nete:cond especifica uma condição é avaliada para determinar como as solicitações de entrada são tratadas. Você deve incluir um atributo que deve ser avaliado.
Ele tem a seguinte sintaxe:
<!ELEMENT nete:cond (nete:case+,nete:default)>
É possível definir os seguintes atributos:
<!ATTLIST nete:cond type (header | host | uri | query | cookie) #REQUIRED criteria (equals | beginswith | endswith | contains | exists) "equals" headername CDATA #IMPLIED>
  • cabeçalho
    Especifica que um cabeçalho HTTP é usado para determinar o destino de uma solicitação. Você também deve definir um nome de cabeçalho. Condições que usam cabeçalhos como a comparação requerem um argumento adicional de headername="value", em que o valor é o nome do HTTP ou cabeçalho do
    CA Single Sign-on
    .
    Cabeçalhos HTTP gerados pelas respostas do
    CA Single Sign-on
    podem ser especificados nos elementos nete:cond.
    Por exemplo:
    <nete:cond type="header" headername="USER_AGENT">
    Esse elemento indica que um cabeçalho é usado, e esse USER_AGENT é o cabeçalho a ser avaliado.
  • host
    Especifica um nome de host em implantações em que vários hosts virtuais são usados. Números de porta são considerados parte do host, para que você possa usar os critérios de termina com, descritos mais adiante, em conjunto com a condição de host para rotear solicitações pelo número da porta.
  • query
    Especifica a parte de sequência de caracteres de consulta do URI que segue o '?' caractere. Isso é semelhante a um nete:cond que utiliza o URI da seguinte maneira:
    • URI
      Especifica o indicador de recurso universal que é a parte de um URL solicitado que vem após o nome do servidor. Você pode usar os critérios de termina com em conjunto com a condição do URI para rotear solicitações por extensão de arquivo.
    • cookie
      Especifica um atributo de cookie para determinar como rotear uma solicitação. Se um valor do cookie for codificado, especifique o esquema de codificação no parâmetro de codificação. Apenas o esquema de codificação base64 é suportado e não há suporte para a criação de cookie. Estes são os possíveis casos de um cookie codificado:
      • Se um cookie for codificado usando base64, especifique o valor do cookie no atributo de valor e base64 como o parâmetro de codificação no elemento nete:case. O algoritmo de codificação base64 é usado para decodificar o valor do cookie recebido de um httprequest e o resultado do valor decodificado é comparado com o valor especificado no atributo de valor.
      • Se um cookie não for codificado, digite o valor do cookie em texto sem formatação no atributo de valor e você poderá especificar o parâmetro de codificação como em branco no elemento nete:case. O texto sem formatação especificado é aceito como valor do cookie e o nete:cond será verificado.
      • Se um cookie for codificado usando um esquema de codificação diferente, digite o valor do cookie codificado no atributo de valor e especifique o parâmetro de codificação como em branco no elemento nete:case. O valor do cookie codificado especificado é aceito como texto sem formatação e o valor do cookie de texto sem formatação é usado para verificar o nete:cond
    Um dos atributos do tipo descritos acima deve ser incluído no elemento nete:cond. Além disso, o elemento nete:cond deve especificar um critério que define a comparação que o mecanismo de proxy executa no valor da condição para uma solicitação de entrada. Critérios possíveis são:
  • igual a
    Indica que o valor do atributo de tipo do elemento pai nete:cond deve ser igual ao conteúdo do atributo de valor do elemento nete:case para atuar em uma solicitação.
    Se nenhum critério for especificado, igualdade é suposta nos critérios padrão.
  • beginswith
    Indica que o valor do atributo de tipo do elemento pai nete:cond deve começar com o conteúdo do atributo de valor do elemento nete:case para atuar em uma solicitação.
  • endswith
    Indica que o valor do atributo de tipo do elemento pai nete:cond deve terminar com o conteúdo do atributo de valor do elemento nete:case para atuar em uma solicitação.
  • contém
    Indica que o valor do atributo de tipo do elemento pai nete:cond deve conter o conteúdo do atributo de valor do elemento nete:case para atuar em uma solicitação.
  • existe
    Indica que o elemento pai nete:cond deve existir e o atributo de valor do elemento nete:case deve ser verdadeiro para atuar em uma solicitação. Você pode usar os critérios existentes com os atributos de cabeçalho e cookie apenas.
Cada elemento nete:cond deve ter um ou mais elementos filho de nete:case. Os filhos nete:case fornecem os valores exclusivos que são usados para rotear solicitações para destinos apropriados.
nete default
A definição do elemento nete:default é:
<!ELEMENT nete:default (nete:cond | nete:xprcond | nete:forward | nete:redirect | nete:local)>
Esse elemento é obrigatório e deve ser um elemento filho de cada elemento nete:cond. Se uma solicitação não estiver de acordo com os requisitos de quaisquer elementos de nete:case contidos nos elementos nete:cond, o elemento nete:default determina como manipular a solicitação.
Os elementos filho possíveis associados ao elemento nete:default são idênticos aos elementos disponíveis para um elemento nete:case. Se você criar elementos nete:cond como filhos para um nete:default, tenha cuidado para levar em conta um caso padrão, já que todas as solicitações de cliente possíveis podem ser tratadas pelo
CA Access Gateway
.
No exemplo a seguir, o elemento nete:default encaminha todas as solicitações que não atenderem aos critérios de quaisquer outras regras do proxy para uma página inicial de informações gerais.
<nete:default> <nete:forward>http://home.company.com/index.html </nete:forward> </nete:default>
As marcas de abertura e fechamento, elementos <nete:forward>
URL
</nete:forward>, devem estar localizadas na mesma linha. No exemplo, as marcas de fechamento </nete:forward>, às vezes, são exibidas em uma linha separada devido a restrições de espaço, no entanto, uma quebra de linha em um arquivo de regras do proxy real causa um erro. O
CA Access Gateway
interpreta as quebras de linha antes da marca de fechamento </nete:forward> como caracteres que fazem parte do URL contido no elemento nete:forward.
nete forward
A definição do elemento nete:forward é:
<!ELEMENT nete:forward (#PCDATA)>
O elemento nete:forward encaminha uma solicitação para um URL especificado.
Observação:
as marcas <nete:forward> e </nete:forward> devem estar localizadas em uma única linha no arquivo de regras do proxy. Se não estiverem localizadas na mesma linha, o
CA Access Gateway
interpreta as quebras de linha como parte do URL contido no elemento. Isso faz com que o serviço de encaminhamento falhe.
No exemplo a seguir, o elemento nete:forward encaminha as solicitações enquanto mantém o URI solicitado pelo usuário.
Se a solicitação do usuário atender aos critérios do elemento pai nete:case, essa solicitação é encaminhada para página inicial.empresa.com. Portanto, uma solicitação para http://servidor.empresa.com/hr/benefícios/índice.html encaminhada pelo elemento nete:forward anterior será processada pelo encaminhamento da solicitação para http://página inicial.empresa.com/hr/benefícios/índice.html.
Se você deseja enviar uma solicitação por meio de SSL, certifique-se de usar https em vez de http ao definir o destino contido no elemento <nete:forward>.
O elemento nete:forward contém o seguinte atributo:
<!ATTLIST nete:forward filter CDATA #IMPLIED>
Esse atributo permite que você especifique o nome de uma classe de filtro de Java que pode ser chamada durante um encaminhamento do
CA Access Gateway
a um servidor de destino. Os filtros podem ser escritos usando a API do filtro.
Atributo de filtro
O elemento nete:forward contém o seguinte atributo:
<!ATTLIST nete:forward filter CDATA #IMPLIED>
Esse atributo permite que você especifique o nome de uma classe de filtro de java que pode ser chamada durante um encaminhamento do
CA Access Gateway
a um servidor de destino. Os filtros podem ser escritos de acordo com a API do filtro.
nete redirect
A definição do elemento nete:redirect é:
<!ELEMENT nete:redirect (#PCDATA)>
O elemento nete:redirect especifica uma resposta que é retornada para um usuário que redireciona a solicitação do usuário para um servidor de destino apropriado. O PCDATA segue o padrão de encaminhar e redirecionar sintaxe. Uma vez redirecionado, o
CA Access Gateway
não lida com a conclusão da solicitação. Em vez disso, a solicitação é manipulada pelo servidor que é destino do redirecionamento.
As marcas <nete:redirect> e </nete:redirect> devem estar localizadas em uma única linha no arquivo de regras do proxy. Se não estiverem localizadas na mesma linha, o
CA Access Gateway
interpreta as quebras de linha como parte do URL contido no elemento. Isso faz com que o serviço de redirecionamento falhe.
No exemplo a seguir, o elemento nete:redirect redireciona as solicitações, mantendo o URI solicitado pelo usuário. Ao contrário de um elemento nete:forward, uma vez que a solicitação foi redirecionada, o
CA Access Gateway
é removido da transação, e o servidor de destino fornece recursos diretamente para o usuário.
Se a solicitação de um usuário para http://www.empresa.com/hr/índice.html atender aos critérios do elemento pai nete:case e for redirecionada pelo exemplo acima, o usuário será redirecionado e o navegador do usuário exibirá o URL do servidor de destino que realiza a solicitação:
Se você deseja redirecionar uma solicitação por meio de SSL, certifique-se usar o https em vez de http ao definir o destino contido no elemento <nete:redirect>.
nete local
O elemento nete:local é incluído para oferecer suporte à funcionalidade futura e não deve ser incluído em arquivos de configuração das regras do proxy.
nete xprcond
O elemento nete:xprcond pode ser usado como um elemento nete:cond em situações em que você deseja aplicar as expressões regulares como condições nas regras do proxy. Expressões regulares podem ser usadas para avaliar a sequência de caracteres URI e qualquer sequência de caracteres de consulta anexada em suas regras do proxy.
A definição do elemento nete:xprcond é:
<!ELEMENT nete:xprcond (nete:xpr+, nete:xpr-default)>
Esse elemento deve conter um ou mais elementos nete:xpr e um único elemento nete:xpr-default.
nete xpr e nete xpr-defaul
Um elemento nete:xpr é semelhante a um elemento nete:cond e contém outros elementos de uma regra baseada em uma expressão regular, bem como um comportamento resultante quando o
CA Access Gateway
detectar uma correspondência para a expressão. Um elemento nete:xpr-defaul contém o comportamento padrão de URI ou combinações de sequência de caracteres de consulta que não correspondem a nenhuma das expressões regulares contidas nos elementos nete:xpr dentro de um elemento nete:xprcond.
A definição de um elemento nete:xpr é:
<!ELEMENT nete:xpr (nete:rule, nete:result)>
Um elemento nete:xpr contém um elemento nete:rule que define uma expressão regular e um elemento nete:result que especifica o comportamento de sequências de caracteres que corresponde à expressão regular.
A definição de um elemento nete:xpr-default é:
<!ELEMENT nete:xpr-default (nete:forward|nete:redirect|nete:local)>
O elemento nete:xpr-defaul especifica um encaminhamento ou redirecionamento que deve ser concluído se o URI ou a sequência de caracteres de consulta que está sendo avaliada pelo
CA Access Gateway
não corresponder às condições mencionadas em qualquer um dos elementos nete:xpr contidos no elemento nete:xprcond pai.
nete rule e nete result
Os elementos nete:rule e nete:result devem estar contidos em um elemento nete:xpr. O elemento nete:rule especifica a expressão regular que o
CA Access Gateway
avalia em relação às solicitações de entrada. O elemento nete:result determina o comportamento para correspondência de solicitações.
A definição do elemento nete:rule é:
<!ELEMENT nete:rule (#PCDATA)>
Esse elemento contém uma sequência de caracteres que é uma expressão regular. O URI e a sequência de caracteres de consulta de uma solicitação são correspondidos com essa expressão regular para determinar se uma solicitação atende à condição nete:xpr.
A definição do elemento nete:result é:
<!ELEMENT nete:result (#PCDATA)>
elementos nete:result podem ter os seguintes atributos:
<!ATTLIST nete:result service (forward|redirect) "forward">
Esse elemento contém uma sequência de caracteres que consiste na sequência de caracteres de substituição (URL) pela qual o
CA Access Gateway
cria um URL para passar para um serviço (encaminhar ou redirecionar). O atributo de serviço é usado para especificar o serviço apropriado que receberá o URL. O serviço padrão é o serviço de avanço definido no arquivo de configuração server.conf.
O URL de substituição no elemento nete:result deve ser um URL que contém, opcionalmente, $#, em que # é 0, 1, 2, etc.
  • $0 é a sequência de caracteres de consulta e URL inteira que está sendo avaliada.
  • $n é a parte do URI solicitado correspondente ao enésimo conjunto de parênteses na expressão regular descrita no elemento nete:rule associado.
Por exemplo, um conjunto de regras do proxy pode conter o seguinte:
 
<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>
As marcas de <nete:result> URL </nete:result> devem estar localizadas em uma única linha no arquivo de regras do proxy. Se eles não estiverem localizados na mesma linha, o
CA Access Gateway
interpreta as quebras de linha como parte do URL contido no elemento. Isso faz com que o serviço de resultado falhe.
No exemplo de regra de proxy nete:xprcond anterior, uma solicitação para:
será encaminhada para:
Tratamento de resposta
O
CA Access Gateway
usa as respostas do
CA Single Sign-on
para determinar um destino para uma solicitação. Como as transações roteadas por meio do
CA Access Gateway
incluem uma interação entre o agente web do
CA Access Gateway
e o
CA Single Sign-on
, quaisquer respostas do
CA Single Sign-on
coletadas durante o processo de autenticação e autorização podem ser usadas pelo
CA Access Gateway
para determinar o destino de uma solicitação.
Por exemplo, se um diretório de usuários contiver informações sobre o tipo de conta para um site de operações bancárias, o
CA Access Gateway
poderá ter usuários de proxy com diferentes tipos de contas para destinos diferentes. Isso permite que uma empresa ofereça uma melhor qualidade de serviço para seus clientes mais importantes. Os clientes com contas padrão podem ser tratados por um conjunto de servidores de destino, enquanto os clientes com contas premium podem ser tratados por um conjunto separado de servidores de destino de alto desempenho.
Como os elementos nete xprcond funcionam
O processamento de um elemento nete:xprcond é semelhante ao processamento de todos os outros elementos nete:cond. Enquanto o
CA Access Gateway
processa solicitações e encontra um elemento nete:xprcond no arquivo de configuração das regras do proxy, ocorre o seguinte:
  1. O
    CA Access Gateway
    examina o primeiro elemento nete:xpr no elemento nete:xprcond.
  2. O mecanismo de proxy avalia a expressão regular descrita no elemento nete:rule com relação à sequência de caracteres de consulta e URI da solicitação.
  3. Se o URI e a sequência de caracteres de consulta solicitada corresponderem à expressão regular especificada no elemento nete:rule, o
    CA Access Gateway
    resolverá a sequência de resultado usando os resultados de correspondência, e a solicitação é encaminhada para o serviço especificado com o URL derivado do elemento nete:result.
  4. Se a sequência de caracteres de consulta e URI não corresponder à expressão regular no elemento nete:xpr primeiro, o mecanismo de regras do proxy avaliará o próximo elemento nete:xpr (repita as etapas 2 e 3). Esse processo continua até que o mecanismo de regras encontre uma correspondência ou atinja o elemento nete:xpr-default.
  5. Se nenhuma correspondência for encontrada antes de atingir o elemento nete:xpr-default, então o conteúdo do elemento nete:xpr-default determina como rotear a solicitação.
Sintaxe de expressão regular
Esta seção descreve a sintaxe que deve ser usada para criar expressões regulares para elementos nete:rule. Um elemento nete:xprcond assume a seguinte forma:
<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>
No elemento nete:xpr, o elemento nete:rule deve consistir em uma expressão regular que usa a sintaxe descrita na tabela a seguir. Essa sintaxe é consistente com a sintaxe de expressão regular suportada pelo Apache e descrita em http://www.apache.org.
Caracteres
Resultados
caractere unicode
Corresponde a qualquer caractere unicode idêntico
\
Usado para cotação de um metacaractere como ’*’)
\\
Corresponde a um único caractere ’\’
\0nnn
Corresponde a um determinado caractere octal
\xhh
Corresponde a um determinado caractere hexadecimal de 8 bits
\\uhhhh
Corresponde a um determinado caractere hexadecimal de 16 bits
\t
Corresponde a um caractere de tabulação ASCII
\n
Corresponde a um caractere de nova linha ASCII
\r
Corresponde a um caractere de retorno ASCII
\f
Corresponde a um caractere feed de formulário ASCII
[abc]
Classe de caracteres simples
[a-zA-Z]
Classe de caracteres com intervalos
[^abc]
Classe de caracteres negada
[:alnum:]
Caracteres alfanuméricos
[:alpha:]
Caracteres alfabéticos
[:blank:]
Caracteres de espaço e guia
[:cntrl:]
Caracteres de controle
[:digit:]
Caracteres numéricos
[:graph:]
Caracteres imprimíveis e também são visíveis (um espaço pode ser impresso, mas não fica visível, enquanto um 'a' é ambos)
[:lower:]
Caracteres alfabéticos minúsculos
[:print:]
Caracteres imprimíveis (caracteres que não são caracteres de controle)
[:punct:]
Caracteres de pontuação (caracteres que não letras, dígitos, caracteres de controle ou caracteres de espaço)
[:space:]
Caracteres de espaço (como espaço, tabulação e formfeed)
[:upper:]
Caracteres alfabéticos maiúsculos
[:xdigit:]
Caracteres que são dígitos hexadecimais
[:javastart:]
Início de um identificador de Java
[:javapart:]
Parte de um identificador de Java
.
Corresponde a qualquer caractere, exceto nova linha
\w
Corresponde a um caractere de "palavra" (alfanumérico mais "_")
\W
Corresponde a um único caractere sem formar palavra
\s
Corresponde a um caractere de espaço em branco
\S
Corresponde a um caractere diferente de espaço
\d
Corresponde a um caractere de dígito
\D
Corresponde a um caractere diferente de dígito
^
Corresponde somente no início de uma linha
$
Corresponde somente no final de uma linha
\b
Corresponde somente no limite de uma palavra
\B
Corresponde somente em um limite de não-palavra
A*
Corresponde a A 0 ou mais vezes (greedy)
A+
Corresponde a A 1 ou mais vezes (greedy)
A?
Corresponde a A 1 ou 0 vez (greedy)
A{n}
Corresponde a A um exatamente n vezes (greedy)
A{n,}
Corresponde a A ao menos n vezes (greedy)
A{n,m}
Corresponde a A ao menos n, mas não mais que m vezes (greedy)
A*?
Corresponde a A 0 ou mais vezes (reluctant)
A+?
Corresponde a A 1 ou mais vezes (reluctant)
A??
Corresponde a A 0 ou 1 vez (reluctant)
AB
Corresponde a A seguido por B
A|B
Corresponde a A ou B
(A)
Usado para agrupamento de subexpressão
\1
Referência inversa à primeira subexpressão entre parênteses
\n
Referência inversa à n subexpressão entre parênteses
Todos os operadores de fechamento (+, *, ?, {m,n}) são greedy por padrão, o que significa que eles correspondem ao maior número de elementos da sequência de caracteres que for possível sem fazer com que a correspondência geral falhe. Se desejar que um fechamento seja reluctant (não greedy), poderá simplesmente adicionar um ’?’. Um fechamento reluctant corresponderá ao menor número de elementos da sequência de caracteres que for possível quando encontrar correspondências. encerramentos {m,n} atualmente não suportam relutância.
Exemplos de expressão regular na regra nete e resultado nete
Expressões regulares para oferecer uma ferramenta muito flexível e poderosa que pode ser utilizada em regras do proxy do
CA Access Gateway
. Esta seção fornece alguns exemplos de elementos nete:rule em regras do proxy. Além disso, os exemplos também contêm vários usos do elemento nete:result para mostrar como agrupamentos em um nete:rule podem ser usados para afetar o destino gerado pelos filhos de um elemento nete:xprcond.
Mapear a única regra para vários servidores de destino
No exemplo a seguir, um elemento nete:rule contém uma expressão regular que pode ser usada para encaminhar as solicitações para diferentes destinos. Este exemplo pressupõe que o
CA Access Gateway
receberá URIs que têm o seguinte formato:
/GOTO=
algum caminho e/ou nome de arquivo
Considere que um elemento nete:xprcond contém os seguintes elementos filho:
<nete:xpr> <nete:rule>/GOTO=(.*)/(.*)</nete:rule> <nete:result>http://$1/$2</nete:result> </nete:xpr>
A expressão regular no elemento nete:rule e o elemento associado nete:result correspondem a URIs que geram um /GOTO=string. Ao encontrar uma correspondência, o
CA Access Gateway
usa a primeira sequência de caracteres após o símbolo = no URI como o valor de US $1 do resultado e o valor após o primeiro símbolo / que aparece após o símbolo = como o resultado de US $2. O elemento nete:result combina esses elementos para criar um URL. Por padrão, elementos nete:result usam o serviço de encaminhamento do
CA Access Gateway
.
Por exemplo, se o URI de uma solicitação avaliada pelo elemento nete:xpr descrito acima fosse da seguinte maneira:
Então, a expressão regular no elemento nete:rule encontraria uma correspondência e atribuiria o valor de US$ 1 como servidor1.empresa.com e o valor de US$ 2 como índice.html. O elemento nete:result reúne esses valores para o seguinte URL:
Esse URL é o destino que o
CA Access Gateway
usa para resolver a solicitação.
Expressões regulares para redirecionar usuários
O elemento nete:result também pode ser usado para criar uma resposta de redirecionamento que é retornada ao usuário que está solicitando o recurso. Isso faz com que o processamento de uma solicitação seja tratado por um servidor além do
CA Access Gateway
, após autenticação e autorização. A seguir está um exemplo de um elemento nete:xpr que especifica um redirecionamento no elemento filho nete:result.
<nete:xpr> <nete:rule>/REDIR=(.*)/(.*)</nete:rule> <nete:result service="redirect">http://$1/$2</nete:result> </nete:xpr>
O atributo de serviço instrui o
CA Access Gateway
para usar o serviço de redirecionamento no lugar o serviço de encaminhamento padrão.
Valores de cabeçalho em encaminhamentos, redirecionamentos e filtros de resultados
O valor de um cabeçalho HTTP ou um cabeçalho de resposta do
CA Single Sign-on
pode ser substituído diretamente em um elemento nete:result, nete:redirect ou nete:forward. Quando um URl em um elemento de encaminhamento ou redirecionamento, ou uma regra em um elemento do filtro de resultado contém {{
HEADER_NAME
}}, o mecanismo de proxy procura um cabeçalho de uma solicitação que corresponda ao cabeçalho especificado e ao valor de cabeçalho do substituto antes de resolver o encaminhamento, redirecionamento ou resultado. Se nenhum cabeçalho correspondente for encontrado em uma solicitação, o mecanismo de proxy substituirá uma sequência de caracteres vazia no lugar do valor do cabeçalho.
Os nomes de cabeçalho diferenciam maiúsculas de minúsculas.
Valor de cabeçalho dinâmico em um encaminhamento de nete
Para usar um valor de cabeçalho dinâmico como parte de um elemento nete:forward, simplesmente insira
{{HEADER_NAME
}} na parte do URL do encaminhamento. Por exemplo:
É possível usar vários cabeçalhos em um único elemento nete:forward. Por exemplo:
Valor de cabeçalho dinâmico em um redirecionamento nete
Para usar um valor de cabeçalho dinâmico como parte de um elemento nete:redirect, simplesmente insira
{{HEADER_NAME
}} na parte do URL do redirecionamento. Por exemplo:
É possível usar vários cabeçalhos em um elemento único nete:redirect. Por exemplo:
Valor de cabeçalho dinâmico em um resultado nete
Para usar um valor de cabeçalho dinâmico como parte de um elemento nete:result, basta inserir
{{HEADER_NAME
}} na parte do URL do resultado. Por exemplo:
Você pode usar outros recursos de regras do proxy, tais como filtros, em conjunto com um valor de cabeçalho dinâmico. Por exemplo:
<nete:result filter="filter1">http://$1/$2?{{HEADER_NAME}}</nete:result>
Tratamento de resposta
O
CA Access Gateway
usa as respostas do
CA Single Sign-on
para determinar um destino para uma solicitação. Como as transações roteadas por meio do
CA Access Gateway
incluem uma interação entre o agente web do
CA Access Gateway
e o
CA Single Sign-on
, quaisquer respostas do
CA Single Sign-on
coletadas durante o processo de autenticação e autorização podem ser usadas pelo
CA Access Gateway
para determinar o destino de uma solicitação.
Por exemplo, se um diretório de usuários contiver informações sobre o tipo de conta para um site de operações bancárias, o
CA Access Gateway
poderá ter usuários de proxy com diferentes tipos de contas para destinos diferentes. Isso permite que uma empresa ofereça uma melhor qualidade de serviço para seus clientes mais importantes. Os clientes com contas padrão podem ser tratados por um conjunto de servidores de destino, enquanto os clientes com contas premium podem ser tratados por um conjunto separado de servidores de destino de alto desempenho.
Gerenciar as regras do proxy
Para gerenciar regras do proxy, execute uma das seguintes etapas:
  • Importe o arquivo proxyrules.xml e edite as regras do proxy, se necessário, executando as seguintes etapas:
    1. Vá até regras do proxy, regras.
    2. Clique em Import.
    3. Clique em Procurar para selecionar o local do arquivo e clique em Fazer upload.
    4. Você pode exibir as regras do proxy importadas em modo de árvore ou em modo de texto.
    5. (Opcional) Edite as regras do proxy e clique em Salvar.
    6. (Opcional) Edite as regras do proxy existentes em um modo de árvore ou em modo de texto.
  • Edite as regras do proxy existentes em um modo de árvore ou em um modo de texto, executando as etapas a seguir:
    1. Vá até regras do proxy, regras.
    2. Clique em Modo de texto.
    3. Edite as regras do proxy necessárias para o seu ambiente.
    4. Clique em Salvar.
Adicionar filtros
Filtros personalizados são filtros definidos pelas necessidades do cliente.  O
CA Access Gateway
usa filtros personalizados para manipular uma solicitação antes de encaminhá-la para um servidor de back-end, bem como para manipular as respostas enviadas pelo servidor de back-end para o cliente do usuário.
Para adicionar filtros em proxyrules.xml ou modo de texto na interface administrativa, digite o filtro necessário nas regras do proxy.
Exemplo
:
<nete:forward filter="filter1"http://FQDN$0</nete:forward>
Para adicionar filtros em modo de árvore na interface administrativa, execute as seguintes etapas:
  1. Clique em Regras do proxy, Filtros.
  2. Clique em Adicionar.
  3. Digite o nome do filtro e o nome da classe Java em Nome e Classe.
  4. (Opcional) Para adicionar parâmetros de filtro, clique em Adicionar na tabela Parâmetros e digite os detalhes.
  5. Clique em OK.
Para aplicar um filtro no modo de árvore na interface administrativa, digite o nome do filtro a ser aplicado quando você criar uma regra do proxy de ação.
Validar as regras do proxy
É possível validar as novas regras do proxy em relação ao DTD de regras do proxy. A validação assegura que as novas regras do proxy serão definidas nas configurações corretas do arquivo XML conforme o DTD.
Para validar as novas regras do proxy, clique em Validar na página Regras do proxy em qualquer modo depois de salvar as regras do proxy.
Testar as regras do proxy
Você pode testar as regras do proxy para verificar sua funcionalidade.
Siga estas etapas:
  1. Clique em Regras do proxy, Teste de regras do proxy.
  2. Digite uma solicitação de teste de amostra de acordo com as regras do proxy definidas.
  3. Clique em Testar as regras do proxy.
  4. Verifique se os resultados exibidos em Resultado estão de acordo com as regras do proxy definidas.
Exportar as regras do proxy
É possível exportar as novas regras do proxy por meio da interface administrativa para referência futura.
Siga estas etapas:
  1. Clique em Exportar de qualquer modo.
  2. Clique em Salvar na caixa de diálogo Download de arquivos e especifique o local para salvar o arquivo proxyrules.xml.
  3. Clique em OK.
Arquivos de configuração das regras de proxy de amostra
O
CA Access Gateway
instala vários exemplos de arquivos de configuração das regras do proxy. Você pode usar esses arquivos XML de exemplo como base para seus próprios arquivos de regras do proxy.
Você pode encontrar esses arquivos de exemplo no diretório
sps_home
\secure-proxy\proxy-engine\examples\proxyrules. Recomendamos que você examine o arquivo de exemplo enquanto você está lendo as descrições neste guia.
Você pode copiar e personalizar um arquivo para atender às suas necessidades.
Para personalizar e implantar um arquivo de regras do proxy
  1. Navegue até o diretório
    sps_home
    \secure-proxy\proxy-engine\examples\proxyrules.
  2. Faça uma cópia do arquivo de exemplo que deseja usar.
  3. Personalize o conteúdo e salve o novo arquivo com um nome exclusivo.
  4. Copie o arquivo modificado para o diretório
    sps_home
    /secure-proxy/proxy-engine/conf.
  5. Abra o arquivo server.conf para modificar a seção de regras do proxy do arquivo para apontar para o arquivo personalizado.
Exemplo de regras do proxy - Encaminhando solicitações por host virtual
O arquivo de exemplo proxyrules_example1.xml encaminha solicitações de acordo com o nome do host especificado na solicitação. O arquivo de exemplo proxyrules_example10.xml também encaminha solicitações do
CA Access Gateway
de acordo com o nome do host especificado na solicitação, o
CA Access Gateway
usa o PID na regra de proxy para contar o número de vezes que a regra de proxy foi acionada. Se você configurou o CA Wily Introscope para monitorar o
CA Access Gateway
, a contagem é exibida nas métricas de dados do CA Wily Introscope.
Nesse arquivo, um conjunto de regras do proxy simples encaminha solicitações de usuário com base em host virtual especificado no recurso solicitado. Todas as solicitações para o servidor empresa.bondtrading.com são encaminhadas para o servidor2, todas as solicitações para empresa.bancária.com são encaminhadas para o Servidor1 e todas as outras solicitações são encaminhadas para o servidor inicial das empresas, que é o padrão para solicitações que não correspondem aos critérios em qualquer outro elemento nete:cond.
Os elementos nete:case devem especificar uma porta, já que o número da porta é considerado como parte do host virtual solicitado pelo usuário. Use os critérios beginswith para evitar que precisam de números de porta.
URL solicitado
URL encaminhado
 
Exemplo de regras do proxy - Encaminhando solicitações por valor de cabeçalho
O arquivo de exemplo proxyrules_example2.xml encaminha solicitações do
CA Access Gateway
de acordo com o valor de um cabeçalho HTTP. O cabeçalho HTTP pode ser um cabeçalho padrão ou um criado usando uma resposta do
CA Single Sign-on
.
Neste exemplo, suponha que o 
CA Access Gateway
 encaminha solicitações feitas para um host padrão virtual de www.empresa.com.
Nesse arquivo, o valor da variável de cabeçalho HTTP "HEADER" determina o destino da solicitação.
A tabela a seguir ilustra os resultados de solicitações usando as regras do proxy com base em um cabeçalho HTTP.
URL solicitado
URL encaminhado
http://www.company.com/index.html
HTTP_HEADER tem o seguinte valor:
HTTP_HEADER="value1"
http://www.company.com/index.html
HTTP_HEADER tem o seguinte valor:
HTTP_HEADER="value2"
http://www.company.com/index.html
HTTP_HEADER tem um valor diferente de value1 ou value2.
Não é necessário incluir o HTTP_ do nome da variável de cabeçalho no elemento nete:cond. O
CA Access Gateway
assumes HTTP_ para nomes de variáveis de cabeçalho.
Regras do proxy que usam os valores de cabeçalho são uma excelente maneira para encaminhar as solicitações com base em um nível de serviço desejado. Por exemplo, você pode usar o valor de uma variável de cabeçalho HTTP que contém tipos de conta de um usuário para distribuir solicitações para servidores de alto desempenho dos clientes com contas premium.
Exemplo de regras do proxy - Encaminhando solicitações por tipo de dispositivo
O arquivo de exemplo proxyrules_example3.xml encaminha solicitações do
CA Access Gateway
de acordo com o tipo de dispositivo usado para acessar o recurso.
O valor do cabeçalho HTTP de agente de usuário é usado para determinar como rotear solicitações.
No arquivo, os usuários que acessam os recursos usando um navegador (agente de usuário contém Mozilla para navegadores da web) são encaminhados para um servidor web, enquanto todos os outros usuários são encaminhados para um servidor sem fio.
A tabela a seguir ilustra os resultados de solicitações usando as regras do proxy com base em um tipo de dispositivo.
URL solicitado
URL encaminhado
http://www.company.com/index.html
Recurso de acesso do usuário por meio de um navegador da web.
http://www.company.com/index.wml
Recurso de acesso do usuário por meio de um dispositivo sem fio.
 
Exemplo de regras do proxy - Encaminhando solicitações com URIs
O arquivo de exemplo proxyrules_example4.xml encaminha solicitações do
CA Access Gateway
de acordo com o URI especificado na solicitação do usuário.
A tabela a seguir ilustra os resultados de solicitações usando as regras do proxy com base em URIs.
URL solicitado
URL encaminhado
 
Exemplo de regras do proxy - Encaminhando solicitações por extensão de arquivo
O arquivo de exemplo proxyrules_example5.xml encaminha solicitações do
CA Access Gateway
de acordo com a extensão do arquivo solicitada pelo usuário. Isso é conseguido usando a condição URI em combinação com os critérios endswith.
No arquivo, as marcas <nete:forward> e </nete:forward> são exibidas em linhas separadas devido a restrições de espaço. No entanto, em seus arquivos de configuração das regras do proxy, as marcas de abertura e fechamento de um elemento <nete:forward> devem aparecer na mesma linha. Caso contrário, o
CA Access Gateway
interpreta a quebra de linha como parte do URL de encaminhamento, o que faz com que as solicitações sejam encaminhadas incorretamente.
No exemplo anterior, os usuários que acessam os recursos .jsp são encaminhados para um servidor de aplicativos, enquanto os usuários sem fio são encaminhados para o servidor sem fio. Todos os outros usuários são encaminhados para o servidor inicial.
A tabela a seguir ilustra os resultados de solicitações usando as regras do proxy com base nas extensões de arquivo.
URL solicitado
URL encaminhado
 
Exemplo de regras do proxy - Encaminhando solicitações com condições aninhadas
O arquivo de exemplo proxyrules_example6.xml encaminha solicitações do
CA Access Gateway
de acordo com o nome de host, determinados cabeçalhos e os tipos de dispositivos. Este arquivo demonstra como o
CA Access Gateway
pode lidar com relacionamentos complexos em um único arquivo de configuração.
No arquivo, os elementos de <nete:forward>
URL
</nete:forward> devem estar localizados na mesma linha. No exemplo, as marcas de fechamento </nete:forward>, às vezes, são exibidas em uma linha separada devido a restrições de espaço, no entanto, uma quebra de linha em um arquivo de regras do proxy real causa um erro. O
CA Access Gateway
interpreta as quebras de linha antes da marca de fechamento </nete:forward> como caracteres que fazem parte do URL contido no elemento nete:forward.
A tabela a seguir ilustra os resultados de solicitações usando regras do proxy com condições aninhadas.
URL solicitado
URL encaminhado
http://bondtrading.company.com/index.html
com um valor de cabeçalho de GOLD_USER ="yes"
http://bondtrading.company.com/index.html
com um valor de cabeçalho de GOLD_USER ="no"
http://www.company.com/index.wml
com um valor de cabeçalho USER_AGENT que contém um nome de dispositivo sem fio
http://home.company.com/
wireless/index.wml
http://www.company.com/index.html
com um valor de cabeçalho USER_AGENT que não contém um nome de dispositivo sem fio
 
Exemplo de regras do proxy -- Usando expressão regular nas regras do proxy
O arquivo de exemplo proxyrules_example7.xml encaminha solicitações do
CA Access Gateway
com base em elementos nete:xprcond que contêm expressões regulares. Expressões regulares são avaliadas com base na sequência de caracteres de consulta e URI de uma solicitação.
No arquivo, a sequência de caracteres de consulta e URI da solicitação é avaliada em relação as três expressões regulares definidas nos elementos nete:xpr. Se uma correspondência não for encontrada com o primeiro elemento nete:xpr, o
CA Access Gateway
tenta corresponder com a segunda e, finalmente, com a terceira expressão regular. Se nenhuma correspondência for encontrada, a condição nete:xpr-default será usada para processar a solicitação.
A tabela a seguir lista os resultados de solicitações usando as regras do proxy de expressão regular.
URL solicitado
URL encaminhado
http://server2.company.com/index.html
O usuário é redirecionado para que
server2.company.com deva processar diretamente a solicitação do usuário.
 
Exemplo de regras do proxy - Encaminhando solicitações pela existência de cookie
O arquivo de exemplo proxyrules_example8.xml encaminha solicitações do
CA Access Gateway
de acordo com a existência de um cookie.
Neste exemplo, se uma solicitação tiver um cabeçalho de cookie "mycookie", o 
CA Access Gateway
encaminha a solicitação para www.empresa.com.
Exemplo de regras do proxy - Encaminhando solicitações pelo valor do cookie
O arquivo de exemplo proxyrules_example9.xml encaminha solicitações do
CA Access Gateway
de acordo com o valor de um cookie.
Neste exemplo, se uma solicitação tiver um cabeçalho de cookie "mycookie" e ela não especificar o mecanismo de codificação, o 
CA Access Gateway
 encaminha a solicitação para www.abcd.com. Se uma solicitação tiver um cabeçalho de cookie "mycookie" e o mecanismo de codificação base64, o
CA Access Gateway
encaminha a solicitação para www.xyz.com.