Com o suporte de conexão única (SSO), os usuários da web podem se autenticar uma vez ao acessar
recursos da web em vários WebSphere Application Server. Os mecanismos de login de formulário para aplicativos
da Web requerem que SSO seja ativada. Utilize este tópico para configurar a conexão única pela primeira
vez.
Antes de Iniciar
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
A SSO é suportada apenas quando o LTPA
(Lightweight Third Party Authentication) é o mecanismo de autenticação.
A SSO é suportada quando o LTPA (Lightweight Third Party Authentication) é
o mecanismo de autenticação.
Quando a SSO estiver ativada, um cookie será criado contendo
o token de LTPA e inserido na resposta HTTP. Quando o usuário acessa outros recursos da Web em qualquer outro processo do
WebSphere Application Server no mesmo domínio Domain Name Service (DNS), o cookie é enviado na
solicitação. O token LTPA é, então, extraído do cookie e validado. Se a solicitação estiver entre diferentes células do WebSphere Application Server, você deve compartilhar as chaves LTPA e o registro de usuário entre as células para que a SSO funcione. Os nomes de região em cada sistema no domínio de
SSO fazem distinção entre maiúsculas e minúsculas e devem corresponder identicamente.
Para o
S.O. local, o nome da região é o nome do domínio, se um domínio estiver sendo utilizado. Se um domínio
não for utilizado, o nome da região é o nome da máquina.
![[Linux]](../images/linux.gif)
![[AIX HP-UX Solaris]](../images/unix.gif)
O nome da região é igual ao nome do host.
Para
LDAP (Lightweight Directory Access Protocol), o nome da região é o nome
da região host:port do servidor LDAP. O mecanismo de autenticação LTPA requer que você ative a SSO se algum aplicativo Web
tiver login de formulário como o método de autenticação.
Como a conexão única é um subconjunto do LTPA, recomenda-se ler Lightweight Third Party Authentication para obter
informações adicionais.
Quando
você ativa a propagação do atributo de segurança, o seguinte cookie é sempre
incluído na resposta:
- LtpaToken2
- LtpaToken2 contém criptografia mais potente e permite incluir vários atributos
no token. Esse token contém a identidade de autenticação e as informações
adicionais, como os atributos utilizados para contatar o servidor de login
original e a chave de cache exclusiva para consultar o Assunto ao
considerar mais que apenas a identidade na determinação da exclusividade.
Nota: O
seguinte cookie é incluído opcionalmente na resposta quando o sinalizador Modo de
Interoperabilidade está ativado:
- LtpaToken
- O LtpaToken é use para interoperar com os releases anteriores do
WebSphere Application Server. Esse token contém apenas o atributo de
identidade de autenticação.
Nota: O LtpaToken é gerado para liberações anteriores ao
WebSphere Application Server Versões 5.1.0.2. O LtpaToken2 é gerado para
WebSphere Application Server Versão 5.1.0.2 e superiores.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Nota: O LtpaToken é gerado para liberações anteriores ao
WebSphere Application Server Versão 5.1.1. LtpaToken2 is generated for
WebSphere Application Server Version 5.1.1
and beyond.
Tabela 1. Tipos de Token LTPA. Esta tabela descreve os tipos de token LTPA.Tipo de Token |
Finalidade |
Como Especificar |
Apenas LtpaToken2 |
Este é o tipo de token padrão. Utiliza a intensidade de
criptografia de preenchimento AES-CBC-PKCS5 (tamanho de chave de 128 bits). Este token é mais forte que o LtpaToken mais
antigo usado antes do WebSphere Application Server Versão 6.02.
Esta é a opção recomendada quando a interoperabilidade com releases mais antigos não
é necessária. |
Desative
a opção Modo de Interoperabilidade, no painel de configuração SSO
no console administrativo.
Para acessar esse painel,
conclua as seguintes etapas:- Clique em Segurança > Segurança Global.
- Em segurança da Web, clique em SSO (Conexão Única).
|
LtpaToken e LtpaToken2 |
Use para interoperar com liberações anteriores ao
WebSphere Application Server Versão 5.1.1.
O cookie LtpaToken mais antigo está presente juntamente
com o novo cookie LtpaToken2. Desde que as chaves LTPA sejam compartilhadas corretamente,
você deverá estar apto a interoperar com qualquer versão do WebSphere utilizando essa
opção. |
Ative a opção Modo de Interoperabilidade, no painel
de configuração SSO no console administrativo.
Para acessar esse painel,
conclua as seguintes etapas:- Clique em Segurança > Segurança Global.
- Em segurança da Web, clique em SSO (Conexão Única).
|
Sobre Esta Tarefa
As etapas a seguir são requeridas para configurar a SSO pela primeira vez.
Procedimento
- Abra o console administrativo.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Digite http://localhost:port_number/ibm/console para acessar o console
administrativo em um navegador da Web.
Digite http://server_name:port_number/ibm/console para acessar o console
administrativo em um navegador da Web.
A porta 9060 é o número da porta padrão para acessar
o console administrativo.
Durante a instalação, porém, um número da porta diferente pode ter
sido especificado. Utilize o número da porta apropriado.
- Clique em Segurança > Segurança global.
- Em segurança da Web, clique em SSO (Conexão
Única).
- Clique na opção Ativado se o SSO estiver desativado. Depois
de clicar na opção Ativado, certifique-se de concluir as etapas restantes
para ativar a segurança.
- Clique em Requer SSL, se for esperado que todos os pedidos
utilizem HTTPS.
- Digite os nomes completos dos domínios no campo Nome do Domínio no
qual o SSO está efetivo. Se os nomes dos domínios forem especificados, eles deverão ser completos. Se o nome do domínio não for completo, o
WebSphere Application Server não configurará um valor de nome de domínio para o cookie
LtpaToken e a SSO será válida apenas para o servidor que criou o cookie.
Ao especificar
vários domínios, é possível utilizar os seguintes delimitadores: um ponto e vírgula
(;), um espaço ( ), uma vírgula (,) ou um canal (|). O
WebSphere Application Server procura os domínios especificados na ordem da esquerda para a
direita. Cada domínio é comparado
com o nome do host do pedido HTTP, até a primeira correspondência ser localizada.
Por exemplo, se você especificar
ibm.com; austin.ibm.com e uma
correspondência for localizada no domínio
ibm.com primeiro, o
WebSphere Application Server não continuará a procura por uma correspondência no domínio
austin.ibm.com. Entretanto, se uma correspondência não for localizada nos domínios
ibm.com ou austin.ibm.com, o
WebSphere Application Server não configurará um domínio para o cookie LtpaToken.
Tabela 2. Valores para Configurar o Campo Nome de Domínio. Esta tabela descreve os valores para configurar o campo Nome de Domínio.
Tipo de Valor do Nome do Domínio |
Por exemplo: |
Finalidade |
Em Branco |
|
O domínio não está configurado. Isso faz com que o
navegador configure o domínio para o nome do host do pedido. A conexão é válida apenas nesse único host. |
Nome de Domínio Único |
austin.ibm.com |
Se o pedido for para um host dentro do domínio
configurado, a conexão será válida para todos os hosts dentro desse domínio. Caso contrário, será válido apenas no nome do host do pedido. |
UseDomainFromURL |
UseDomainFromURL |
Se o pedido for para um host dentro do domínio
configurado, a conexão será válida para todos os hosts dentro desse domínio. Caso contrário, será válido apenas no nome do host do pedido. |
Nomes de Domínios Diversos |
austin.ibm.com;raleigh.ibm.com |
A conexão é válida para todos os hosts dentro do
domínio do nome do host do pedido. Atenção: SSO de domínio cruzado não é suportado. Por exemplo, chicago.xxx.com e cleveland.yyy.com, em que os domínios DNS sejam diferentes.
|
Nomes de Domínios Diversos e UseDomainFromURL |
austin.ibm.com;raleigh.ibm.com; UseDomainFromURL |
A conexão é válida para todos os hosts dentro do
domínio do nome do host do pedido. Atenção: SSO de domínio cruzado não é suportado. Por exemplo, chicago.xxx.com e cleveland.yyy.com, em que os domínios DNS sejam diferentes.
|
Se você especificar o UseDomainFromURL, o
WebSphere Application Server configurará o valor
de nome de domínio SSO para o domínio do host que cria a solicitação. Por exemplo, se uma solicitação HTTP for proveniente
de server1.raleigh.ibm.com, o
WebSphere Application Server configurará o valor de nome de
domínio SSO para
raleigh.ibm.com .
Dica: O valor, UseDomainFromURL, não faz distinção
entre maiúsculas e minúsculas. Você
pode digitar usedomainfromurl para utilizar esse valor.
Para obter mais
informações, consulte Configurações de Conexão Única.
- Opcional: Ative a opção Modo de Interoperabilidade se deseja suportar conexões SSO no
WebSphere Application Server Versão 5.1.1 ou posteriores para interoperar com versões
anteriores do servidor de aplicativos.
Essa opção configura o token LtpaToken de estilo antigo na resposta, para que possa ser
enviado a outros servidores que funcionam apenas com esse tipo de token. Caso contrário, apenas o token LtpaToken2 é incluído na resposta.
Se o desempenho tiver que ser considerado e
você só estiver se conectando a servidores Versão 6.1 ou mais recentes que não
estão executando produtos que dependem do LtpaToken, não ative o modo de
Interoperabilidade. Quando o modo de Interoperabilidade não estiver ativado, um LtpaToken não é retornado em uma resposta.
- Opcional: Ative a opção Propagação do Atributo de
Segurança de Entrada da Web se desejar que as informações incluídas
durante o login em um servidor front-end específico sejam propagadas para
outros servidores front-end. O token SSO não contém nenhum
atributo sensível, mas compreende onde o servidor de login original
existe em casos em que é necessário contactar esse servidor para
recuperar as informações serializadas. Ele também contém o valor de consulta do cache
para localizar informações serializadas em DynaCache, se os servidores de front-end
estiverem configurados no mesmo domínio de replicação de DRS. Para
obter informações adicionais, consulte Propagação de Atributo de Segurança.
Importante: Se as seguintes instruções forem verdadeiras, recomenda-se
desativar a opção
Propagação do Atributo de Segurança de Entrada da Web
por motivos de desempenho:
- Você não possui informações específicas incluídas no Assunto durante um
login que não possa ser obtido em um servidor front-end diferente.
- Você não incluiu atributos customizados no token PropagationToken utilizando
as APIs (Application Programming Interfaces) do WSSecurityHelper.
Se você perceber que há informações customizadas ausentes no Assunto, re-ative
a opção
Propagação do Atributo de Segurança de Entrada da Web para consultar se
as informações são propagadas com êxito para outros servidores de aplicativos front-end.
As duas propriedades customizadas a seguir podem ajudar a aprimorar o desempenho quando a
propagação do atributo de segurança estiver ativado:
- com.ibm.CSI.propagateFirstCallerOnly
O valor padrão dessa propriedade customizada é true. Quando essa propriedade customizada estiver
definida como true, o primeiro responsável pela chamada do token de propagação que permanecer
no encadeamento será registrado quando a propagação do atributo de segurança estiver ativada. Quando essa propriedade é configurada como false, todos os alternadores do responsável pela chamada são registrados, o que pode afetar o desempenho.
- com.ibm.CSI.disablePropagationCallerList
Quando essa propriedade customizada estiver definida como true, a capacidade de incluir um responsável pela chamada ou uma lista de hosts no token de propagação estará completamente desativada. Essa função é benéfica quando o responsável pela chamada ou a lista de hosts do token de propagação não for necessária no ambiente.
- Clique em OK.
O que Fazer Depois
Para que as alterações tenham efeito, salve, pare e
reinicie todos os gerenciadores de implementação do produto, nós e servidores.