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.

Voltar para parte superior

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).

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:

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

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

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++

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.

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.

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.

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

Crie um novo certificado autoassinado conforme mostrado abaixo

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

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.

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.

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

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.

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.

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>
	

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

				
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

				
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.

				
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.

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.

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

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.

				
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

				
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:

				
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.

				
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:

				
WPSconfig.bat disable-security

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

				
C:\Program Files\WebSphere\AppServer\bin>serverStatus.bat -all

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.

				
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:

				
WPSconfig.bat enable-security-ldap

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

				
C:\Program Files\WebSphere\AppServer\bin>serverStatus.bat -all

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.

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:

				
WPSconfig.bat run-svrssl-config
WPSconfig.bat validate-pdadmin-connection
WPSconfig.bat enable-tam-all

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

				
C:\Program Files\WebSphere\AppServer\bin>serverStatus.bat -all

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

				
[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:

				

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:

Nome de usuário: wpsbind

Senha: wpsbind

Resultado: Você deve obter a página THE myportal sem nenhum login de 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.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

• Artigo relacionado aos guias de produtos Tivoli e WebSphere
  • IBM® Tivoli Access Manager 6.0 Install Guide
  • IBM® Tivoli Directory Server 6.0 Documentation
  • IBM® WebSphere Application Server Documentation
  • IBM® WebSphere portal v6.0 Documentation
  
  
• Faça o download das versões de avaliação de produtos IBM e comece a trabalhar com ferramentas de desenvolvimento de aplicativos e produtos de middleware a partir do DB2®, Lotus ®, Rational®, Tivoli® e WebSphere®.
  
  

Sobre os autores

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Técnicas de conexão única
• Lightweight third-party authentication
• Trust Associations Interceptor
• Ativando SSL entre WebSEAL e servidores de backend usando GSKit Utility
• Configurando conexão única para o WebSphere Portal
• Gerenciamento de sessões do WebSphere Portal e logout usando o servidor WebSEAL
• Cenário de integração
• Resolução de problemas
• Conclusão
• Download
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais