Conexão Única para um IBM WebSphere Portal por meio do IBM Tivoli Access Manager WebSEAL

Cenários concretos oferecem dicas de segurança Tivoli

Este artigo destaca alguns dos pontos importantes a serem considerados ao integrar o IBM® Tivoli® Access Manager para e-business com o IBM WebSphere® Portal para o propósito de fornecer autenticação a um portal por meio de conexão única (SSO). Ele fornece etapas detalhadas para configuração de um Trust Association Interceptor++ (TAI++), que é uma das diversas formas de configurar a SSO. Ele também aborda o gerenciamento de sessões do WebSphere Portal (WP). Este artigo também aborda as etapas necessárias para criar chaves para ativação da segurança usando o IBM Key Management Utility. Opções de linha de comandos também são fornecidas juntamente com opções da GUI para que um usuário não fique parado mesmo se a GUI não estiver disponível. Essas etapas também são úteis para aqueles que usam o IBM Key Management Utility para o propósito de gerenciamento de chaves.

Mr. Mandar Vilas Deshmukh, Staff Software Engineer, IBM India Pvt. Ltd.

Mandar is Staff Software Engineer, currently working with Tivoli® Directory Server Java development team as Technical lead. He has total 5+ years of experience in IBM® India Pvt. Ltd. He is Tivoli Certified Advanced Deployment Professional - Tivoli Security Management Solutions (ITAM, ITIM, ITIL Foundation Certified). He is also EC-Council certified Ethical Hacker, Sun certified Java Professional and IBM® Certified DB2 V 8.1 Associate.



Mr. Nagesh Bhagwat, Systems Software Engineer, IBM India Pvt. Ltd.

Nagesh is Systems Software Engineer, currently working with Tivoli Security Team, IBM® India Software Labs. He holds Bachelor of Engineering Degree in Computer Science. He is IBM®Tivoli Access Manager for e-business V6.0 Implementation-certified, IBM® Certified DB2 V 8.1 Associate and SUN Certified Java Professional.



18/Fev/2009

Introdução

O IBM WebSphere Portal é executado como um aplicativo no IBM WebSphere Application Server e fornece a agregação de conteúdos, aplicativos, processas, personalização e outros serviços. O WebSphere Application Server e o WebSphere Portal podem ser integrados com um produto gerenciador de segurança externa, tal como o IBM Tivoli Access Manager para e-business ou Netegrity SiteMinder.

Um dos componentes do Tivoli Access Manager é seu servidor de segurança de proxy reverso chamado WebSEAL. O WebSEAL pode ser o frontend de qualquer servidor de aplicativos da Web ou servidor da Web em uma infraestrutura de e e-business corporativa. Quando o WebSphere Application Server e o WebSphere Portal são implementados com o WebSEAL, geralmente é necessário fornecer uma experiência com a SSO para o usuário final. Para que a SSO seja possível, o WebSphere Application Server precisa ser configurado como "confiar" no servidor WebSEAL, assim, se o WebSEAL já tiver autenticado um usuário, o Application Server não precisará autenticar novamente o usuário.

O WebSphere Application Server fornece a estrutura Web Trust Association usada para configurar servidores de segurança de terceiros. Uma implementação do TAI é necessário para cada tipo de servidor de segurança. O WebSphere Application Server é fornecido com um TAI para Access Manager, o qual você pode configurar. Com base na confiança estabelecida, o Application Server pode mapear a credencial resultante do WebSEAL para uma credencial válida do WebSphere Application Server.

Este artigo é útil para administradores do Application Server, administradores de portais e outros que precisam fornecer a SSO para seus aplicativos WebSphere Portal. Para obter o melhor deste artigo, você deve estar familiarizado com as tarefas de administração do WebSphere Application Server, WebSphere Portal e Tivoli Access Manager. Também é necessário estar familiarizado com a configuração de um servidor de diretório LDAP, tal como IBM Tivoli Directory Server, o qual é usado no cenário de exemplo explicado neste artigo.

As informações sobre mecanismos SSO e o IBM Key Management Utility são úteis para programadores de segurança, profissionais de implementação e designers.


Técnicas de conexão única

Lightweight third-party authentication

Lightweight Third-Party Authentication (LTPA)" LPTA é uma tecnologia de autenticação usada em produtos IBM WebSphere e Lotus Domino.

Token LTPA

LtpaToken: O LtpaToken é usado para interoperar com os releases anteriores do WebSphere Application Server. Este token contém apenas o atributo de identidade de autenticação. O LtpaToken é gerado para releases anteriores ao WebSphere Application Server v5.1.0.2 (para z/OS) ou versão 5.1.1 (para plataformas distribuídas).

LtpaToken2: O LtpaToken2 contém criptografia avançada e permite incluir vários atributos no token. Este token contém a identidade de autenticação e informações adicionais, tais como os atributos usados para contato com o servidor de login original e a chave de cache exclusiva para procura do Assunto ao considerar mais do que apenas a identidade ao determinar exclusividade. O LtpaToken2 é gerado para o WebSphere Application Server Versão 5.1.0.2 (para z/OS®) e para v5.1.1 (para plataformas distribuídas) e posterior.

Se um usuário estiver acessando servidores da Web usando a tecnologia LTPA, então é possível que um usuário da Web propague automaticamente sua identidade entre todos os servidores físicos participantes.

Tal ambiente também é chamado de ambiente de conexão única (SSO).

Figura 1. SSO com LTPA
Trabalhando com LTPA

Fluxo de pedido:

1. O usuário solicita um recurso protegido pelo WebSEAL. O WebSEAL solicita as credenciais ao usuário, e o usuário as fornece.

2. O WebSEAL autentica o usuário comunicando com seu registro de usuário. Ele também determina se o usuário está autorizado a abrir a URL solicitada. Após o êxito na autenticação do usuário final, o WebSEAL cria o cookie do token LTPA.

3. O pedido é passado para o IBM HTTP Server usando a junção que está configurada para ele. A junção do WebSEAL para o IBM HTTP Server é configurada para passar as informações iv-user e iv-groups, e o Token LTPA que foi criado na Etapa 2, no cabeçalho HTTP.

4. O pedido é encaminhado para o WebSphere Application Server apropriado ou clone, conforme determinado pelo plug-in do Application Server.

5. No WebSphere Application Server, o TAI não está ativado e o Application Server obtém o token LTPA no cabeçalho. O Application Server cria apenas o cookie de sessão para este usuário e assume que este usuário foi autenticado. O WebSphere Portal procura por informações de grupo no LDAP, obtém o mapeamento de recursos a partir do banco de dados e, em seguida, exibe a página do portal.

Token LTPA:

O token LTPA é um elemento criptografado que contém as seguintes partes de informações:

Tabela 4. O token LTPA
Elemento Detalhes
Dados do UsuárioGeralmente configurado como ID do usuário, mas pode ser qualquer informação do usuário usada para identificar exclusivamente o usuário.
Prazo de ExpiraçãoDiferente da expiração do cookie, este campo é usado para impingir um limite de tempo que inicia a partir do momento de login e não é afetado pela atividade ou inatividade do navegador. O limite de tempo é uma definição LTPA configurável que tem 30 minutos como padrão.
Assinatura DigitalUsada para validar o token.

O cookie LTPA contém as seguintes partes de informações:

Tabela 3. O cookie LTPA
Elemento Detalhes
Nome do CookieSempre configurado como LtpaToken/LtpaToken2
DomínioConfigurado como o domínio da Internet compartilhado por todos os servidores participantes na conexão única (exemplo: mycompany.com
Expiração do CookieConfigurado para excluir este cookie ao final do tempo de vida do navegador.
SeguroConfigurado para forçar o uso de Secure Sockets Layer (SSL). Há uma definição de configuração LTPA que cria cookies que são enviados apenas por meio de SSL.
Valor do CookieIsso é configurado para o token LTPA conforme descrito abaixo.

Requisito e Suporte LTPA

O LTPA necessita que o registro de usuário configurado seja um repositório centralmente compartilhado, tal como um registro LDAP ou um® registro de domínio tipo Windows, para que os usuários e grupos sejam os mesmo no domínio SSO.

A tabela a seguir resume os recursos do mecanismo de autenticação e os registros de usuários com os quais o LTPA pode trabalhar. Isso é para o WebSphere Application Server v6.1

Tabela 5. Informações de suporte ao LTPA
Mecanismo de autenticação Credenciais encaminháveis SSO Registro de usuários do S.O. local Registro de usuários LDAP Registro de usuários customizado
LTPASimSimSimSimSim
SWAMNãoNãoSimSimSim

Simple WebSphere Authentication Mechanism (SWAM): O mecanismo de autenticação SWAM é destinado a ambientes de tempo de execução do servidor de aplicativos simples, não distribuídos e únicos. A restrição do servidor de aplicativos único ocorre devido ao fato de que o SWAM não suporta credenciais encaminháveis, como o SWAM é destinado a um único processo do servidor de aplicativos, a conexão única (SSO) não é suportada.

O mecanismo de autenticação SWAM é adequado para ambientes simples, ambientes de desenvolvimento de software ou outros ambientes que não necessitam uma solução de segurança distribuída.

Trust Associations Interceptor

TAI e TAI++

Trust Associations Interceptor (TAI)

A intenção da interface do Trust Association Interceptor é que reverse proxy security servers (RPSS) existam como os pontos de entrada expostos para executar autenticação e autorização bruta, enquanto o WebSphere Application Server impinge o controle de acesso refinado adicional. As associações de confiança melhoram a segurança reduzindo o escopo e o risco de exposição.

O WebSphere Application Server suporta a conexão única (SSO) com serviços de autenticação periféricos, tal como proxies reversos por meio de "associações de confiança". Quando as associações de confiança estão ativadas, o WebSphere Application Server não precisa autenticar um usuário se um pedido chegar por meio de uma via a origem confiável que já executou a autenticação.

Figura 2. SSO com TAI
Trabalhando com TAI

Fluxo de pedido:

1. Um usuário solicita um recurso protegido pelo WebSEAL, o que serve como o proxy e intercepta todos os pedidos. O WebSEAL solicita as credenciais ao usuário e o usuário as fornece.

2. O WebSEAL autentica o usuário consultando seu registro de usuário LDAP. Ele também determina se o usuário possui acesso (ou seja, está autorizado a abrir) à URL solicitada.

3. Se a autenticação tiver êxito, o WebSEAL passará o pedido para o IBM HTTP Server usando a junção que foi configurada para ele. A junção do WebSEAL para o IBM HTTP Server é configurada para passar as informações iv-user e iv-groups no cabeçalho HTTP. A identificação do usuário final deve ser passada para o TAI em um cabeçalho chamado "iv-user", o qual é inserido pelo WebSEAL no cabeçalho do pedido de HTTP enviado do WebSEAL para o Application Server. Embora o WebSEAL possa ser configurado para passar a identidade do usuário final de outras formas, o cabeçalho iv-user é o único cabeçalho suportado pelo TAI. A senha do usuário final não é passada no cabeçalho HTTP.

4. O arquivo de plug-in do Application Server verifica a raiz de contexto da URL solicitada, determina o Application Server de destino ou clone, e encaminha o pedido para ele.

5. O TAI no WebSphere Application Server (para o qual o TAI deve estar ativado) processa o pedido. Após o TAI processar com êxito, o Application Server cria um cookie de autenticação de usuário criptografado chamado Token LTPA. Este cookie, que é exclusivo para cada usuário para cada sessão, (ou seja, se o mesmo usuário efetuar login várias vezes, ele verá um cookie diferente criado a cada login) é persistente (geralmente duas horas) e dura até o final da sessão do usuário. Portanto, o TAI não precisa processar todos os pedidos do usuário.

6. Após o TAI aceitar a identificação do usuário final e criar um token LTPA, o WebSphere Portal executará consultas adicionais no LDAP, tal como informações de grupo. Ele consulta o mapeamento de recursos a partir do banco de dados e, em seguida, exibe a página do portal.

  • Diferenças entre TAI e TAI++

A implementação TAI trabalha com os dados de credenciais. O WebSphere Application Server usa as informações para impingir políticas de segurança.

Tabela 6. As diferenças entre TAI e TAI++
TAM TAI (Trust Associations Interceptor) TAM TAI++ (Trust Associations Interceptor plus plus)
Isso está obsoleto.Essa é a versão preferencial
O TAI retorna um ID de usuário que representa o usuário final.O TAI++ retorna um sujeito que representa o usuário final.
Associações de confiança são suportadas desde o WebSphere Application Server v3.5. Uma limitação do TAI é que ele pode fornecer apenas o ID do usuário ao tempo de execução do WebSphere Application Server.A interface do TAI foi estendida no WebSphere Application Server v5.1.1 e no WebSphere Application Server v6.0 e posterior para suportar o retorno de informações completas de credenciais.
Após o TAI ser invocado, procuras adicionais no registro de usuários foram necessárias para criar as diversas credenciais necessárias para autorização (mesmo se essas informações já estavam contidas no pedido).Nenhuma pesquisa adicional no registro de usuários é necessária após a invocação de TAI++. (Entretanto, o WebSphere Portal pode realizar chamadas adicionais para o registro para construir atributos idênticos)
Não aplicável para TAI.Esteja ciente de que se o WebSphere Application Server participa em um cluster ou realiza chamadas EJB de recebimento de dados, a propagação de credenciais deve estar ativada no WebSphere Application Server.
Isso é suportado no WebSEAL v4.1, 5.1 e v6.0.A interface do TAI++ suporta o WebSEAL v5.1 e v6.0, mas não suporta o WebSEAL v4.1.

O leitor do artigo pode usar as diferenças acima como uma entrada para realizar uma seleção de técnicas SSO a serem usadas nesse ambiente.

Ativando SSL entre WebSEAL e servidores de backend usando GSKit Utility

O SSL pode ser uma boa forma para atender seus requisitos de segurança. No nível de protocolo, o SSL fornece identificação, autenticação, integridade e confidencialidade. No mundo real, é muito importante usar comunicação segura entre esses servidores corporativos. Para ativar o SSL, precisamos gerar certificados e distribuí-los entre os keystores dos servidores de comunicação.

Nesta seção, você verá o procedimento completo para criação de um novo conjunto de chaves. Aqui, apenas para o propósito de demonstração, estamos usando certificados autoassinados.

O IBM Global Security Kit (GSKit) fornece uma interface gráfica com o usuário (GUI) e uma interface de linha de comandos (CLI) para criação de chaves para o SSL. O utilitário GUI é conhecido como "gsk7ikm" e o utilitário CLI é conhecido como "gsk7cmd". O procedimento para a GUI é explicado nas seções a seguir. O arquivo CLI para o mesmo é fornecido em um download.

Figura 3. Distribuição de chaves
A sessão tempo limite 1

Distribuição de chaves

Etapas de alto nível:-

1) Criação do arquivo keystore do servidor

2) Criação do arquivo keystore do cliente

3) Criação do arquivo keystore do plug-in e inclusão do certificado do servidor

4) Criação do arquivo keystore de confiança do servidor e inclusão de certificados do servidor, cliente e plug-in

5) Criação do arquivo de confiança do cliente e inclusão de certificados do servidor e do cliente

6) Configuração do WebSphere Application Server e do plug-in

7) Configuração do servidor WebSEAL

1) Criação do arquivo keystore do servidor

Figura 4. Criação do keystore do servidor
A sessão tempo limite 1

Crie um novo certificado autoassinado conforme mostrado abaixo

Figura 5. Criação de keystore do servidor
A sessão tempo limite 1

Extraia o certificado para o arquivo chamado "Server.arm".

Figura 6. Criação do keystore do servidor
A sessão tempo limite 1

2) Criação do arquivo keystore do cliente

Siga o mesmo procedimento que o keystore do servidor para criação do arquivo keystore do cliente. Especifique o nome do arquivo do banco de dados de chaves como "ClientKey.jks". Crie o novo certificado autoassinado e extraia o certificado para o arquivo como "Client.arm".

3) Criação do arquivo keystore do plug-in

Siga o mesmo procedimento realizado para a criação da chave do servidor. Selecione o tipo de banco de dados de chaves como "CMS" em vez de JKS e crie o arquivo-chave como "PluginKey.kdb". Crie o novo certificado autoassinado e extraia o certificado para o arquivo como "Plugin.arm".

Inclua o certificado do servidor do arquivo para o arquivo do banco de dados de chaves do plug-in.

Figura 7. Criação do arquivo keystore do plug-in
A sessão tempo limite 1

Especifique o rótulo como "WebSphere Server CA" e clique em "OK".

4) Criação do arquivo keystore de confiança do servidor e inclusão de certificados do servidor, cliente e plug-in.

Figura 8. Criação do arquivo keystore de confiança do servidor
A sessão tempo limite 1

Inclua o certificado de cliente do arquivo para "Servertrust.jks"

Figura 9. Criação do arquivo keystore de confiança do servidor
A sessão tempo limite 1

Especifique o rótulo como "WebSphere Client CA" e clique em "OK".

De forma semelhante, inclua os certificados "Serverkey.arm" e "plugin.arm" do arquivo para "ServerTrust.jks".

Seu console agora deverá exibir "WebSphere Plug-in CA", "WebSphere Server CA" e "WebSphere Client CA" na lista, conforme mostrado abaixo.

Figura 10. Criação do arquivo keystore de confiança do servidor
A sessão tempo limite 1

5) Criando arquivo keystore de confiança do cliente e incluindo certificados do servidor e do cliente.

Siga o mesmo procedimento acima para a criação do arquivo-chave de confiança do cliente chamado "ClientTrust.jks", assim como a inclusão do certificado do servidor e do cliente no certificado existente

Seu console agora deverá conter "WebSphere Server CA" e "WebSphere Client CA" na lista, conforme mostrado na figura abaixo.

Figura 11. Criando o arquivo keystore de confiança do cliente
A sessão tempo limite 1

6) Atualizando o WebSphere Application Server

Configure o WebSphere Application Server para usar as novas chaves.

Acesso o Console Administrativo:

1) Selecione Segurança -> SSL -> <célula>/DefaultSSLSettings

2) Altere as seguintes entradas para refletir o caminho e as senhas das novas chaves -> Clique em OK

Key File Name: ${USER_INSTALL_ROOT}/etc/ServerKey.jks
Key File Password: <ServerKey.jks Password>
Trust File Name: ${USER_INSTALL_ROOT}/etc/ServerTrust.jks
Trust File Password: <ServerTrust.jks Password>
Figura 12. Configuração do SSL do WebSphere
A sessão tempo limite 1

Clique para ver a imagem maior

Figura 12. Configuração do SSL do WebSphere

A sessão tempo limite 1

Observação: Se você estiver em um ambiente ND, precisará atualizar o <dmgr>/DefaultSSLSettings, assim como as entradas acima.

3) Salve as alterações e efetue logout

4) Reinicie o WebSphere Server

Observação: Se você estiver em um ambiente ND, precisará reiniciar todos os servidores, agentes de nós e o Deployment Manager para que as novas configurações tenham efeito em toda a célula

Atualizando o arquivo sas.client.props:

1) Abra o arquivo $WAS_HOME/properties/sas.client.props em um editor
2) Altere as seguintes linhas no arquivo sas.client.props para refletir as novas
configurações SSL -> Salve o arquivo
com.ibm.ssl.keyStore=C\:/Program Files/WebSphere/AppServer/etc/ClientKey.jks
com.ibm.ssl.keyStorePassword=<ClientKey.jks Password>
com.ibm.ssl.trustStore=C\:/Program Files/WebSphere/AppServer/etc/ClientTrust.jks
com.ibm.ssl.trustStorePassword=<ClientTrust.jks Password>

Observação:-  
O caminho para os seus arquivos-chave
será relativo à instalação do WebSphere e plataforma

Atualizando o arquivo soap.client.props:

1) Abra o arquivo $WAS_HOME/properties/soap.client.props em um editor
2) Altere as seguintes linhas no arquivo soap.client.props para refletir as novas
configurações SSL -> Salve o arquivo
com.ibm.ssl.keyStore=C\:/Program Files/WebSphere/AppServer/etc/ClientKey.jks
com.ibm.ssl.keyStorePassword=<ClientKey.jks Password>
com.ibm.ssl.trustStore=C\:/Program Files/WebSphere/AppServer/etc/ClientTrust.jks
com.ibm.ssl.trustStorePassword=<ClientTrust.jks Password>

Observação:-  O caminho para os seus arquivos-chave 
será relativo à instalação do WebSphere e
plataforma

Atualizando o arquivo tghe plugin-cfg.xml:

1) Abra o arquivo $WAS_HOME/config/cells/plugin-cfg.xml em um editor.
2) Altere as seguintes linhas no arquivo "plugin-cfg.xml" para refletir a nova chave SSL
do plug-in ->. Salve o arquivo.
<Property Name="keyring"
	Value="C:\Program Files\WebSphere\AppServer\etc\PluginKey.kdb"/>
<Property Name="stashfile"
	Value="C:\Program Files\WebSphere\AppServer\etc\PluginKey.sth"/>

Observação:-  O caminho para os seus
arquivos-chave será relativo à instalação do WebSphere e
plataforma.
Observação:-  Será necessário alterar todos os transportes 
que usam HTTPS no arquivo "plugin-cfg.xml".

3) Reinicie seu servidor da Web para que as novas alterações entrem em efeito.

Importando o certificado para o WebSEAL

1) Abra um arquivo do banco de dados de chaves (KDF) do WebSEAL
selecionando "Arquivo do Banco de Dados de Chaves" -> "abrir"
2) Insira as seguintes informações para criar o arquivo-chave -> Clique em OK.
Selecione a partir do local : C:\Program Files\Tivoli\pdweb\www-default\certs\pdsrv.kdb
3) Insira uma senha para o seu arquivo-chave -> Clique em OK.
4) Clique no botão Importar Chave.
5) Insira as seguintes informações para incluir o certificado 
público do servidor -> Clique em OK.
Nome do Arquivo de Certificado: ServerKey.arm
Local: C:\Program Files\WebSphere\AppServer\etc
6) Insira uma senha para o certificado público de chave do servidor -> Clique em OK.
7) Salve e Saia.

Configurando conexão única para o WebSphere Portal

Gerenciamento de sessões do WebSphere Portal e logout usando o servidor WebSEAL

O WebSEAL mantém um cache de sessão que contém informações de segurança referentes a todos os usuários autorizados. Como parte da manutenção deste cache, cronômetros são usados para impingir restrições de segurança na duração de uma sessão de usuário, assim como na quantidade de tempo ocioso permitido. As sessões expiradas são removidas do cache do WebSEAL, destruindo a sessão do usuário.

O WebSphere Portal também mantém um cache de sessão para todos os usuários autenticados. Esse cache é gerenciado pelo WebSphere Portal Server e possui semelhantes restrições de segurança com base em tempo. Ao integrar o WebSEAL e o WebSphere Portal, torna-se necessário compreender as implicações desses caches de sessões distintos e como precisam ser gerenciados.

O WebSEAL é geralmente configurado para fornecer conexão única (SSO) para servidores HTTP de backend. Isso significa que são autenticados uma vez para o servidor WebSEAL. Sua identidade é, então, propagada de forma segura para os aplicativos de backend. Neste caso, o WebSEAL está fornecendo o gerenciamento dos dados de autenticação do usuário e, dessa forma, deverá ser considerado a origem principal das informações de sessão. Por esse motivo geralmente recomendamos que as sessões WebSEAL expirem um pouco antes de quaisquer sessões do servidor HTTP de backend. Essa recomendação ajuda a garantir que uma operação consistente seja fornecida ao usuário. Se um aplicativo HTTP de backend esgotou o tempo limite dos dados da sessão antes da sessão do WebSEAL, por exemplo, o usuário poderá receber erros do aplicativo de backend.

O WebSphere Portal, por padrão, possui um tempo limite de inatividade de 30 minutos e tempo limite de sessão de 2 horas em suas sessões de usuários. Esses valores podem ser alterados, conforme mostrado na figura abaixo.

Figura 13. Configuração de tempo limite da sessão
A sessão tempo limite 1

Se a SSO estiver configurada entre o WebSEAL e o WebSphere Portal e a sessão WebSphere Portal esgotar o tempo limite antes da sessão WebSEAL, a página de erro de sessão expirada será exibida para o usuário. Em muitos casos, os administradores podem simplesmente configurar o WebSphere Portal para não mostrar esse erro. Configure o parâmetro "timeout.resume.session=true" para desativar isso.

Figura 14. Configuração de tempo limite da sessão
A sessão tempo limite 2

Quando o WP está configurado para não mostrar este erro, se uma sessão de usuário esgotar o tempo limite de inatividade ou expirar, o usuário será simplesmente autenticado novamente e uma nova sessão será criada. Isso ocorrerá sem a interação pelo usuário e ocorrerá por meio da integração da SSO fornecida pelo WebSEAL e WebSphere Portal.

Cenário de integração

Etapas da Integração ITDS e WP

Observação:

Neste cenário, o WebSphere Portal e o Tivoli Access Manager estão compartilhando um registro de usuário comum.

A seção a seguir descreve etapas para configurar o WebSphere Portal com o IBM Tivoli Directory Server.

Procure pelo arquivo PortalUser.ldif no diretório inicial do WebSphere Portal, modifique o sufixo para o qual seu servidor LDAP está configurado e importe o arquivo ldif para o Tivoli Directory Server usando o seguinte comando idsldapadd.

Listagem 7. Comando de importação de LDIF
cmd>idsldapadd -D cn=root -w <senha> -p <porta> -c -f PortalUser.ldif

Execute os comandos pdadmin para importar os seguintes usuários e grupo para o Tivoli Access Manager após concluir com êxito o comando acima: Grupo: wpsadmins Usuários: wpsbind e wpsadmin

Lista 8. Comando de importação pdadmin
pdadmin -a sec_master -p <senha>
pdadmin sec_master> group import wpsadmins cn=wpsadmins,cn=groups,o=ibm,c=in
pdadmin sec_master> user import wpsbind uid=wpsbind,cn=users,o=ibm,c=in
pdadmin sec_master> user import wpsadmin uid=wpsadmin,cn=users,o=ibm,c=in
pdadmin sec_master> user modify wpsbind account-valid yes
pdadmin sec_master> user modify wpsadmin account-valid yes

Execute os seguintes comandos para verificar usuários e grupos no TAM:

Lista 9. Verificar usuários e grupos
pdadmin -a sec_master -p passw0rd user list * 0
pdadmin -a sec_master -p passw0rd group list * 0

Agora podemos iniciar usando WPSconfig.bat para configurar o WebSphere Portal com outros produtos Tivoli.

Agora desativaremos a segurança do WebSphere Portal; para isso precisamos modificar alguns parâmetros em wpconfig.properties. Use o nome da chave na seguinte tabela para procurar no arquivo de propriedades e use valores fornecidos na tabela.

Lista 10. Alterações na configuração do portal
Seção: Configuração do WebSphere Application Server
WasUserid						wpsbind
WasPassword 					wpsbind

Seção: Configuração do WebSphere Portal
PortalAdminid 					wpsadmin
PortalAdminPwd 					wpsadmin
PortalAdminGroupId 				wpsadmins

Abra o prompt de comandos e acesse o diretório portal_server_root/config.

Insira o seguinte comando para executar a tarefa de configuração:

Lista 11. Desativar segurança
WPSconfig.bat disable-security

Observação:- Prossiga apenas se você receber uma mensagem informando Construção Bem-sucedida . Se alguma das tarefas de configuração falhar, verifique os valores no arquivo wpconfig.properties.

Após cada etapa, use o seguinte comando para verificar os estados dos servidores.

Lista 12. Verificando o estado do servidor
C:\Program Files\WebSphere\AppServer\bin>serverStatus.bat -all

Observação:- O status do Application Server deve ser INICIADO

Agora é hora de configurar o WebSphere Portal para usar a segurança LDAP. Neste artigo, estamos usando o Tivoli Directory Server como o registro de usuários. Antes de executar o comando para ativar a segurança LDAP, precisamos modificar alguns parâmetros em wpconfig.properties. Use o nome da chave na seguinte tabela para procurar no arquivo de propriedades e use valores fornecidos na tabela.

Observação:- Para o propósito de demonstração, estamos usando o mesmo usuário e o mesmo grupo para todas as funções. Você pode criar e usar diferentes usuários e grupos para cada função.

Lista 13. Integrar Portal com LDAP e TAM
Seção: Configuração do WebSphere Portal
PortalAdminId 				uid=wpsadmin,cn=users,o=ibm,c=in
PortalAdminIdShort 			wpsadmin
PortalAdminPwd 				wpsadmin
PortalAdminGroupId 			cn=wpsadmins,cn=groups,o=ibm,c=in
PortalAdminGroupIdShort 		wpsadmins
WpsContentAdministrators 		uid=wpsadmin,cn=users,o=ibm,c=in
WpsContentAdministratorsShort		wpsadmin
WpsDocReviewer 				uid=wpsadmin,cn=users,o=ibm,c=in
WpsDocReviewerShort 			wpsadmin

Seção: Configuração do LDAP
LDAPHostName 				dw_server.in.ibm.com
Lookaside 				true
LDAPPort 				389
LDAPAdminUId 				cn=root
LDAPAdminPwd 				passw0rd
LDAPServerType 				IBM_DIRECTORY_SERVER
WWmmSystemId 				uid=wpsbind,cn=users,o=ibm,c=in
WmmSystemIdPassword 			wpsbind
LDAPSuffix 				o=ibm,c=in
LdapUserPrefix 				uid
LDAPUserSuffix 				cn=users
LdapGroupPrefix 			cn
LDAPGroupSuffix 			cn=groups
LDAPUserObjectClass 			inetOrgPerson
LDAPGroupObjectClass 			groupOfUniqueNames
LDAPGroupMember 			uniqueMember
LDAPUserFilter 				(&(uid=%v)(objectclass=inetOrgPerson))
LDAPGroupFilter 			(&(cn=%v)(objectclass=groupOfUniqueNames))
LTPAPassword 				passw0rd
LTPATimeout 				120
SSODomainName 				in.ibm.com

Seção: Entradas de configuração relacionadas ao Tivoli Access Manager
PDAdminPwd 				passw0rd
PDServerName 				dw_server.in.ibm.com
TamHost 				dw_server.in.ibm.com
PDPolicyServerList 			dw_server.in.ibm.com:7135:1
PDAuthzServerList 			dw_server.in.ibm.com:7136:1
JunctionPoint 				/dw_server_tai
WebSealInstance 			Webseal_instance-webseald-dw_server.in.ibm.com
WebSealHost 				dw_server.in.ibm.com
WebSealPort 				80,443
WebSealUser 				wpsbind
BaUserName	 			wpsbind
BaPassword 				wpsbind
PDRoot 					/dw_server

Salve e feche o arquivo wpconfig.properties. Abra o prompt de comandos e acesse o diretório portal_server_root/config.

Insira o seguinte comando para executar a tarefa de configuração:

Lista 14. Ativar segurança
WPSconfig.bat enable-security-ldap

Observação:- Prossiga apenas se receber a mensagem informando Construção bem sucedida para o comando acima.

Após cada etapa, use o seguinte comando para verificar os estados dos servidores.

Lista 15. Verificando o status do servidor
C:\Program Files\WebSphere\AppServer\bin>serverStatus.bat -all

Observação:- O status do Application Server deve ser INICIADO

Se a construção for concluída com êxito, inicie o server1 e o WebSphere Portal. Verifique se a segurança do LDAP (ITDS) está ativada ou não está usando o login de console.

Seção: Etapas para ativar a SSL entre componentes diferentes

Observação:- Ignore esta seção se a SSL não for necessária.

Consulte a seção "Ativando a SSL entre WebSEAL e Servidores de Backend Usando GSKit V7" para isso.

Salve e feche o arquivo wpconfig.properties. Abra o prompt de comandos e acesse o diretório portal_server_root/config.

Insira o seguinte comando para executar a tarefa de configuração:

Listagem 16. Configuração do TAM
WPSconfig.bat run-svrssl-config
WPSconfig.bat validate-pdadmin-connection
WPSconfig.bat enable-tam-all

Observação:- Prossiga apenas se receber a mensagem informando Construção bem-sucedida para todos os comandos acima.

Após cada etapa, use o seguinte comando para verificar os estados dos servidores.

Lista 17. Status do Servidor
C:\Program Files\WebSphere\AppServer\bin>serverStatus.bat -all

Observação:- O status do Application Server deve ser INICIADO

Seção: Configuração do WebSEAL

Observação:- Esta é apenas uma configuração de exemplo; há muitas formas de configuração do WebSEAL. Os únicos itens que são relevantes para o TAI são iv-creds e a senha simulada.

O local padrão do arquivo de configuração do WebSEAL é: <instalação_do_TAM>/PDWeb/etc/webseald-default.conf

Lista 18. Configuração do WebSEAL
[ba]
ba-auth = none

[junction]
basicauth-dummy-password = wpsbind
http-timeout = 300
https-timeout = 300

[forms]
forms-auth = both

[script-filtering]
script-filter = yes

Configurando a página de logout do WebSphere Portal

Você também pode precisar alterar o comportamento do logout. O comportamento preferido e padrão é para os usuários efetuarem logout do WebSphere Portal e reterem suas credenciais SSO do Access Manager. O Access Manager é, portanto, um produto SSO corporativo e está provavelmente fornecendo a SSO para mais de um WebSphere Portal. Entretanto, em alguns casos você pode preferir que, quando os usuários efetuarem logout do WebSphere Portal, suas credenciais do Access Manager também sejam destruídas. Se você deseja este comportamento, faça o seguinte:

Modifique o ConfigService.properties

  • Faça uma cópia do arquivo ConfigService.properties em:
    • <WP_ROOT>\config\properties\ConfigService.properties.
  • Edite o arquivo conforme especificado abaixo:
Lista 19. Configuração de Logout do WP
redirect.logout= true
redirect.logout.ssl= true ou false, dependendo de seu ambiente
redirect.logout.url= <protocolo>://<nome_do_host>/pkmslogout

Em que:

  • <protocol> é o protocolo da máquina WebSEAL (HTTP ou HTTPS).
  • <host_name> é a URL completa do WebSEAL.

O valor para redirect.logout.url deve aparecer em uma única linha.

Execute as seguintes etapas para executar a tarefa de configuração update-properties:

  • Localize o diretório /PortalServer/config
  • Digite a seguinte tarefa de configuração apropriada para seu sistema operacional em uma linha de comandos:
    • WPSconfig.bat update-properties

Nota :- Após executar todas essas tarefas, será necessário reiniciar WebSphere_Portal.

Teste o TAI++:

Agora que você concluiu todas as etapas, verifique se você obtém a SSO acessando sua versão desta URL:

https://<host_do_WebSEAL>:<porta>/dw_server_tai/wps/myportal

Nome de usuário: wpsbind

Senha: wpsbind

Resultado: Você deve obter a página THE myportal sem nenhum login de portal.

Figura 15. Início do WebSphere Portal
Início do WebSphere Portal

Parabéns! Você configurou com êxito a SSO entre o Tivoli Access Manager e o WebSphere Portal

Teste a página de Logout do TAI++:

Atualmente, você está com login efetuado na página the myportal. Teste as alterações efetuando login no portal e clicando no link Logout. Sua página deve redirecionar para uma página WebSEAL pkmslogout com uma mensagem dizendo: "Usuário wpsbind efetuou logout"

Resolução de problemas

Problema-I:- Esgotado o tempo limite da sessão durante a conexão única pelo WebSEAL para o WebSphere Portal

Solução :- Efetue login no console administrativo do WebSphere Selecione Recursos-> Provedores do Ambiente de Recursos -> WP ConfigService -> Propriedades customizadas Inclua um novo parâmetro como "timeout.resume.session" com valor "true" como tipo "Boolean". Reinicie o WebSphere Application Server.

Problema-II:- Falha da tarefa de configuração validate-pdadmin-connection

Solução :- Ao emitir a mensagem "Não é possível contatar servidor", a validade dos valores de ID e senha do PDAdmin precisa ser verificada no arquivo wpconfig.properties.

Problema-III:- Depurando o módulo de login do IBM® Tivoli Access Manager para E-business

Solução :- O Console Administrativo do WebSphere Application Server mantém os módulos de login para o WebSphere Portal. Para depurar o PDLoginModule fornecido pelo Tivoli Access Manager, acesse o Console Administrativo do WebSphere Application Server, procure pelo Login JAAS Portal_Login e inclua uma propriedade customizada para PDLoginModule com um nome de propriedade de "debug" e um valor "=true".

Problema-IV:- Verificando a configuração do TAM-TAI

Solução :-

  • No Console Administrativo do WebSphere Application Server, clique em Segurança > Segurança Global > Autenticação > Mecanismos de Autenticação >LTPA. Clique em Associação de Confiança sob Propriedades Adicionais
  • Sob Propriedades Gerais, localize Ativar Associação de Confiança. Se sua caixa estiver selecionada, então a associação de confiança já estará ativada. Se não estiver selecionada, selecione a caixa de opção e clique em "OK" para ativar a associação de confiança
  • Clique em "Salvar" na parte superior da tela sob Mensagem(ns). Clique em "Salvar" novamente, quando solicitado, para confirmar suas alterações
  • Clique em Segurança > Segurança Global > Autenticação > Mecanismos de Autenticação >LTPA. Clique em Associação de Confiança sob Propriedades Adicionais. Clique em Interceptores sob Propriedades Adicionais
  • O seguinte interceptor deverá ser listado:
    • com.ibm.ws.security.web.WebSealTrustAssociationInterceptor
  • Se ele não estiver listado, revise o ConfigTrace.log em busca de erros encontrados durante a tarefa enable-tam-tai de configuração e execute novamente a tarefa, se necessário.
  • Clique em "Salvar" na parte superior da tela sob Mensagem(ns). Clique em "Salvar" novamente quando solicitado, para confirmar suas alterações

Para obter mais informações sobre Resolução de Problemas, consulte a documentação do IBM WebSphere Portal v6.0 na seção Recurso

Conclusão

Este artigo fornece formas diferentes nas quais o LTPA, TAI pode ser configurado para integração do Tivoli Access Manager com o WebSphere Portal para autenticação. Ele também explica como esses mecanismos ajudam o WebSphere Portal e o Tivoli Access Manager WebSEAL Server a conseguir a conexão única. Você executou um cenário em que configurou o ambiente SSL para os plug-ins WebSphere Portal, Tivoli Access Manager e WebSphere.


Download

DescriçãoNomeTamanho
IBM Command Line Reference for SSL Key Generationcli.zip1KB

Recursos

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tivoli
ArticleID=407630
ArticleTitle=Conexão Única para um IBM WebSphere Portal por meio do IBM Tivoli Access Manager WebSEAL
publish-date=02182009