Cenários de Uso de SAML
A função SAML é descrita por meio de quatro cenários de uso básicos. Os três primeiros cenários demonstram a conexão única dos serviços da Web, configurados usando um conjunto de políticas. O quarto cenário descreve a conexão única SAML customizada, que pode ser construída usando a API SAML e a API do cliente de confiança. Os cenários demonstram o uso de blocos de construção e APIs SAML para autenticação em um Security Token Service (STS), solicitam tokens SAML e implementam os tokens SAML para obter acesso a serviços de negócios.
Visão geral
O WebSphere Application Server com SAML fornece blocos de construção e APIs que permitem criar a conexão única e identificar soluções de negócios da federação de identidade usando tokens SAML. Os conjuntos de política SAML são os blocos de construção para configuração de aplicativos de serviços da Web para solicitar tokens SAML, propagar tokens SAML em mensagens SOAP e validar e autenticar tokens SAML, todos sem uma única linha de programação.
Usando as APIs SAML e de cliente WS-Trust, você pode criar programaticamente tokens SAML, analisar e validar tokens SAML e autenticar tokens SAML recebidos de protocolos diferentes de mensagens SOAP de serviços da Web. Especificamente, use as APIs SAML para processar atributos de token SAML customizados, criar interfaces de aplicativo personalizadas e executar autorização baseada em solicitação. Use a API de cliente WS-Trust para solicitar tokens SAML ou outros tipos de tokens, a partir de um STS, e validar e trocar tokens de segurança com um STS.
O produto WebSphere Application Server não inclui um STS para emitir SAML ou qualquer outro tipo de token de segurança. Entretanto, o WebSphere Application Server com SAML interopera com o Tivoli Federated Identity Manager e outras implementações STS de terceiros.
Cenário 1: Conexão Única (SSO) de Serviços da Web
Neste cenário de uso de conexão única (SSO), um usuário é autenticado em um STS e solicita tokens SAML usando o método de confirmação de transmissão. O usuário então usa tokens SAML para acessar um provedor de serviços de negócios. O provedor de serviços de negócios valida os tokens SAML e assere a identidade e atributos do usuário com base no relacionamento de confiança entre o provedor e o STS emissor. Os tokens SAML recebidos serão considerados válidos se os certificados de assinatura de token forem confiáveis pelo provedor de serviços de negócios, e se o prazo de expiração dos tokens for menor que o horário local do provedor de serviços de negócios mais um clock skew configurável.
O provedor de serviços de negócios pode acessar serviços de recebimento de dados em nome do usuário usando tokens SAML baseados na configuração de política do serviço. Usando a configuração de política, o provedor de serviços de negócios pode propagar os tokens SAML originais ou gerar tokens SAML emitidos automaticamente baseados nos atributos do usuário originais. Para obter uma descrição detalhada de como configurar conjuntos de políticas e ligações para este cenário, leia sobre como configurar ligações do cliente e do provedor para o token de transmissão SAML.
A conexão única usando um token de transmissão SAML tem vantagens sobre outra tecnologia SSO, porque o SAML é um token de segurança padrão de mercado e é suportado por vários produtos de fornecedor. Além disso, a implementação do WebSphere Application Server da função SAML interopera com o Tivoli Federated Identity Manager, DataPower e outros produtos de fornecedor.

É possível incluir uma ligação do responsável pela chamada nas ligações de amostra do provedor SAML para selecionar o token SAML recebido, que representa a identidade do responsável pela chamada. O ambiente de tempo de execução do Web Services Security usa o SAML NameId para representar a identidade do cliente e procurar o nome da segurança do usuário e a associação ao grupo a partir do registro de usuário configurado quando você usa a configuração de login JAAS de system.wss.caller padrão.
Quando este cenário for executado com êxito, o ambiente de tempo de execução WS-Security salvará os tokens SAML e poderá reutilizá-los para acessar o mesmo provedor de serviços de negócios, se os tokens ainda forem válidos. O token será válido se o prazo de expiração do token for menor que o período de cache, que é configurável. Quando o provedor de serviços de negócios tiver validado e autenticado os tokens SAML recebidos, os JAAS subjects, juntamente com os tokens SAML correspondentes, serão salvos no cache de autenticação. O token SAML permanece válido no servidor de aplicativos de hosting, independentemente do prazo de expiração do token. Isto significa que o ambiente de tempo de execução WS-Security não verifica o prazo de expiração do token SAML no mesmo processo, porque os tokens SAML permanecem válidos no processo do servidor de aplicativos, desde que o token esteja no cache de autenticação.
Os prazos de expiração do token SAML são verificados quando o provedor de serviços de negócios usa os tokens SAML para chamar serviços de recebimento de dados. Os pedidos de saída falharão se o prazo de expiração do token SAML não for menor que o prazo atual incluído no período de cache. Esta limitação também é aplicável quando a configuração de política requer o uso dos tokens SAML originais. No entanto, a limitação não será aplicável se a configuração de política usar então tokens SAML emitidos automaticamente, por exemplo, se o provedor de serviços de negócios tiver criado e assinado uma reprodução dos tokens SAML originais.
Cenário 2: Conexão Única (SSO) de Serviços da Web com Validação holder-of-key
A conexão única com o cenário de uso de validação holder-of-key é semelhante ao cenário de uso de SSO anterior. A SSO com o cenário holder-of-key usa tokens SAML com o método de confirmação holder-of-key (HoK), em vez do método de confirmação de transmissão. Os tokens SAML HoK contêm uma chave que o cliente usa para comprovar a propriedade da chave e a propriedade do token. Esta chave integrada pode ser uma chave compartilhada (também conhecida como uma chave simétrica) ou um certificado X.509 com uma chave pública (também conhecida como uma chave assimétrica). No caso de uma chave compartilhada, a chave é criptografada usando a chave pública do provedor de serviços de negócios de destino para que apenas o serviço de negócios pretendido possa consumir as mensagens SOAP.
Quando um cliente solicita tokens SAML com a chave compartilhada HoK de um STS, o STS criptografa a chave nos tokens SAML e envia uma cópia da mesma chave na resposta WS-Trust ao cliente solicitante. Isto é necessário porque, de outra maneira, o cliente não poderá ler as chaves criptografadas nos tokens SAML. Para comprovar a propriedade dos tokens SAML, o cliente usa as chaves compartilhadas para assinar e criptografar as mensagens de pedido SOAP. Os serviços de negócios são necessários para validar a propriedade do token HoK, extraindo a chave compartilhada criptografada e usando-a para verificar a assinatura digital.

1 O usuário efetua logon em um navegador da Web usando o SPNEGO e é autenticado. É criado um JAAS subject.
2 A credencial do token SPNEGO é usada para solicitar um token SAML usando WS-Trust. O token é assinado com a chave privada do servidor de confiança.
3 A assinatura do token SAML é validada com base no relacionamento de confiança. A credencial de segurança é criada usando os atributos do token SAML. A chave criptográfica do token SAML é usada para decriptografar a mensagem SOAP.
Conforme mostrado no diagrama, um cliente do navegador usa credenciais do Kerberos (representadas pelo token SPNEGO) para acessar um aplicativo da Web. Suponha que a credencial do Kerberos possa ser delegada, o aplicativo da Web possa solicitar um token SAML do STS em nome do cliente, usando a credencial Kerberos do cliente delegado. Por exemplo, o aplicativo da Web obtém um token do Kerberos da solicitação de aprovação do cliente (APREQ) a partir do centro de distribuição (KDC) em nome do cliente. O aplicativo da Web usa então o token APREQ do cliente para autenticar no STS e solicita um token SAML do cliente do STS em nome do cliente.
Neste exemplo, o token SAML requer o método de confirmação holder-of-key usando uma chave simétrica. O aplicativo da Web usa o token SAML para acessar serviços de negócios de recebimento de dados, também em nome do cliente, portanto, o token SAML autentica o cliente nos serviços de recebimento de dados e também protege as mensagens de pedido usando assinatura digital e criptografia. Para obter informações adicionais sobre como configurar ligações para o token HoK, leia sobre como configurar ligações de cliente e de provedor para o token de chave simétrica holder-of-key SAML.
Quando o cenário for executado com êxito, os serviços de negócios de destino poderão então usar o token SAML para acessar outros serviços de recebimento de dados usando o mesmo procedimento descrito no cenário, se os serviços de negócios de recebimento de dados puderem extrair a chave integrada. Como alternativa, os serviços de negócios podem ser configurados para usar tokens SAML assinados automaticamente para acessar serviços de recebimento de dados para evitar a distribuição da chave privada.
Cenário 3: Gerenciamento de Identidade Associado de Serviços da Web
No cenário de uso de gerenciamento de identidade associada, um cliente do navegador acessa um aplicativo da Web do portal da empresa. Neste cenário, os dados de autenticação do usuário básicos, como o nome de usuário e senha, são usados para solicitar tokens SAML de um STS e, em seguida, os tokens SAML são usados para obter acesso a serviços de negócios em domínios de segurança. O provedor de serviços de negócios de recebimento valida os tokens SAML com base no relacionamento de confiança entre o provedor e o STS emissor, e o provedor também assere a identidade e atributos do usuário. Isto significa que o usuário não precisa ser definido anteriormente no diretório do usuário nos serviços de negócios de destino. Uma vantagem deste cenário é que ele fornece uma maneira mais gerenciável de associar serviços de negócios de muitos parceiros de negócios, enquanto remove o requisito para consolidar usuários em um serviço de diretório do usuário.

1 O usuário efetua logon com um nome de usuário e senha e é autenticado no portal da empresa. É criado um JAAS subject.
2 O nome de usuário e senha são usados para autenticação no STS e para solicitar um token SAML que representa o usuário.
3 A assinatura do token SAML é validada com base no relacionamento de confiança. As credenciais de segurança são criadas usando os atributos do token SAML. A chave criptográfica do token SAML é usada para decriptografar a mensagem SOAP.
A configuração de login do sistema padrão, wss.caller, mapeia as identidades do usuário que são representadas por tokens SAML para identidades do usuário no diretório do usuário configurado. Um módulo de login customizado deve ser incluído na configuração de login wss.caller para asserir identidades do usuário do token SAML de outros domínios de segurança no servidor de aplicativos. Este módulo de login customizado extrai a identidade do usuário do token SAML e outros atributos e constrói as propriedades de asserção usadas pelo servidor de aplicativos. Duas destas propriedades, nome de usuário e identidade do usuário, são requeridas pelo servidor de aplicativos. Como as duas propriedades são fornecidas na asserção de identidade, o servidor de aplicativos não precisa validar o nome de usuário em relação ao diretório do usuário local.
Além disso, as informações sobre associação ao grupo de usuários podem ser fornecidas para o servidor de aplicativos. Estas informações são usadas para construir o objeto WSCredential que representa as credenciais de segurança do servidor de aplicativos para o usuário. As propriedades de usuário são transmitidas para o WSWSSLoginModule do servidor de aplicativos usando o estado compartilhado LoginContext JAAS. Para obter informações detalhadas sobre estas propriedades, leia sobre como configurar o mapeamento de identidade de entrada.
Cenário 4: Soluções de Conexão Única (SSO) Customizada
O cenário de uso de conexão única (SSO) customizada usa as APIs de biblioteca de tokens SAML, as APIs de cliente WS-Trust e outras APIs do servidor de aplicativos e SPIs para construir soluções de SSO customizada para ajuste a um ambiente de computação de negócios específico. O diagrama para este cenário mostra um exemplo no qual os usuários são tokens SAML autenticados e emitidos de um provedor de identidade que tem um relacionamento de confiança com um servidor da empresa. Nesse cenário, uma empresa deseja conceder acesso aos usuários para aplicativos da Web protegidos com base no relacionamento confiável, sem pedir aos usuários autenticação adicional.
Os clientes do aplicativo da Web, como navegadores da Web, passam tokens SAML para o servidor de aplicativos usando o protocolo HTTPS, em vez de usar o protocolo de serviços da Web. Para interceptação e transmissão nestes pedidos, a empresa constrói um trust association interceptor (TAI) SAML que implementa a API Trust Association Interceptor do servidor de aplicativos. Um TAI SAML usa a API da biblioteca de tokens SAML para validar e autenticar Tokens SAML. Como alternativa, o TAI SAML pode usar a API do cliente WS-Trust para validar e autenticar tokens SAML em relação a um STS externo. Para obter informações adicionais sobre a interface TAI, leia sobre como desenvolver um interceptor customizado para associações de confiança. Um TAI SAML customizado não é fornecido com o WebSphere Application Server.

1 O usuário efetua logon em um provedor de identidade usando um nome de usuário e senha. Os provedores de identidade emitem um token SAML para o usuário.
2 O TAI SAML usa a API SAMLTokenFactory para validar o token SAML e para autenticar o token SAML para criar credenciais do usuário. O TAI SAML também pode usar a API do cliente WS-Trust para validar o token SAML com um STS externo.
Para obter informações adicionais sobre as APIs SAML, leia sobre a API do cliente WS-Trust e as APIs da biblioteca de tokens SAML.
Uma Solução Mais Complexa: Domínios de Segurança Múltiplos
As seções anteriores desse documento descrevem quatros cenários básicos de uso. Entretanto, você pode querer asserir tokens SAML entre diversos limites de domínio de segurança. Para obter informações adicionais sobre essa solução, consulte a documentação sobre asserções SAML entre os domínios de segurança do WebSphere Application Server.