É possível aplicar à mesma mensagem mais do que uma transformação. Dependendo da situação, a ordem pela qual as transformações são aplicadas pode não ser indiferente. Por exemplo, numa mensagem XML onde seja necessário remover um elemento e converter o resultado em JSON, a transformação a ser aplicada em primeiro lugar terá de ser o XSLT. Assim sendo, criou-se um mecanismo que permite às aplicações indicar a ordem de execução das transformações. Esse mecanismo consiste num valor inteiro que indica a prioridade da transformação e onde zero é o valor máximo de prioridade. Assim, no caso de existirem três transformações para a mesma mensagem, uma com prioridade zero, outra com um e outra com seis. Será aplicada primeiro a de zero, seguida pela de um e finalmente a de seis. Os objectos MessageTransformation existentes na lista incluída no dicionário estão ordenados por índice de prioridade. Para transformações com igual nível de prioridade não existe garantia de qual será executada em primeiro lugar.
4.6.1 Comandos
Definiu-se um comando por cada transformação existente. Cada comando contém os parâmetros com a informação necessária à criação do objecto ITransformation
correspondente, sendo que todos eles têm pelo menos de incluir o nome do cliente destino, a expressão regular e o nível de prioridade.
Sendo este um módulo que suporta várias instâncias, a implementação de cada comando utiliza o WSP para notificar as restantes instâncias, existindo ainda o objecto TranslatorNotificationManager que trata de processamento dos eventos recebidos.
4.7 Módulo de segurança
O módulo de segurança recebeu o nome de Security e trata-se de um módulo que suporta mais do que uma instância. A Figura 51 representa o diagrama de classes da classe que implementa o módulo.
Figura 51: Diagrama de classes do módulo Security
A lista de aplicações cliente que requereram transporte de dados cifrados entre o bus e o cliente é guardada no campo acessível através da propriedade DataProtectionUsers. A propriedade PermissionsTable disponibiliza um dicionário onde se guarda, para cada aplicação cliente, o nome dos clientes que estão autorizados a enviar-lhe mensagens.
O método processDataMessageAsync começa por verificar a identidade do remetente da mensagem. Depois disso, é obtida uma lista dos destinos da mensagem, verificando-se para cada destino se existem políticas de envio e, caso existam, se o remetente está na lista de aplicações autorizadas a enviar mensagens para esse destino.
Finalmente verifica-se se os dados da mensagem estão cifrados (caso em que se efectua a decifra) e se os destinos da mensagem exigem dados cifrados (realizando-se a cifra).
À semelhança do módulo de encaminhamento, também neste módulo se utiliza a base de dados para persistência e partilha de informação entre as várias instâncias. A Figura 52 mostra o modelo relacional das tabelas criadas.
Figura 52: Modelo relacional referente ao módulo de segurança
Durante o carregamento de cada instância do módulo, o método synchronizeTables realiza a leitura das tabelas DataProtectionUser e PermissionsTable preenchendo os campos homónimos do objecto SecurityManager.
4.7.1 Autenticação
Para realizar as funcionalidades deste módulo, é necessário um mecanismo que permita autenticar as aplicações cliente. O mecanismo implementado consiste na prova de chave privada. Algoritmos de assinatura assimétricos utilizam um par de chaves criptográficas composto por uma chave privada que apenas uma das partes tem acesso e uma chave pública, à qual têm acesso todos os outros participantes.
O mecanismo de autenticação desenvolvido consiste em fornecer ao bus de mensagens uma chave pública associada ao nome de uma aplicação cliente. De seguida, nas comunicações em que for necessário o cliente autenticar-se, será incluído pelo cliente um cabeçalho onde consta a informação do seu nome assinada com a chave privada. Quando o bus verificar a validade da assinatura, prova-se que quem emitiu a mensagem tem em sua posse a chave privada que está associada à chave pública fornecida ao bus para aquele cliente [Gol06] As chaves públicas são armazenadas em certificados X509 localizados no certificate store do Windows e não é da responsabilidade do bus o transporte e instalação dos certificados. Os certificados funcionam apenas como meio de associar uma chave pública a um nome de utilizador (subject) não sendo feita verificação da cadeia do certificado.
O método de autenticação atrás descrito tem a fragilidade de um atacante poder capturar uma mensagem assinada e mais tarde repeti-la. O problema pode ser minimizado incluindo nos dados assinados da mensagem a data e hora em que a mensagem foi produzida. Desta forma, define-se um tempo máximo durante o qual é aceitável que a mensagem demore no transporte (por exemplo, 5 minutos) e todas as mensagens recebidas que tenham sido criadas há mais tempo, são descartadas. Contudo, esta solução obriga a que o bus e os clientes tenham um relógio sincronizado. Considerou-se que o peso de tal solução não se justifica e optou-se por uma solução em meio-termo. A autenticação inclui data e hora da criação da mensagem mas a tolerância dada pelo servidor são 13h. Assim, por um lado consegue-se minimizar os efeitos de um ataque por repetição de mensagens e pelo outro, apenas é exigido às aplicações cliente que tenham a data correcta.
A Listagem 10 mostra um excerto de uma mensagem de dados autenticada. <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:mb="http://www.isel.deetc/MessageBus"> <s:Header>
<mb:MessageType>data</mb:MessageType> ...
<mb:security encryptedPayload = "false"> <sender>SalesSystem</sender>
<timeStamp>26-06-2010 19:57:44</timeStamp> </mb:security>
<mb:securitySignature>TWFuIGbIG...</mb:securitySignature> ... </s:Header> <s:Body> ... </s:Body> </s:Envelope>