A amostra Security Policy Enforcement Point (PEP) demonstra como usar o Security Policy Enforcement Point (PEP) como o Ponto de Cumprimento da Política em um fluxo de mensagens.
Nessa amostra, informações de identidade contidas na mensagem são usadas pelo Security Policy Enforcement Point (PEP) para impingir as operações de segurança. Por exemplo, autenticação, autorização e mapeamento usando um provedor de segurança WS-Trust v1.3, como TFIM v6.2. Como uma implementação de segurança é baseada em um provedor de segurança centralizado externo, como TFIM v6.2, esta amostra fornece um fluxo de mensagens adicional que emula algumas operações de segurança básicas.
Instruções também são fornecidas detalhando como configurar o TFIM v6.2 como um provedor de segurança externo centralizado para a amostra, consulte Estendendo a amostra Security Policy Enforcement Point (PEP).
Esta amostra demonstra como executar as seguintes tarefas:
Esta amostra demonstra os seguintes cenários:
Para obter detalhes sobre os conceitos relacionados com a segurança do fluxo de mensagens, consulte Visão geral de segurança do fluxo de mensagens na documentação do WebSphere Message Broker.
O diagrama a seguir mostra o fluxo de mensagens principal da amostra Security Policy Enforcement Point (PEP), que é o SecurityPEPNodeSampleFlow.msgflow no projeto de Message Broker SecurityPEPNodeSampleApplicationProject. Este fluxo consiste em um nó HTTPInput e dois nós SecurityPEP que invocam operações de segurança. Um nó HTTPRequest também é usado para invocar o serviço da Web assegurado com o SAML 2.0.
O nó HTTP_ID HTTPInput, extrai a identidade transmitida na mensagem de entrada. O local do nome de usuário e senha que forma a identidade na mensagem é conhecida para o nó HTTPInput pelas propriedades de segurança configuradas. O nó HTTPInput do arquivo broker archive (BAR) SecurityPEPNodeSample.bar é configurado com PEPSAMPLE_HTTP_UPA1_EMUL como o perfil de segurança. Os valores autenticação e authenticationConfig do perfil de segurança são configurados para invocar a emulação STS para autenticar a identidade. Se a autenticação do token de identidade do nome do usuário e senha falharem neste nó, a lista de exceções será transmitida para o terminal de Falha. Se a autenticação for bem sucedida, a mensagem será transmitida para o próximo nó GetAuthenticationType.
O nó Compute GetAuthenticationType, busca o campo DemonstrateTokenType do conteúdo da mensagem de entrada e roteia-o adequadamente. O valor do campo DemonstrateTokenType pode ser UP ou SAML. Se não for nenhum desses, uma exceção de usuário será produzida.
O nó PEP_UP_A1A2 SecurityPEP extrai a identidade do nome de usuário e senha na mensagem de entrada para demonstrar que o local da identidade na mensagem é conhecido para o nó SecurityPEP pelas propriedades de segurança configuradas. O nó PEP do arquivo broker archive (BAR) SecurityPEPNodeSample.bar é configurado com o perfil de segurança PEPSAMPLE_PEP_UPA1A2_EMUL. Os valores autenticação, authenticationConfig, autorização e authenticationConfig do perfil de segurança são configurados para invocar a emulação STS para autenticar e autorizar a identidade. Se a autenticação e a autorização do token UP forem bem sucedidas, a mensagem será transmitida para o nó Compute, no qual o status da operação de segurança é atualizado no corpo da mensagem e uma resposta é retornada.
O nó PEP_MAP_UP->SAML2.0 SecurityPEP reutiliza a identidade transmitida na mensagem de entrada e coloca-a nos campos de segurança da árvore de propriedades. Quando as propriedades de segurança configuradas são definidas para Token atual o nó SecurityPEP usa a identidade atual. O nó PEP do arquivo BAR SecurityPEPNodeSample.bar é configurado com o perfil de segurança PEPSAMPLE_PEP_MAPUP2SAML2.0_EMUL. Os valores mapeamento e mappingConfig do perfil de segurança são configurados para invocar a emulação STS para executar um intercâmbio de token do nome de usuário e senha para o conteúdo SAML 2.0. O token SAML mapeado é, em seguida, colocado no corpo da mensagem para que possa ser encaminhado para um serviço pelo nó HTTPRequest "HTTP Request-SAMLA1", que é configurado para invocar o fluxo de mensagensSecurityPEPNodeReportFlow.msgflow.
O serviço HTTP chamado pelo nó HTTPRequest no fluxo de mensagens SecurityPEPNodeSampleFlow.msgflow é exibido no seguinte diagrama SecurityPEPNodeReportFlow.msgflow:
Este fluxo possui um nó SecurityPEP que extrai o SAML2.0 presente no corpo da mensagem da mensagem de entrada e invoca o provedor de segurança para validar o SAML2.0. O nó PEP do arquivo BAR SecurityPEPNodeSample.bar está configurado com o perfil de segurança PEPSAMPLE_HTTP_SAMLA1_EMUL. Os valores authentication e authenticationConfig do perfil de segurança estão configurados para invocar a emulação STS para validar o conteúdo SAML. Se a validação do conteúdo do SAML2.0 for bem sucedida, a mensagem será transmitida para o nó Compute, no qual o status da operação de segurança é atualizado no corpo da mensagem e uma resposta é retornada.
A amostra usa o fluxo de mensagensSecurityPEPNodeSampleSTSEmulatorFlow.msgflow para emular as operações de segurança executadas por um provedor externo, consulte o diagrama a seguir:
Este fluxo contém o nó HTTPInput "HTTP WS Request", que recebe a solicitação WS-Trust feita pelo Broker Security Manager, quando os nós HTTPInput e SecurityPEP no fluxo de mensagens SecurityPEPNodeSampleFlow.msgflow chamam uma operação de segurança. O fluxo possui vários nós Compute que emulam a saída de um provedor de segurança e preparam uma resposta WS-Trust.
Nota: A emulação usa dados fixos que geram a mesma resposta WS-Trust a cada execução. No caso do token SAML, as datas não são alteradas dinamicamente. Por exemplo, IssueInstant="2010-04-14T07:10:53Z", NotBefore="2010-04-14T07:00:53Z" e NotOnOrAfter="2010-04-15T07:10:53Z". Essas datas e o período de validade do conteúdo de SAML não são verificados pela emulação.
Três mensagens de entrada são fornecidas para executar a amostra Security Policy Enforcement Point (PEP).
<?xml version="1.0" encoding="UTF-8"?> <Envelope> <Body> <MessageIdentity> <Username>broker01</Username> <Password>passw0rd01</Password> <IssuedBy>Issuer1</IssuedBy> <DemonstrateTokenType>SAML</DemonstrateTokenType> </MessageIdentity> </Body> </Envelope>
A mensagem é fornecida nos arquivos a seguir:
O arquivo .xml está na seguinte subpasta: SecurityPEPNodeSampleApplicationProject/SampleTestMessages/TestMessage_UPA1_MAP2SAML2.0_A1.xml
<?xml version="1.0" encoding="UTF-8"?> <Envelope> <Body> <MessageIdentity> <Username>broker01</Username> <Password>passw0rd01</Password> <IssuedBy>Issuer1</IssuedBy> <DemonstrateTokenType>UP</DemonstrateTokenType> </MessageIdentity> </Body> </Envelope>
A mensagem é fornecida nos arquivos a seguir:
O arquivo .xml está na seguinte subpasta: SecurityPEPNodeSampleApplicationProject/SampleTestMessages/TestMessge_UP_A1A2.xml
<?xml version="1.0" encoding="UTF-8"?> <Envelope> <Body> <MessageIdentity> <Username>dummy_usr</Username> <Password>passw0rd01</Password> <IssuedBy>Issuer1</IssuedBy> <DemonstrateTokenType>UP</DemonstrateTokenType> </MessageIdentity> </Body> </Envelope>
A mensagem é fornecida nos arquivos a seguir:
O arquivo .xml está na seguinte subpasta: SecurityPEPNodeSampleApplicationProject/SampleTestMessages/TestMessage_UP_A1_failure.xml