Apache ODE

Os artefatos gerados automaticamente e que são necessários para a implantação do processo de negócio no Apache ODE são os seguintes:

• deploy.xml: descritor de implantação, contendo informações sobre a com- posição e os web services participantes;

• config.endpoint: utilizado para especificar as políticas de segurança que serão utilizadas para garantir os requisitos de segurança;

• VTAProcess.bpel: composição executável expressa em WS-BPEL 2.0; • VTAProcess.wsdl: descrição da interface da composição em WSDL 1.1; • VTAService.xml: política de segurança com asserções referentes à NF-Action

RestrictAccess;

• AirService.xml: política de segurança com as asserções das NF-Actions Use- Authenticationrelacionadas ao web service da companhia aérea que irá processar as tasks BPMN Check Flight Availability e Confirm Flight;

• PaymentService.xml: política de segurança com as asserções das NF-Actions (UseCryptography, UseAuthentication) relacionadas ao web service da admin- istradora de cartão de crédito que irá processar a task BPMN Confirm Pay- ment.

A descrição das interfaces dos web services AirService e Payment Service também são necessárias, mas não são geradas pela SecMosc Engine, pois estão armazenadas no SecMosc Repositorye são apenas recuperados para posterior implantação.

O arquivo deploy.xml é mostrado na Listagem 5.1. Na linha 6 é configurado qual serviço será provido pela composição definindo o endpoint do WSDL utilizado. Na linha 10, são configurados os partnerLinks referentes aos web services que serão utilizados para fazer o invoke. O mesmo é feito na linha 14 para o web service administradora de cartão de crédito. Na configuração dos partnerLinks também é especificado o endpointdos web services, sendo que nesta configuração é especificado o endereço onde o web service estará disponível.

5.4. GERAÇÃO DE ARTEFATOS ESPECÍFICOS

Listagem 5.1: Descritor de Deploy do Apache ODE

1 <?xml version="1.0" encoding="UTF-8"?> 2 <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03" xmlns: air="http://air.services.secmosc.cin.ufpe.br" xxmlns:pay="http ://payment.services.secmosc.cin.ufpe.br" xmlns:pns="http:// samplePaper.windows.cin.ufpe.br" xmlns:wns="http://samplePaper. windows.cin.ufpe.br.wsdl"> 4 <process name="pns:VTAService"> 5 <active>true</active> 6 <provide partnerLink="initializer">

7 <service name="wns:VTAService" port="VTAServicePort" />

8 </provide>

10 <invoke partnerLink="airInvoke">

11 <service name="air:AirService" port=" AirServiceHttpSoap11Endpoint" />

12 </invoke>

14 <invoke partnerLink="payInvoke">

15 <service name="pay:PaymentService" port=" PaymentServiceHttpSoap11Endpoint" />

16 </invoke>

17 </process>

18 </deploy>

O arquivo config.endpoint é responsável por anexar as políticas de segurança que serão processadas pelo Apache Rampart e pelo SecMosc Security Module. Na Listagem 5.2 é mostrado o arquivo gerado. Nas linhas 2, 3 e 4 são configurados apenas apelidos para os namespaces do serviços e cada serviço deverá possuir um namespace único e será referenciado pelo seu apelido. Nas linhas 7, 8 e 9 são configurados, para cada apelido, qual é o arquivo que contém a respectiva política de segurança.

Listagem 5.2: Configuração da Política de Segurança

1 #NS Alias 2 alias.air-ns=http://air.services.secmosc.cin.ufpe.br 3 alias.pay-ns=http://payment.services.secmosc.cin.ufpe.br 4 alias.vta-ns=http://samplePaper.windows.cin.ufpe.br.wsdl 6 #Policy Configuration 7 pay-ns.PaymentService.ode.security.policy=PaymentService.xml

8 air-ns.AirService.ode.security.policy=Airrvice.xml

9 vta-ns.VTAService.ode.security.policy=VTAService.xml

Para a composição, a task BPMN Receive Customer Data, foi associado a NF-Action RestrictAccess, conforme modelo BPMN da Figura 5.1. A asserção prin- cipal é o elemento de configuração do SecMosc Security Module <SecMoscConfig> presente na linha 5 da Listagem 5.3. Como a restrição é de entrada, aplicada na task BPMN que representa a primitiva <receive> do WS-BPEL, deverá ser usado o ele- mento <restrictSource>, linha 7, juntamente com o atributo policyType que indica qual a política que será aplica às restrições de IP. Caso o valor do atributo seja allow, será permitido acesso apenas ao endereços declarados e negado ao demais e, se o valor for deny, será negado apenas para os endereços listados e permitido os demais. Nas linhas 8 e 9, são mostrados quais os endereços IP que sofrerão a restrição. Essas propriedades são definidas durante a modelagem, sendo que elas possuem valores padrões, mas que podem ser alterados pelo usuário.

Listagem 5.3: Asserções da Task BPMN Receive Customer Data

1 <?xml version="1.0" encoding="UTF-8"?>

2 <wsp:Policy wsu:Id="RestAcc" xmlns:wsu="http://docs.oasis-open.org/ wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns: wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> 3 <wsp:ExactlyOne> 4 <wsp:All> 5 <secmosc:SecMoscConfig xmlns:secmosc="http://www.cin.ufpe.br/ secmosc/policy"> 6 <secmosc:restrictAccess> 7 <secmosc:restrictSource policyType="allow"> 8 <secmosc:source address="172.17.0.0/16"/> 9 <secmosc:source address="127.0.0.1"/> 10 </secmosc:restrictSource> 11 </secmosc:restrictAccess> 12 </wsp:All> 13 </wsp:ExactlyOne> 14 </wsp:Policy>

As asserções relativas à NF-Action RestrictAccess foram geradas baseadas no arquivo genérico requirements.xml, conforme o trecho mostrado na Listagem 5.4. Na linha 8 é especificado qual o tipo de restrinção e, nas linhas 9 e 10, são mostrados quais os endereços de rede que sofrerão a restrinção.

5.4. GERAÇÃO DE ARTEFATOS ESPECÍFICOS

Listagem 5.4: Configuração Genérica da NF-Action RestrictAccess

1 <?xml version="1.0" encoding="UTF-8"?>

2 <nf-requirements xmlns="http://www.cin.ufpe.br/sec-mosc/nf- requirements">

3 <nf-statements>

4 <nf-statement name="Customize" taskID="_0celZdllEd6se5R3-QLMYg ">

5 <nf-actions>

6 <nf-action name="RestrictAccess" nf-attribute="Security\ Confidentiality">

7 <nf-properties>

8 <nf-property name="polyceType" value="allow" />

9 <nf-property name="IP" value="172.17.0.0/16" />

10 <nf-property name="IP" value="127.0.0.1" />

11 </nf-properties> 12 </nf-action> 13 </nf-actions> 14 </nf-statement> 15 <!-- Addtional NFStatements --> 16 </nf-statements> 17 </nf-requirements>

Para a task Check Flight Availability foi associada a NF-Action UseAu- thentication, sendo a mesma suportada pelo Apache Rampart. A configuração para realizar a NF-Action é mostrada na Listagem 5.5. Para isso, na linha 7 é adicionado um elemento <UsernameToken> para incluir informações de autenticação em todas as requisições feitas ao web service. A autenticação é baseada no par usuário/senha, sendo que na linha 12 é especificado o nome do usuário e na linha 13 a classe que irá, em tempo de execução, recuperar a senha do repositório de serviços e incluí-la na mensagem SOAP na forma de um hash SHA1 [10] ou algum outro algoritmo de assinatura digital suportado pelo Rampart.

Listagem 5.5: Asserções da Task BPMN Check Flight Availability

1 <?xml version="1.0" encoding="UTF-8"?>

2 <wsp:Policy wsu:Id="Auth" xmlns:wsu="http://docs.oasis-open.org/wss /2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp ="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http ://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:ramp=" http://ws.apache.org/rampart/policy">

4 <wsp:All> 5 <sp:SignedSupportingTokens> 6 <wsp:Policy> 7 <sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap .org/ws/2005/07/securitypolicy/IncludeToken/ AlwaysToRecipient" /> 8 </wsp:Policy> 9 </sp:SignedSupportingTokens> 11 <ramp:RampartConfig> 12 <ramp:user>engineUser</ramp:user> 13 <ramp:passwordCallbackClass>br.cin.ufpe.secmosc.clients. EnginePWCBHandler</ramp:passwordCallbackClass> 14 </ramp:RampartConfig> 15 </wsp:All> 16 </wsp:ExactlyOne> 17 </wsp:Policy>

A configuração genérica da NF-Action UseAuthentication, também parte do arquivo requirements.xml, é mostrada na Listagem 5.6. A configuração genérica e a específica para esta NF-Action é a mesma para as tasks Check Flight Avail- ability, Process Payment e Confirm Flight, alterando apenas o nome do usuário e a senha extraída pela classe EnginePWCBHandler.

Listagem 5.6: Configuração Genérica da NF-Action USeAuthentication

1 <?xml version="1.0" encoding="UTF-8"?>

2 <nf-requirements xmlns="http://www.cin.ufpe.br/sec-mosc/nf- requirements">

3 <nf-statement name="Customize" taskID="_65468llEd6selkjlk67_NM ">

4 <nf-actions>

5 <nf-action name="UseAuthentication" nf-attribute="Security\ Confidentiality">

6 <nf-properties>

7 <nf-property name="Token Type" value="UsernameToken" />

8 </nf-properties> 9 </nf-action> 10 </nf-actions> 11 </nf-statement> 12 <!-- Addtional NFStatements --> 13 </nf-statements> 14 </nf-requirements> 68

5.4. GERAÇÃO DE ARTEFATOS ESPECÍFICOS

A task Process Payment possui duas NF-Actions associadas: ( UseAuthenti- cation e UseCyptography). Sendo que a configuração para UseAuthentica- tioné similar à mostrada na Listagem 5.5. A configuração para UseCyptography é mostrada na Listagem ??. Nas linhas 8 a 17, é configurado qual o tipo de token (certi- ficado) será utilizado para iniciar a conversação (<InitiatorToken>). De maneira análoga deverá ser configurado, na linha 19, o tipo de certificado utilizado no lado do serviço. Nas linhas 21 a 25 (Listagem ??) será configurado qual o tipo de algoritmo utilizado no processo de encriptação (<AlgorithmSuite>). Neste caso foi utilizado o TripleDesRsa15. Nas linhas 32 a 34 (Listagem ??), estão especificadas quais partes da mensagem (Header ou Body) poderão ser encriptadas utilizando o elemento <Encrypt- edParts>. Nas linhas 36 a 49 são feitas configurações específicas para o Rampart, como qual o certificado a ser utilizado para encriptar e decriptar, a localização do arquivo que contém os certificados (keystore), a senha para acessá-lo, assim como o nome da classe Java que irá manipular a recuperação da senha da chave privada dos certificados <passwordCallbackClass>.