Ajax em uma rede: Os desafios de segurança e topologia para agregar conteúdo de múltiplos sites em uma arquitetura Ajax

Usando o WebSphere Application Server Feature Pack para Web 2.0 e o Tivoli Access Manager WebSEAL

A introdução de técnicas de programação Asynchronous JavaScript™ and XML (Ajax) em um ambiente de rede pode ser bastante desafiadora. O artigo examina os cenários de segurança e topologia que possivelmente podem ser encontrados ao criar arquiteturas no estilo Ajax que agregam conteúdo de múltiplos sites. Este artigo explora esses cenários usando o produto IBM® Tivoli® Access Manager WebSEAL juntamente com o IBM WebSphere® Application Server Feature Pack para Web 2.0 para o desenvolvimento de arquiteturas no estilo Ajax para o WebSphere Application Server. Este conteúdo é parte do IBM WebSphere Developer Technical Journal.

Kevin Haverlock, Software Development, IBM

Author photoKevin Haverlock é arquiteto e desenvolvedor do produto WebSphere Application Server da IBM e atualmente faz parte da equipe do feature pack para Web 2.0.


nível de autor Contribuidor do
        developerWorks

Peter Tuton, Software Engineer, IBM

Peter TutonPeter Tuton é um Engenheiro de Software no Tivoli Security Integration Factory Team com base em Gold Coast, Austrália. Nesta função, Peter é o Technical Lead para a equipe desenvolvendo soluções de integração para o Tivoli Access Manager e o Tivoli Federated Identity Manager. Peter participou na certificação de várias soluções de integração IBM com as principais empresas de software, incluindo a Siebel, PeopleSoft e SAP.



Grant Murphy, Software Engineer, IBM Australia

Grant MurphyGrant Murphy é um Engenheiro de Software baseado na Gold Coast, Austrália. A função atual de Grant é desenvolvedor no Global Security Toolkit da IBM.



09/Nov/2009

Introdução

Um recurso interessante de uma arquitetura Ajax é a capacidade de agregar conteúdo de múltiplas fontes de dados para criar um site ou aplicativo da Web inteiramente novo. Como exemplo, você pode criar um aplicativo da Web que combina informações sobre resorts de esqui com informações sobre o tempo, que estão disponíveis em vários serviços climáticos. As informações estão disponíveis em vários sites da Web, mas o seu aplicativo junta esses dados em uma página da Web. Esses tipos de aplicativos são muitas vezes denominados de mashups e não é necessário ir muito além do Google ou Yahoo para ver as possibilidades inovadoras da criação de aplicativos da Web deste tipo.

A criação de uma topologia de rede para suportar agregação de conteúdo de múltiplos sites apresenta diversos desafios técnicos. Os desafios incluem tratar restrições entre domínios do navegador, possível expiração de sessão do usuário, esgotamento de tempo limite de conexões persistentes, e possíveis problemas de autenticação e autorização. Este artigo examina os desafios técnicos associados com o Ajax e explora como o IBM WebSphere Application Server Feature Pack para Web 2.0 combinado com o IBM Tivoli Access Manager WebSEAL podem ser usados para resolver esses desafios técnicos.


Topologia Ajax

A Figura 1 mostra uma típica arquitetura no estilo Ajax. Do lado esquerdo há um cliente, como um navegador da Web. No exemplo, o navegador suporta a linguagem de programação JavaScript, que é usada para manipular o Document Object Model (DOM) da página sendo visualizada. As páginas podem conter widgets JavaScript, que executam uma função de GUI. Como exemplo, é possível criar um widget que retira dados do servidor e exibe os conteúdos no navegador. O widget trata a criação e manipulação do DOM que o navegador usa para exibir conteúdo gráfico.

Figura 1. Arquitetura Ajax usando um proxy
Figure 1. Ajax architecture using a proxy

SOAP, ATOM, XML, JSON

Quando um cliente conecta-se a um servidor para permutar dados, há sempre um formato combinado para a interpretação dos dados. SOAP, ATOM, XML e JSON são formatos comuns que os servidores e clientes usarão para permutar informações ao conectar-se. Cada uma dessas tecnologias tem suas vantagens e desvantagens. A decisão sobre qual tecnologia usar na verdade se resume a qual melhor atende às necessidades específicas do aplicativo da Web que está sendo desenvolvido. O Web 2.0 feature pack fornece suporte do lado do servidor e do cliente para esses protocolos para ajudar a tornar o desenvolvimento para Web mais fácil.

No centro da Figura 1 há um proxy de encaminhamento. Um proxy é importante na arquitetura Ajax se é planejado agregar conteúdo de múltiplos serviços da Web ou se é necessário impingir um mecanismo de segurança nos clientes que se conectam à rede. Como exemplo, o Ajax depende muito de XMLHTTPRequests para emitir conexões de rede nos bastidores para recuperar dados. Por projeto, navegadores modernos não permitem XMLHTTPRequests para domínios originados fora da origem do documento. Como exemplo, se o widget de GUI em JavaScript que foi criado originou-se do site http://www.mysite.com, mas emite um XMLHTTPRequest para http://www.mydata.com/data para acessar dados, a solicitação será bloqueada pelo navegador. Ao invés disso, o cliente conecta-se ao proxy, que age como um corretor, intermediando as solicitações dos clientes para outros domínios. Do ponto de vista do cliente, a solicitação parece se originar do mesmo domínio que o documento original. Além de trabalhar com o modelo de segurança do próprio navegador, o proxy pode fornecer uma camada adicional de autenticação e autorização para agir como um ponto de controle para acesso a documentos ou serviços na rede.

Na parte esquerda da Figura 1 existem vários terminais de serviços ou documentos que clientes baseados em navegador podem tentar acessar. Em uma arquitetura Ajax, esses terminais de serviços podem acessar um banco de dados, Barramento de Serviço Corporativo ou outros serviços de backend para retirar informações. As informações retornadas estão num formato que é consumível pelo terminal do cliente. Exemplos típicos incluem SOAP, ATOM, XML ou JSON.


Juntando tudo

O IBM WebSphere Application Server Feature Pack para Web 2.0 é um complemento opcional para o WebSphere Application Server Versões 6.0, 6.1 e 7.0. Adicionalmente, suporta o IBM WebSphere Application Server Community Edition V2.x. O feature pack contém tecnologia do lado do cliente e do servidor que pode ser usada para criar arquiteturas no estilo Ajax. A tecnologia é fornecida no formato de bibliotecas que podem ser incluídas com seu aplicativo da Web. Como um desenvolvedor, você seleciona os pacotes de biblioteca adequados para o aplicativo da Web Ajax que está sendo criado. As listas abaixo resumem os recursos disponíveis no Web 2.0 feature pack.

Lado do cliente

  • O Dojo 1.1 Toolkit é um kit de ferramentas em JavaScript que simplifica a criação de aplicativos Ajax usando JavaScript.
  • IBM Extensions para Dojo
    • Biblioteca JavaScript para tratar conteúdo de alimentação SOAP ou Atom.
    • Widgets Gauge GUI
    • Biblioteca OpenSearch

Lado do servidor

  • Uma biblioteca JSON baseada em Java que é usada para criar dados JSON que são facilmente consumidos por clientes baseados em JavaScript.
  • Bibliotecas de alimentação baseadas em Abdera que podem ser usadas para criar alimentações ATOM.
  • Um proxy Ajax baseado em servlets que pode ser integrado em seu aplicativo.
  • Sistema de mensagens Ajax usado para criar arquiteturas no estilo Comet.

O IBM Tivoli Access Manager WebSEAL é um proxy da Web reverso que recebe solicitações HTTP/HTTPS de um cliente baseado em navegador e entrega conteúdo de seu próprio servidor da Web ou acessa servidores backend de aplicativos da Web como o WebSphere Application Server. As solicitações que passam através do WebSEAL são avaliadas para determinar se o usuário está autorizado para acessar um recurso solicitado. O WebSEAL suporta estes recursos:

  • Arquitetura plugável que suporta vários mecanismos de autenticação.
  • Aceita solicitações HTTP e HTTPS.
  • Protege recursos do servidor backend oferecendo controle de acesso de baixa granularidade para espaço da Web para servidores locais e backend.
  • Executa um proxy da Web reverso.
  • Fornece recursos para conexão única.
  • Tem várias histórias de integração positivas com produtos de software de terceiros.

A Figura 2 mostra um diagrama revisado de topologia e mostra como o Web 2.0 feature pack e o WebSEAL podem ser usados juntamente para fornecer uma solução Ajax baseada na Web. O WebSEAL forma a base da topologia de rede, fornecendo serviços de proxy e segurança, enquanto que o Web 2.0 feature pack fornece as bibliotecas de aplicativos para criar aplicativos da Web no estilo Ajax.

Figura 2. Topologia atualizada usando WebSEAL como proxy
Figure 2. Updated topology using WebSEAL as the proxy

No lado do cliente, o Web 2.0 feature pack fornece o kit de ferramentas JavaScript Dojo 1.1. O Dojo Toolkit é uma solução de software livre que pode ser usada para criar arquiteturas no estilo Ajax. O Dojo Toolkit é agrupado em volta de três componentes:

  • Core consiste de uma biblioteca JavaScript que fornece a estrutura sobre a qual os outros componentes do Dojo são construídos. O suporte de estrutura é fornecido para eventos, empacotamento, consultas baseadas em CSS, animações e tratamento de JSON, entre outros. O Dijit está situado sobre o Core.
  • O Dijit é um conjunto de widgets baseadas em modelos customizáveis que suportam localização e acessibilidade. O Dijit contém um conjunto de widgets bastante abrangente e que podem ser usados sem qualquer adaptação ou customizados de acordo com seus requisitos. Além do Dijit, existe o Dojox.
  • O Dojox contém componentes inovadores como criação de gráfico, suporte off-line e grades, e mais.

Adicionalmente, a IBM fornece bibliotecas JavaScript com o Web 2.0 feature pack para tratar formatos SOAP e ATOM, assim como widgets baseadas em GUI para criar medidores no estilo analógico, como para um painel.

No centro do diagrama da Figura 2 há o produto WebSEAL da Tivoli, que executa a função de um proxy e fornece um mecanismo de segurança para controlar o acesso aos documentos e objetos da Web na rede. A conexão entre o servidor WebSEAL e um servidor backend de aplicativos da Web é denominada junção do WebSEAL. Uma junção do WebSEAL pode ser considerada como um ponto de montagem lógico no espaço da Web do WebSEAL e está ilustrada na Figura 3. Uma junção cria uma representação lógica dos documentos da Web e possibilita que o WebSEAL forneça segurança em nome do servidor backend ao qual o WebSEAL está conectado. Como as junções do WebSEAL criam um mapeamento lógico entre o espaço da Web de um servidor de aplicativos backend, as junções podem ser usadas para criar um mapeamento transparente para o usuário ou aplicativo da Web. Como um exemplo, se o aplicativo da Web que você criou é originado de http://www.mysite.com, mas acessa dados de clientes de http://www.yoursite.com/jsondata, é possível criar uma junção do WebSEAL que mapeia o acesso para http://www.mysite.com/junction/jsondata. O WebSEAL mapeia a solicitação para http://www.yoursite.com/jsondata de forma integrada e retorna os dados de volta para o cliente.

Figura 3. Topologia com a junção do Tivoli WebSEAL
Figure 3. Topology with Tivoli WebSEAL junction

Se o servidor requer segurança de baixa granularidade para um diretório, uma junção é criada no WebSEAL identificando o objeto ou documento da Web que necessita de autenticação e autorização adicionais. O Tivoli Access Manager fornece a estrutura de segurança à qual o WebSEAL se conecta.

O WebSEAL receberá uma solicitação de URL do cliente e, com base na configuração da junção, emitirá uma solicitação para o servidor. Do ponto de vista do servidor, o WebSEAL aparece como outro cliente qualquer solicitando informações. Dependendo dos dados retornados, o servidor formatará os dados no protocolo apropriado, como JSON, ATOM, SOAP ou XML. Dependendo do protocolo sendo retornado, o Web 2.0 feature pack fornece tecnologia de aplicativos do lado do servidor que pode tornar o retorno de conteúdo de dados mais fácil.

  • O JSON4J é uma biblioteca Java que pode ser usada com seu aplicativo para criar fluxos de dados formatados do JSON. Como um exemplo, pode ser necessário retornar colunas em uma tabela de um banco de dados SQL. O JSON4J pode ser usado para formatar os dados gerando um fluxo de dados JSON, que é então retornado de volta para o cliente.
  • O Abdera 0.40 é fornecido com o Web 2.0 feature pack e pode ser usado para criar alimentações de publicações no estilo ATOM a partir do servidor. As alimentações podem representar informações de notícias, ou qualquer outro conteúdo de publicação.
  • O RPCAdapter possibilita a invocação de métodos Java usando JavaScript. Especificamente, é possível criar um fluxo de dados do JSON no cliente contendo os métodos para invocar e os parâmetros. Os dados são enviados para o RPCAdapter, que verifica a solicitação JSON e chama o método especificado. A resposta do método pode ser um Java Bean, que é serializado para um fluxo de dados XML ou JSON e devolvido para o cliente. O RPCAdapter permite um mapeamento mais fácil de Java Beans legados para formatos que sejam consumíveis para um cliente baseado em Ajax.

Cenários demonstrando os desafios na implementação de uma arquitetura Ajax

Dependendo do aplicativo e complexidade, pode ser necessário que várias questões sejam respondidas antes de implementar uma arquitetura no estilo Ajax em uma rede. Aqui estão alguns exemplos:

Expiração de sessão do usuário

Ao usar a arquitetura acima, considere o cenário onde foi criado um widget JavaScript Dojo que solicita dados para um servidor e os exibe em uma tabela. O widget usa a função xhrGet do Dojo para emitir um XMLHTTPRequest para o servidor. O proxy encaminha a solicitação para o servidor e o servidor responde com um fluxo de dados JSON, que o widget Dojo analisa facilmente para exibir os dados. O que acontece quando a sessão do proxy WebSEAL expira devido a um esgotamento de tempo limite ou se o número de sessões exceder o máximo?

Do ponto de vista do widget, o código emite uma solicitação e espera que o retorno seja formatado como JSON. Ao invés disso, o widget recebe uma resposta HTML, que é uma página da Web com um formulário de login. A página da Web com formulário de login solicita um ID e senha do usuário. Normalmente, um login da Web não é um problema, mas como a solicitação subjacente ao servidor está ocorrendo em segundo plano, não há uma ação de usuário óbvia para o login. A Figura 4 ilustra o problema.

Figura 4. Expiração de Sessão do Usuário
Figure 4. User Session expiration

Do ponto de vista do WebSEAL, quando uma sessão do usuário expira, a última solicitação emitida é armazenada no cache e o formulário de login do Tivoli Access Manager é retornado. Quando o formulário de login for enviado, o WebSEAL e o WebSEAL autenticado novamente pelo usuário reenviam a solicitação. Em um aplicativo Ajax complexo, isso normalmente causa uma perda de contexto. Ao interceptar esse comportamento, é possível lembrar esse contexto e trabalhar para restaurá-lo para fornecer a experiência de usuário ideal.

Possível solução

Uma solução neste caso seria reconhecer quando os dados recebidos não são recebidos e responder adequadamente. No caso de dados JSON, a solução é usar dojo.fromJSON(data) e analisar a resposta do JSON. A análise falhará se for recebido HTML de um formulário de login ou uma página de erro HTML do servidor. Se houver um problema, capture a exceção e proceda a partir daí. As condições de erro HTTP podem ser obtidas pela função de erro. O parâmetro ioArgs fornece atributos adicionais que podem ser usados para ajudar a localizar o problema.

Listagem 1. Exemplo de solução
<script>
        var timer = null;
        // Function that retrieves a JSON object and puts the information
        // into the div with an id of 'json-content'. Notice how we're defining
        // 'handleAs' to be of type 'text'. We we handle the parsing of the JSON
        // data so that we can trap the exception if it occurs.
        function getJson () {
            
            var d = dojo.xhrGet ({
                                  url:      '/webseal/login',
                                  handleAs: 'text', 
                                  load:     loadIntoNode,
                                  error:    errorCondition
                                 });
        };


          function loadIntoNode(data, ioArgs){
            try{
                console.log("Read JSON Data ... do something",data);
				
		// read the JSON data that was returned by the service 
                var jsonData = dojo.fromJson(data);

                console.log(jsonData.attribute);
                console.log(jsonData.number);
		
                //do something with the JSON data that you read
		//dojo.byId("json-content").innerHTML = data;

            }catch(e)
            {
                // respond with an error reading JSON.  As an example, if an HTML form
                // login is returned, then dojo.fromJson will throw an Exception. 
                // Catch the exception and dispaly a login box. At this point, we
                // are assuming the error condition is because Dojo can't parse the
                // JSON stream. You can fine tune the error condition by looking at
                // the e.message value
		        console.log("error reading json data ",e.message);
                
                // Do something on the error condition, display a login widget, or 
                // look at the ioArgs to further narrow the problem down.
          }

          function errorCondition(error,ioArgs){

           console.log("Status",ioArgs.xhr.status);
              
            // retrieve an error message for the HTTP response code.  As an 
            // example, if we get a 500 (Server Error) then take an action.

            switch(ioArgs.xhr.status) {
            case 404: //page not found error
                      break;
            case 500: // server side error
                      break;
            case 407: // proxy authentication
                      break;
            default: // default action
            };

            console.log("HTTP Error code:",ioArgs.xhr.status);
            console.log("Error Condition:",error.responseText);
	        console.log("Error Message:  ",error.message);
	        
	        //dojo.byId("json-content").innerHTML = ioArgs.xhr.status;
          };       
        
</script>

Conexão persistente

Manter uma conexão persistente entre um cliente e um servidor da Web está se tornando uma técnica popular em ambientes Ajax. Como um exemplo, um Web 2.0 feature pack suporta o modelo de programação Comet. O Comet é um modelo de aplicativos da Web onde uma conexão HTTP mantida por longo tempo permite que o servidor envie dados ao navegador sem que o navegador solicite os dados. Como a conexão com o servidor está sempre aberta, o servidor pode facilmente enviar novos dados para o cliente. Quando o tempo de espera da conexão expirar, a biblioteca JavaScript reabre a conexão com o servidor e a mantém aberta até que o tempo de espera se esgote. O processo se repete com a biblioteca JavaScript abrindo a conexão novamente.

Um exemplo típico seria um aplicativo de cotações de ações onde as informações de preço alteradas são enviadas ao navegador sem intervenção do usuário. Do ponto de vista do usuário, a mudança ocorre instantaneamente. O modelo de programação Comet difere de um modelo de sondagem, onde o cliente abre uma conexão, solicita uma atualização, e então fecha a conexão novamente. O efeito do modelo de programação Comet é que conexões persistentes são mantidas abertas até os terminais de serviço aos quais o cliente está se conectando. A Figura 5 ilustra o cenário.

Figura 5. Modelo de programação Comet
Figure 5. Comet programming model

A implicação disso para o WebSEAL é que os usuários com sessões ativas manterão aberta pelo menos uma conexão de longa duração com o servidor, além das conexões mais curtas que são abertas por outras solicitações iniciadas pelo usuário. Isso consumirá encadeamentos de trabalho do WebSEAL, e o valor do parâmetro [server] worker-threads pode precisar ser ajustado no arquivo de configuração do WebSEAL. Em casos extremos, quando um grande número de sessões de usuário ativas é esperado, pode ser necessário adicionar instâncias do WebSEAL.

Possível solução

Determine se há um problema com a configuração atual do parâmetro [server] worker-threads configurado no arquivo de configuração do WebSEAL. O método mais simples para determinar se há um problema é usar as estatísticas do WebSEAL. Especificai mente, monitore a saída do componente pdweb.threads. (Listagem 2)

Listagem 2. Saída de um comando statistics get para o componente pdweb.threads
#pdadmin> server task default-webseald-instance stats get pdweb.threads
active : 0 total : 50

Se o valor reportado para active está atingindo continuamente o valor de total, devem ser disponibilizados mais encadeamentos de trabalho. Para obter mais detalhes sobre a configuração de encadeamentos de trabalho do WebSEAL, consulte o Guia de Ajuste de Desempenho do WebSEAL. Para obter mais detalhes sobre a coleta de estatísticas do WebSEAL, consulte o Guia de Determinação de Problemas do Tivoli Access Manager para e-business e o Guia de Auditoria do Tivoli Access Manager para e-business.

Autenticação e autorização

Dependendo do aplicativo da Web sendo desenvolvido, pode existir um requisito para controlar o acesso a documentos da Web ou os tipos de servidores aos quais o aplicativo da Web pode conectar-se. Embora esteja além do escopo deste artigo explicar a arquitetura de autenticação e autorização do Tivoli Access Manager (que é usada pelo WebSEAL), uma curta descrição pode ajudar a entender as questões ao criar arquiteturas no estilo Ajax que envolvem o WebSEAL.

O Tivoli Access Manager contém uma política de segurança que define o acesso a um domínio. O domínio é governado por duas estruturas de segurança: O registro de usuários, como o LDAP, Lotus Domino ou Microsoft Active Directory, e um banco de dados mestre de políticas de autorização. O registro do usuário contém os usuários e grupos que têm permissão para participar no domínio e completar a autenticação. O banco de dados de políticas de autorização contém uma representação de todos os recursos no domínio. O administrador de segurança pode determinar o nível de segurança aplicando regras conhecidas como protected object policies (POP) e access control lists (ACL). Um objeto protegido pode ser um recurso da Web, como uma página ou um URL para um terminal de serviços ao qual o cliente do navegador está tentando conectar-se.

Dependendo de como o WebSEAL é configurado, os clientes podem conectar-se a um domínio seguro como autenticados ou não autenticados. Somente usuários com uma entrada no registro de usuários podem se tornar usuários autenticados.

O proxy WebSEAL recebe uma solicitação do cliente do seu navegador a partir do widget Dojo. O acesso a objetos protegidos a partir de um cliente não autenticado ou uma conta com privilégios menores que os necessários retornará um prompt de login ou um erro "HTTP 401", respectivamente. Um agente de usuário, como um navegador, entende como tratar esses cenários. No entanto, um cliente típico usando Ajax como mecanismo de requisição não entenderá.

Regravação de links e política de mesma origem

Para uma junção padrão do WebSEAL, a filtragem JavaScript somente é executada se for configurada dessa forma. Ou seja, a junção é criada usando a opção -j.

A maioria dos desenvolvedores da Web inclui informações de URL em seu código JavaScript. Essas informações de URL não serão regravadas pelo WebSEAL, e podem causar uma variedade de problemas, principalmente relacionados a links mortos. No entanto, um problema específico também existe para solicitações feitas com o objeto XMLHttpRequest, devido à política de mesma origem que é impingida pela linguagem JavaScript.

O exemplo a seguir demonstra como um desenvolvedor da Web tipicamente escreveria seu conteúdo Ajax. Ao separar operações JavaScript do conteúdo HTML, é possibilitado uma melhor reutilização de recursos. Entretanto, se houver conteúdo de URL definido no JavaScript, será necessário habilitar a filtragem de script no WebSEAL. Considere o cenário ilustrado nas Listagens 3 e 4.

Listagem 3. widget.js
<script>        
        function getXML () {
        
            var url_1 = "http://sales.acme.org/sales.xml";
            var url_2 = "http://" + server + ":" + port + "/sales.xml";
            var url_3 = "/sales.xml";
            var url_4 = "sales.xml";
            
            var d = dojo.xhrGet ({
                                  url:      url_1,
                                  handleAs: 'text', 
                                  load:     loadIntoNode,
                                  error:    errorCondition
                                 });
        };
        function loadIntoNode(data, ioArgs){
        
            // process XML file
        }
        ...
        
</script>
Listagem 4. widget.html
<body class="tundra">
...

<button id="1469" dojoType="dijit.form.Button" onClick="getXML();")'>
XML Data Button
</button>

...
</body>

No exemplo acima, ocorrem esses problemas:

  • Os URLs não serão sobrescritos a não ser que a filtragem de scripts tenha sido configurada corretamente.
  • Se o link http://sales.acme.org/sales.xml link não for sobrescrito, será levantada uma exceção pelo navegador, pois isso seria visto como uma violação da política de mesma origem.
  • Se a filtragem de script foi ativada, a variável url_1 definida em example.js seria sobrescrita pelo WebSEAL.
  • Mesmo com a filtragem de script configurada corretamente, O WebSEAL não consegue interpretar o nível de construção dinâmica de link que é usado em url_2.
  • Embora o WebSEAL tenha a capacidade de filtrar JavaScript, é muitas vezes difícil diferenciar entre uma variável cujo objetivo é ser uma cadeia de caractere literal e um URL relativo ou relativo em relação ao servidor. URLs absolutos são sobrescritos corretamente, e como URLs relativos não precisam ser alterados, o único tipo de URLs que causará problemas neste caso são os URLs relativos em relação ao servidor. Isso ocorre porque o WebSEAL deve adicionar o nome da junção ao caminho do URL relativo em relação ao servidor que apontam para recursos em servidores de junção. Se não for possível determinar se uma variável declarada como url_3 é um URL relativo em relação ao servidor, todas as solicitações emitidas dessa maneira resultarão em links mortos.

Possível solução

O WebSEAL é inteligente o suficiente para filtrar o JavaScript, mas é preciso configurá-lo para isso. Se a filtragem JavaScript for simplesmente ativada, não será obtido o efeito desejado. Uma configuração padrão para o WebSEAL com filtragem de JavaScript ativada procurará somente URLs em conteúdo similar às entradas na tabela abaixo.

Conteúdo não filtradoConteúdo filtrado
<a href="javascript:doRequest('http://sales.acme.org/somecontent.html')">clique aqui</a><a href="javascript:doRequest('http://acme.org/sales_junciton/somecontent.html')">clique aqui</a>
<script type="text/javascript" src="http://sales.acme.org/js/script.js"></script><<script type="text/javascript" src="http://acme.org/sales_junction/js/script.js"></script>

Para obter o conteúdo definido dentro de um JavaScript externo inspecionado, é necessário usar uma configuração como a mostrada na Listagem 5.

Listagem 4. Mudanças necessárias no webseald.conf
[filter-content-types]
type = text/html
type = text/xml
type = text/javascript

[script-filtering]
script-filter = yes

Outra abordagem possível é utilizar junções de hosts virtuais, se isso é adequado à sua infraestrutura existente. Ao fazer isso, a necessidade de filtrar URLs dentro de conteúdo HTML é efetivamente eliminada. Um número muito menor de problemas ocorrerá quando for necessário sobrescrever URLs dentro dos seus scripts do lado do cliente. No entanto, junções de hosts virtuais não são adequadas para todas as implementações do WebSEAL dentro de uma empresa. Portanto, é realmente uma questão de escolher o que é melhor para o seu ambiente.


Conclusão

Este artigo demonstrou como o IBM Tivoli Access Manager WebSEAL pode ser usado juntamente com o IBM WebSphere Application Server Feature Pack para Web 2.0. O WebSEAL pode ser usado para fornecer um ambiente de proxy de rede seguro enquanto que o Web 2.0 feature pack fornece as tecnologias de aplicativos de servidor e cliente para criar arquiteturas no estilo Ajax. Ao fornecer os cenários de exemplo, o artigo explorou vários problemas que podem surgir, juntamente com as possíveis soluções.

Recursos

Aprender

Obter produtos e tecnologias

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere, Tivoli, Desenvolvimento da Web
ArticleID=445603
ArticleTitle=Ajax em uma rede: Os desafios de segurança e topologia para agregar conteúdo de múltiplos sites em uma arquitetura Ajax
publish-date=11092009