Índice. Índice Remissivo iii

Transcrição

1 Segurança

2 ii Segurança

3 Índice Segurança Segurança do WebSphere e Segurança do Java Práticas de Ambiente Seguras Comunicação SSL (Secure Sockets Layer) Terminologia SSL Autenticação SSL Uni e Bidirecional SSL em um Ambiente em Cluster Implementações de SSL Tipos de Arquivos de Certificado Comunicação Segura com Adaptadores Comunicação Segura com Aplicativos Customizados 8 Comunicação Segura com Middleware Suportado 10 Exemplo de Configurações SSL Antes de Iniciar Criando um Certificado Configurando SSL para o Servidor de Diretórios 14 Configurando SSL no WebSphere Application Server Configurando o IBM Tivoli Identity Manager Server Testando a Comunicação SSL Entre Servidores.. 17 Movendo o Servidor HTTP para Segurança e Desempenho Adicionais SSL para o IBM HTTP Server e Plug-in do WebSphere Application Server Configurando Conexão Única Configurando Conexão Única com o WebSEAL 23 Mapeamento de Contas Alterando a Página de Logoff Definindo Contas do Usuário do IBM Tivoli Access Manager Definindo Grupos do IBM Tivoli Access Manager 28 Incluindo uma Conta de Usuário do IBM Tivoli Access Manager em um Grupo Definindo uma Junção SSL do WebSEAL Definindo uma Junção TCP ou SSL do WebSEAL 30 Definindo ACLs do IBM Tivoli Access Manager 33 Concedendo Acesso às ACLs do IBM Tivoli Access Manager Associando a Junção WebSEAL às ACLs Configurando o IBM Tivoli Identity Manager para Conexão Única Acessando Consoles do IBM Tivoli Identity Manager Comandos Utilizados com Freqüência para Configurar Conexão Única Configurando o Intervalo de Tempo Limite da Sessão para o IBM Tivoli Identity Manager Índice Remissivo iii

4 iv Segurança

5 Segurança Talvez você precise configurar a segurança e a autenticação adicional para o ambiente do seu servidor, incluindo a segurança global do WebSphere Application Server, dividida em segurança do aplicativo e segurança administrativa, e a do Java 2 e para adaptadores e outros aplicativos, como um servidor de diretório LDAP, implementando a autenticação SSL (Secure Sockets Layer). Esses tópicos de segurança incluem práticas em proteger o acesso a dados e logs que contêm informações sigilosas. As boas práticas também incluem a implementação de uma função de conexão única utilizando a segurança da Web do IBM Tivoli Access Manager. A configuração permite a um usuário efetuar login uma vez e propaga a identidade do usuário ao IBM Tivoli Identity Manager, eliminando a necessidade de outro login. Segurança do WebSphere e Segurança do Java 2 O IBM Tivoli Identity Manager utiliza dois tipos de segurança: a segurança global do WebSphere Application Server, que é dividida em segurança administrativa e segurança do aplicativo, e também a segurança do Java 2. A segurança global reforça a autenticação e a autorização baseada em função. Quando a segurança global do WebSphere Application Server for ativada, você não será capaz de efetuar logon no Console Administrativo do WebSphere Application Server sem um ID do usuário e senha. A segurança do Java 2 pode, opcionalmente, ser ativada ou desativada quando a segurança global do WebSphere Application Server está ativada e direcionada para o uso dos recursos do sistema, como gravação no sistema de arquivos, atendimento em um soquete e chamadas para APIs. A segurança Java 2 é configurada em um arquivo was.policy. Para obter mais informações sobre como configurar a segurança global do WebSphere Application Server e também como configurar a segurança do Java 2, consulte o Centro de Informações do WebSphere Application Server. Para obter mais informações sobre como instalar e configurar o IBM Tivoli Identity Manager com segurança global do WebSphere Application Server ativada, consulte o IBM Tivoli Identity Manager: Guia de Instalação e Configuração. Práticas de Ambiente Seguras Estas práticas podem ajudar a garantir um ambiente do IBM Tivoli Identity Manager seguro. 1

6 Tabela 1. Práticas para um Ambiente do IBM Tivoli Identity Manager Seguro Determinados dados sigilosos nestas áreas Certifique-se de que estas práticas ocorram Dados do Banco de Dados Restrinja o acesso ao sistema operacional para arquivos do banco de dados Limite os privilégios das contas do sistema operacional (administrativo, privilégio de raiz ou DBA) para o mínimo necessário, altere as senhas padrões e reforce as alterações de senha periódicas. Consulte o documento do fornecedor do banco de dados sobre segurança para obter mais detalhes. Logs do Banco de Dados Restrinja o acesso ao sistema operacional para arquivos de log e rastreio. Limite os privilégios das contas do sistema operacional (administrativo, privilégio de raiz ou DBA) para o mínimo necessário, altere as senhas padrões e reforce as alterações de senha periódicas. Consulte o documento do fornecedor do banco de dados sobre segurança para obter mais detalhes. Backups de Banco de Dados Os backups de banco de dados devem ser armazenados em segurança e em locais seguros de retenção e devem ser guardados contra vazamentos ou exposição de informações sigilosas e confidenciais. Consulte a segurança dos fornecedores do banco de dados e os documentos de backup para obter detalhes. Dados LDAP Os dados LDAP que contêm informações sigilosas devem ser manipulados com segurança, inclusive desativando leitura anônima e ativando SSL e restringindo o acesso a sistemas operacionais privilegiados e autorizados e a usuários de aplicativos apenas. Consulte o documento do fornecedor do servidor de diretórios LDAP sobre segurança para obter mais detalhes. Logs LDAP Restrinja o acesso aos arquivos de log no diretório de log do servidor de diretórios a sistemas operacionais privilegiados e autorizados e usuários de aplicativos apenas, o que é especialmente importante se o log de auditoria do servidor de diretórios estiver ativado. Consulte o documento do fornecedor do servidor de diretórios sobre segurança para obter mais detalhes. Backups LDAP Arquivos LDIF contendo informações sigilosas que devem ser armazenadas de forma segura e manipuladas com segurança. Logs do IBM Tivoli Identity Manager Restrinja o acesso a logs do ITIM contendo informações sigilosas no diretório path/ibm/tivoli/common/ctgim. 2 Segurança

7 Tabela 1. Práticas para um Ambiente do IBM Tivoli Identity Manager Seguro (continuação) Determinados dados sigilosos nestas áreas Certifique-se de que estas práticas ocorram Diretórios sob ITIM_HOME Restrinja o acesso a diretórios em ITIM_HOME para dados, configuração e install_logs contendo informações sigilosas. Tráfego de Rede Restrinja o tráfego de rede somente ao necessário pela implementação. Se você grava seu próprio aplicativo e utiliza uma API do IBM Tivoli Identity Manager para recuperar dados sigilosos, criptografe os dados antes de enviar os dados pela rede. Segurança do WebSphere Application Server Ative a segurança no WebSphere Application Server e desaprove a execução do WebSphere Application Server utilizando uma conta não-raiz. Comunicação SSL (Secure Sockets Layer) O protocolo SSL (Secure Sockets Layer) padrão de mercado, que utiliza certificados digitais assinados de uma CA (Autoridade de Certificação) para autenticação, é utilizado para proteger a comunicação em uma implementação do IBM Tivoli Identity Manager. O SSL fornece a criptografia dos dados trocados entre os aplicativos. Um aplicativo que age como um servidor SSL apresenta suas credenciais em um certificado digital assinado para verificar se um cliente SSL é a entidade que ele declara ser. Um aplicativo que age como um servidor SSL pode também ser configurado para requerer que o aplicativo que age como um cliente SSL apresente suas credenciais em um certificado, concluindo por meio disso uma troca de certificados bidirecionais. Terminologia SSL Esses termos se aplicam à comunicação SSL (Secure Sockets Layer) paraibm Tivoli Identity Manager. Servidor SSL O servidor SSL atende os pedidos de conexão dos clientes SSL. Por exemplo, o IBM Tivoli Directory Server pode ser um servidor SSL que ouve os pedidos de conexão do IBM Tivoli Identity Manager Server e do WebSphere Application Server. Cliente SSL O cliente SSL emite pedidos de conexão. Por exemplo, a máquina na qual o Tivoli Identity Manager Server eowebsphere Application Server estão instalados é o cliente SSL, que emite pedidos de conexão ao IBM Tivoli Directory Integrator. Certificados Assinados Um certificado digital assinado é um método padrão de mercado para verificar a autenticidade de uma entidade, como um servidor, um cliente ou aplicativo. Os certificados assinados são emitidos por uma autoridade de certificação terceirizada, mediante uma taxa. Alguns utilitários, como o utilitário ikeyman, também podem emitir certificados assinados. Uma Autoridade de Certificação ou certificado de CA precisa ser utilizado para verificar a origem de um certificado digital assinado. Segurança 3

8 Certificados de Signatário (Certificados de Autoridade de Certificação) Um certificado de CA (Autoridade de Certificação) deve ser utilizado para verificar a origem de um certificado digital assinado. Quando um aplicativo receber um certificado assinado de outro aplicativo, utilizará um certificado CA para verificar o originador do certificado. Muitos aplicativos, como navegadores da Web, são configurados com os certificados de CA de autoridades de certificação de renome para eliminar ou reduzir a tarefa de distribuir certificados de CA em todas as zonas de segurança em uma rede. Certificados Autoassinados Um certificado autoassinado contém informações sobre o proprietário do certificado e a assinatura do proprietário. Basicamente, é um certificado assinado e um certificado de CA em um só. Se você escolher utilizar certificados autoassinados, deverá extrair o certificado de CA dele para configurar o SSL. Armazenamento de Chaves SSL O armazenamento de chaves SSL é um arquivo de banco de dados de chave designado como um armazenamento de chaves. Ele contém o certificado SSL. Nota: O armazenamento de chaves e o armazenamento confiável podem ser o mesmo arquivo físico. Armazenamento Confiável SSL O armazenamento confiável SSL é um arquivo de banco de dados de chave designado como um armazenamento confiável. O armazenamento confiável SSL contém a lista de certificados de signatário (certificados de CA) que definem em quais certificados o protocolo SSL confia. Somente um certificado emitido por um desses signatários confiáveis relacionados é aceito. Nota: O armazenamento confiável e o armazenamento de chaves podem ser o mesmo arquivo físico. Autenticação SSL Unidirecional Para SSL unilateral, um armazenamento de chaves e um certificado são necessários apenas no lado do servidor SSL (tal como o Tivoli Directory Server) e um armazenamento confiável é necessário apenas no lado do cliente SSL (tal como o Tivoli Identity Manager Server). Autenticação SSL Bilateral (Autenticação do Lado do Cliente) Para SSL que utiliza autenticação SSL bilateral (lado do cliente), tanto um armazenamento de chaves com um certificado, e um armazenamento confiável contendo o certificado do signatário que emitiu o certificado do outro lado, são necessários no lado do servidor SSL e no lado do cliente SSL. Autenticação SSL Uni e Bidirecional A configuração da comunicação entre um servidor e o cliente SSL pode utilizar a autenticação SSL unilateral ou bilateral. Por exemplo, o cliente SSL é a máquina na qual o IBM Tivoli Identity Manager Server está instalado e o servidor SSL é o IBM Tivoli Directory Server. A autenticação unilateral cria um armazenamento confiável no cliente e um armazenamento de chaves no servidor. Nesse exemplo, o certificado A da CA existe no armazenamento confiável no cliente SSL e também no armazenamento de 4 Segurança

9 chaves no servidor SSL. Tivoli Identify Manager (cliente SSL) Armazenamento Confiável Tivoli Directory Integrator (servidor SSL) Armazenamento de chaves CA certificado A CA certificado A Figura 1. Comunicação SSL Unilateral A autenticação bilateral cria um armazenamento confiável e um armazenamento de chaves no cliente e também no servidor. Nesse exemplo, tanto no cliente como no servidor, há um certificado A da CA no armazenamento confiável e um certificado B da CA no armazenamento de chaves. Tivoli Identify Manager (cliente SSL) Armazenamento Confiável Tivoli Directory Integrator (servidor SSL) Armazenamento Confiável CA certificado A CA certificado B Armazenamento de chaves Armazenamento de chaves Certificado B Certificado A Figura 2. Comunicação SSL Bilateral Para obter mais informações sobre as etapas para configurar a comunicação SSL unilateral e bilateral entre o Tivoli Identity Manager Server e um adaptador do Tivoli Identity Manager, consulte o guia de instalação e configuração para o adaptador. SSL em um Ambiente em Cluster A configuração da comunicação entre um servidor e o cliente SSL pode utilizar a autenticação SSL unilateral ou bilateral. Por exemplo, o cliente SSL é a máquina na qual o IBM Tivoli Identity Manager Server está instalado e o servidor SSL é o IBM Tivoli Directory Server. Para configurar a autenticação SSL unilateral para um grupo de servidores do IBM Tivoli Identity Manager em um cluster do WebSphere Application Server, importe Segurança 5

10 os certificados da CA apropriados no armazenamento confiável utilizado em cada membro do servidor de aplicativos do cluster ou configure o armazenamento confiável do servidor de aplicativos com certificados da CA e copie o conteúdo desse armazenamento confiável para os outros membros do servidor de aplicativos no cluster. Para configurar a autenticação SSL bilateral para um cluster, você deve configurar cada membro do servidor de aplicativos para utilizar armazenamentos confiáveis e armazenamentos de chaves separados. O armazenamento confiável pode ser o mesmo arquivo comum com certificados de CA, copiado de um membro do servidor de aplicativos para os armazenamentos confiáveis dos outros membros do servidor de aplicativos (exatamente como você faria para uma autenticação SSL unilateral). Cada armazenamento de chaves deve ser exclusivo para cada membro do servidor de aplicativos e deve conter somente o certificado e chave privada do servidor de aplicativos (cliente). Alternativamente, você pode implementar uma configuração menos segura (por exemplo, para testar a conectividade), configurando um armazenamento de chaves comum com um único certificado e chave privada. Então, você exporta o certificado e a chave privada para um arquivo temporário (por exemplo, para um arquivo formatado PKCS12) e, em seguida, importa esse arquivo no armazenamento de chaves de cada membro do servidor de aplicativos no cluster. Implementações de SSL O IBM Tivoli Identity Manager Server utiliza várias implementações do protocolo SSL. O Tivoli Identity Manager Server utiliza as seguintes implementações do protocolo SSL: IBM Global Security Toolkit (GSKit) Utilizado pelos adaptadores do WebSphere Application Server, do IBM Tivoli Directory Server e do IBM Tivoli Identity Manager. IBM Java Secure Socket Extension (JSSE) Utilizado pelo Tivoli Identity Manager Server e pelo IBM Tivoli Directory Integrator OpenSSL Usado por adaptadores baseados em Tivoli Identity Manager Server Adapter Development Kit (ADK). Tipos de Arquivos de Certificado Certificados e chaves são armazenados em diversos tipos de arquivos. Arquivos que armazenam certificados e chaves podem ter os seguintes formatos:.pem Um arquivo de correspondência com mais privacidade, que tem a extensão de arquivo.pem, começa e termina com as seguintes linhas: -----BEGIN CERTIFICATE END CERTIFICATE----- Um formato de correspondência com mais privacidade suporta vários certificados digitais, incluindo uma cadeia de certificados. Se sua organização utiliza cadeia de certificados, utilize esse formato para criar certificados CA. 6 Segurança

11 .arm Um arquivo com extensão.arm contém uma representação ASCII codificada em base 64 de um certificado, incluindo sua chave pública, mas não sua chave privada. Um formato.arm é gerado e utilizado pelo utilitário IBM Key Management. Especifique esse formato para extrair um certificado autoassinado da máquina na qual o certificado autoassinado foi gerado para a máquina que utilizará o certificado autoassinado como o certificado CA..der Um arquivo com extensão.der contém dados binários. Esse formato pode ser utilizado para um único certificado, ao contrário de um arquivo com formato de correspondência com mais privacidade, que pode conter vários certificados. Especifique esse formato para extrair um certificado autoassinado da máquina na qual o certificado autoassinado foi gerado para a máquina que utilizará o certificado autoassinado como o certificado CA..pfx (PKCS12) Um arquivo PKCS12, com extensão.pfx, contém um certificado (certificado emitido por CA ou certificado autoassinado) e uma chave privada correspondente. Utilize esse formato para transferir o conteúdo de um armazenamento de chave para uma máquina separada. Por exemplo, você pode criar e instalar um certificado e uma chave privada usando o utilitário de gerenciamento de chaves, exportar o certificado e a chave para um arquivo PKCS12 e, em seguida, importar o arquivo para outro armazenamento de chave. Esse formato também é útil para converter de um tipo de implementação SSL para uma implementação diferente. Por exemplo, você pode criar e exportar um arquivo PKCS12 utilizando o utilitário IBM Key Management e, em seguida, importar o arquivo para outra máquina utilizando o utilitário OpenSSL CertTool. Comunicação Segura com Adaptadores O IBM Tivoli Identity Manager Server utiliza comunicação SSL ou SSH (Secure Shell) para se comunicar seguramente com os adaptadores suportados. A Figura 3 na página 8 ilustra como os links de comunicação segura podem ser configurados. Segurança 7

12 Tivoli Identity Manager Server S S L S S L SSL Tivoli Directory Integrator Outros Adaptadores A d ap t a d or SSH SSL Recurso Gerenciado UNIX Recurso Gerenciado LDAP CHAVE: SSL = SSL de uma Via ou Duas Vias SSH = Protocolo Secure Shell Figura 3. Comunicação Segura no Ambiente do IBM Tivoli Identity Manager Recursos gerenciados podem se comunicar com os adaptadores do IBM Tivoli Identity Manager utilizando os seguintes protocolos: v SSL Adaptadores como Windows Server Active Directory ou Lotus Notes podem ser configurados para utilizar a autenticação SSL para comunicação com o IBM Tivoli Identity Manager Server. Nem todos os adaptadores utilizam a mesma configuração SSL. Para mais informações, consulte o guia de instalação e configuração do adaptador específico. v SSH (Secure Shell) Protocolo SSH é utilizado entre o adaptador eorecurso gerenciado. Não é necessária configuração para utilizar o protocolo SSH. O uso de SSH entre o adaptador e os recursos gerenciados não pode ser desativado. No entanto, a configuração do SSH pode ser necessária no recurso gerenciado. Para mais informações, consulte os guias de instalação e configuração do adaptador do IBM Tivoli Identity Manager para Unix e Linux. Comunicação Segura com Aplicativos Customizados Se você desenvolver aplicativos customizados para acessar o IBM Tivoli Identity Manager Server, esses aplicativos devem aderir às diretrizes de programação descritas nesta seção. Essas diretrizes garantem que: v Limites de segurança compilados no Tivoli Identity Manager Server são observados rigorosamente. v Apenas as APIs autorizadas são usadas para comunicação entre os aplicativos customizados e de servidor. v As funções apropriadas são designadas a usuários e grupos de usuários que usam aplicativos customizados para acessar as funções do Tivoli Identity Manager. 8 Segurança

13 O Tivoli Identity Manager protege sua funcionalidade principal com uma camada de EJBs (beans enterprise Java) do gerenciador. Esses EJBs residem em uma camada sem privilégios do Tivoli Identity Manager Server que é ilustrada no Figura 4. Quando o Tivoli Identity Manager Server se comunica com um aplicativo cliente, cada método EJB de gerenciador assume um token assinado do responsável pela chamada para verificar a sua identidade, exceto quando o próprio método faz a autenticação. O responsável pela chamada obtém esse token assinado depois de fazer a autenticação no Tivoli Identity Manager Server. Figura 4. Camadas de Segurança no Tivoli Identity Manager Os seguintes tipos de aplicativos customizados podem ser criados para se comunicar com o Tivoli Identity Manager Server: Cliente Java independente Implementado como um cliente magro do WebSphere Application Server. Aplicativo da Web Implementado fora do WebSphere Application Server. Um aplicativo da Web pode invocar somente um subconjunto específico de APIs do Tivoli Identity Manager Server. Aplicativo corporativo, o mesmo JVM (Java Virtual Machine) Implementado na mesma instância do servidor (enrole.ear) como Tivoli Identity Manager Server. Aplicativo corporativo, JVM separado Implementado na mesma máquina do Tivoli Identity Manager Server, mas é executada como um processo JVM separado. Segurança 9

14 Servlets Implementado em uma máquina separada executando o WebSphere Application Server. Servlets não são implementados no contexto de um aplicativo da Web. Ao implementar os aplicativos customizados para se comunicar com o Tivoli Identity Manager Server, use as seguintes regras para garantir comunicação segura: v v v Permita somente que APIs publicadas acessem somente EJBs do gerenciador na área sem privilégios. Permita que aplicativos customizados usem somente as funções que as APIs fornecem. Garanta que o computador no qual o Tivoli Identity Manager Server é executado esteja sempre seguro. O WebSphere Application Server usa funções para gerenciar a autorização para componentes de aplicativos e outros objetos, incluindo nomes de grupo e usuário. Use as diretrizes descritas abaixo para designar funções em aplicativos customizados que fazem interface com o Tivoli Identity Manager. ITIM_SYSTEM Essa função é definida quando o Tivoli Identity Manager Server é implementado no WebSphere Application Server. ITIM_SYSTEM é usado pelos componentes do Tivoli Identity Manager Server. É autorizado para chamar todos os métodos EJB em camadas com e sem privilégios. Não designe quaisquer nomes de diretores ou IDs do usuário a esta função sem consulta anterior com um representante do IBM Tivoli. ITIM_CLIENT Essa função é autorizada para chamar somente métodos EJB de gerenciador na camada sem privilégios. Mapeie os usuários para esta função, nomes de grupo de usuários e outros diretores que executam menos tarefas restritas no Tivoli Identity Manager Server. Comunicação Segura com Middleware Suportado O IBM Tivoli Identity Manager Server utiliza SSL para comunicação segura com middleware suportado, como um servidor de diretórios. Sua configuração pode ser semelhante ao exemplo de configuração de cluster em Figura 5 na página Segurança

15 Navegador IBM HTTP Server Plug-in de Servidor da Web do WebSphere } WebSphere Application Server Tivoli Identity Manager Server SSL SSL SSL Banco de Dados Tivoli Identity Manager Armazém de Dados LDAP Figura 5. Configuração Inicial Depois da instalação inicial, você pode configurar os links de comunicação segura entre o IBM Tivoli Identity Manager Server e estes aplicativos: v Servidor de Diretórios v Servidor HTTP v Navegador da Web v Outro middleware suportado Exemplo de Configurações SSL As configurações SSL de exemplo incluem comunicação segura entre o IBM Tivoli Identity Manager Server e o servidor de diretórios e entre um servidor HTTP e um navegador da Web. Na Tabela 2, o primeiro aplicativo é o cliente SSL e o segundo aplicativo é o servidor SSL: Tabela 2. Exemplo de Configurações SSL Cliente SSL IBM Tivoli Identity Manager Server Servidor HTTP (IBM HTTP Server) Navegador da Web Servidor SSL Servidor de Diretórios LDAP IBM Tivoli Identity Manager Server IBM Tivoli Identity Manager Server SSL de Uma Via SSL de Duas Vias Seu site pode precisar de configuração adicional para autenticação SSL com o IBM Tivoli Identity Manager Server. Antes de Iniciar Antes de começar a configurar o SSL para comunicação segura, instale e configure o IBM Tivoli Identity Manager Server. Em seguida, localize o IBM GSKit (Global Security Kit) para gerar certificados. Segurança 11

16 Conclua estas tarefas: 1. Instale e configure o Tivoli Identity Manager Server e o middleware suportado necessário, incluindo o servidor de diretórios. Esse exemplo supõe que exista uma configuração de cluster e que o servidor de diretórios esteja em uma máquina separada. 2. Certifique-se de que a configuração inicial esteja executando corretamente. Para obter informações adicionais, consulte IBM Tivoli Identity Manager: Guia de Instalação e Configuração. 3. Localize o IBM GSKit (Global Security Kit), que está incluído no IBM Tivoli Directory Server que a configuração inicial instala. Por exemplo, localize o diretório path/local/ibm/gsk7/bin no computador que possui o Tivoli Directory Server, em que path é um valor como usr. O pacote GSKit fornece o utilitário de gerenciamento de chaves ikeyman (gsk7ikm), que você pode utilizar para criar bancos de dados de chaves, pares de chaves pública-privada e pedidos de certificados. As etapas a seguir presumem que você utiliza o utilitário ikeyman para criar certificados autoassinados para comunicação segura. Alternativamente, você pode utilizar o Console Administrativo do WebSphere Application Server para criar um certificado autoassinado. Um certificado digital autoassinado é um certificado digital temporário que você emite para você mesmo, sendo você mesmo a autoridade de certificação (CA). Quando o teste estiver concluído, substitua o certificado autoassinado por um certificado assinado por um certificado de CA de uma autoridade de certificação bem-conhecida. Criando um Certificado Use o utilitário ikeyman para criar um certificado autoassinado e extraia o certificado para torná-lo disponível para comunicação segura. Antes de Iniciar Dependendo de como o administrador customizou o seu sistema, você poderá não ter acesso a essa tarefa. Para obter acesso a essa tarefa, ou ter alguém que a conclua para você, entre em contato com o administrador do sistema. Por Que e Quando Desempenhar Esta Tarefa O utilitário ikeyman está incluído no IBM Tivoli Directory Server. Para criar um certificado digital autoassinado, conclua estas etapas: 1. Inicie o utilitário ikeyman. Por exemplo, no diretório /usr/local/ibm/gsk7/ bin, digite este comando: gsk7ikm 2. Se o utilitário ikeyman não puder localizar Java, execute este comando: export JAVA_HOME=opt/IBM/ldapv6.1/java/jre 3. Na página Gerenciamento de Chaves IBM, clique em Arquivo do Banco de Dados de Chave Abrir Novo. 4. Selecione um tipo de banco de dados padrão do CMS. 5. No campo Nome do Arquivo, digite um nome para o arquivo do banco de dados principal do CMS. Por exemplo, digite: LDAPSERVER_TEST1234.kbd 12 Segurança

17 Por exemplo, o valor especifica application_serverhostname em que application é o servidor de diretórios e serverhostname é o computador que possui o servidor de diretórios. 6. No campo Local, especifique um local para armazenar o arquivo de banco de dados de chave. Por exemplo, digite /certs. 7. Clique em OK. 8. No menu Senha que é exibido, digite e confirme uma senha como Pa$$word1. Então, especifique a senha com maior intensidade possível e também especifique Ocultar a Senha para um Arquivo? Clique em OK. 9. Clique em Criar Novo Certificado Autoassinado e especifique um rótulo que coincida com o nome do arquivo do banco de dados principal do CMS, como LDAPSERVER_TEST1234. Esse exemplo utiliza o mesmo nome (LDAPSERVER_TEST1234) para o nome do certificado eoarquivo do banco de dados de chave que contém o certificado. 10. Digite IBM no campo Organização, aceite os demais valores padrão do campo e, então, clique em OK. Agora existe um certificado autoassinado, incluindo chaves pública e privada. 11. Para uso subseqüente com clientes, extraia o conteúdo do certificado em um arquivo ASCII Codificado em Base-64. Conclua estas etapas: a. Selecione Extrair Certificado. b. Especifique o tipo de dados dos Dados DER Binários. Um arquivo com extensão.der contém dados binários. Esse formato pode ser utilizado somente para um único certificado. Especifique esse formato para extrair um certificado autoassinado. c. Especifique o nome do arquivo de certificado que você criou, como LDAPSERVER_TEST1234.der. d. Especifique um local como /certs, no qual você armazenou anteriormente o arquivo do banco de dados principal e. Clique em OK. 12. Verifique se o diretório /certs contém os seguintes arquivos: Tabela 3. Arquivos no Diretório /certs Arquivo LDAPSERVER_TEST1234.crl LDAPSERVER_TEST1234.der LDAPSERVER_TEST1234.kbd LDAPSERVER_TEST1234.rdb LDAPSERVER_TEST1234.sth Descrição Não utilizado nesse exemplo. O certificado. Arquivo de banco de dados de chave que possui o certificado. Não utilizado nesse exemplo. Arquivo stash que possui a senha Nota: Se você estiver usando um certificado existente ou recentemente adquirido de uma CA, copie-o para o diretório /certs no sistema de arquivo raiz do servidor de diretório. Alternativamente, você pode utilizar o Console Administrativo do WebSphere Application Server para criar um certificado autoassinado. Clique em Segurança Certificado SSL e Gerenciamento de Chaves Gerenciar Configurações de Segurança de Terminal {Entrada Saída} Segurança 13

18 14 Segurança configuração_ssl Armazenamento de Chaves e Certificados [armazenamento de chaves]. Nas Propriedades Adicionais, clique em Certificados pessoais e, em seguida, clique em Criar um certificado autoassinado. O que Fazer Depois Para obter informações adicionais, consulte estes recursos: v Tópicos sobre como proteger as comunicações de diretório no Guia de Administração do IBM Tivoli Directory Server neste Web site: com.ibm.ibmds.doc/admin_gd16.htm v IBM Global Security Kit Secure Sockets Layer Introduction and ikeyman User s Guide neste Web site: com.ibm.itame2.doc_5.1/ss7aumst.pdf. Configurando SSL para o Servidor de Diretórios A seguir, utilize um arquivo LDIF para configurar SSL no servidor de diretórios, incluindo a especificação de uma porta segura. Antes de Iniciar Dependendo de como o administrador customizou o seu sistema, você poderá não ter acesso a essa tarefa. Para obter acesso a essa tarefa, ou ter alguém que a conclua para você, entre em contato com o administrador do sistema. Por Que e Quando Desempenhar Esta Tarefa Conclua estas etapas: 1. Se o servidor de diretórios não estiver em execução, inicie o servidor. Por exemplo, no UNIX, digite este comando: /opt/ibm/ldap/v6.1/sbin/ibmslapd -I itimldap em que -I especifica a instância. 2. Crie um arquivo LDIF como ssl.ldif com os seguintes dados: dn: cn=ssl,cn=configuration changetype: modify replace: ibm-slapdsslauth - ibm-slapdsslauth: serverauth replace: ibm-slapdsecurity - ibm-slapdsecurity: sslonly replace: ibm-slapdsslkeydatabase - ibm-slapdsslkeydatabase: /certs/ldapserver_test1234.kdb Nota: As linhas vazias que contêm apenas o caractere - (hífen) são necessárias para formatar o arquivo LDIF. Para alterar a porta segura a partir do número da porta padrão 636, tal como 637, inclua estas linhas adicionais: replace: ibm-slapdsecureport ibm-slapdsecureport: 637

19 3. Coloque o arquivo LDIF no seguinte diretório: /opt/ibm/ldap/v6.1/bin 4. Execute o comando idsldapmodify, que modifica a política de senha incluindo o arquivo LDIF no processo. idsldapmodify -D cn=root -w passwd -i ssl.ldif -D Liga ao diretório LDAP, que é cn=root neste exemplo. -w Utiliza o valor passwd (a senha de administrador do servidor de diretórios) como a senha para autenticação. -i Lê as informações de modificação de entrada a partir de um arquivo LDIF em vez de a partir da entrada padrão. Neste exemplo, o arquivo é nomeado ssl.ldif. Um resultado bem-sucedido produz uma mensagem semelhante a esta: Operation 0 modifying entry cn=ssl,cn=configuration 5. Teste o servidor de diretórios para confirmar se está atendendo na porta segura padrão 636. Conclua estas etapas: a. Pare o servidor de diretórios. Digite: /opt/ibm/ldap/v6.1/sbin/ibmslapd -k b. Inicie o servidor de diretórios. Digite: /opt/ibm/ldap/v6.1/sbin/ibmslapd -I itimldap em que -I especifica a instância. c. Determine se o servidor de diretórios está atendendo na porta 636. Por exemplo, exibe estatísticas para a interface de rede com o servidor de diretórios digitando: netstat -an grep 636 Uma mensagem de retorno que indica a porta em que está atendendo pode ser este exemplo: tcp : :* LISTEN Configurando SSL no WebSphere Application Server A seguir, configure o WebSphere Application Server para ativar a comunicação SSL entre o IBM Tivoli Identity Manager e o servidor de diretórios. Antes de Iniciar Dependendo de como o administrador customizou o seu sistema, você poderá não ter acesso a essa tarefa. Para obter acesso a essa tarefa, ou ter alguém que a conclua para você, entre em contato com o administrador do sistema. Por Que e Quando Desempenhar Esta Tarefa Conclua estas etapas: 1. Copie manualmente todos os arquivos do diretório /certs/ LDAPSERVER_TEST1234 no servidor de diretórios para um diretório idêntico /certs na raiz do WebSphere Application Server. 2. No WebSphere Application Server, altere para o diretório /opt/ibm/websphere/appserver/bin. 3. Inicie o utilitário ikeyman. Por exemplo, no UNIX, digite: ikeyman.sh 4. Clique em Novo Arquivo de Banco de Dados de Chave. Na página Novo, conclua estas etapas: Segurança 15

20 a. No campo Tipo de Banco de Dados de Chave, selecione JKS. b. No campo Nome do Arquivo, navegue para um nome de arquivo como /opt/ibm/websphere/appserver/java/jre/lib/security/cacerts. O arquivo cacerts é instalado por padrão com o WebSphere Application Server. c. No campo Local, digite /opt/ibm/websphere/appserver/java/jre/lib/ security/. Em seguida, clique em OK. 5. No menu Senha, digite changeit, que é a senha padrão. Em seguida, clique em OK. 6. No menu Substituir arquivo existente, selecione Sim. 7. Digite e confirme a senha Pa$$word1, selecione a senha de maior intensidade possível e, então, clique em OK. 8. Clique em Incluir para incluir um certificado a partir de um arquivo. 9. No menu Incluir Certificado de CA a Partir de um Arquivo, conclua estas etapas e clique em OK: a. Especifique o tipo de dados dos Dados DER Binários. b. Navegue até o nome do certificado, como LDAPSERVER_TEST1234.der neste exemplo. c. Digite um valor para o local, tal como /certs/. 10. Digite uma etiqueta para o certificado, como ITIM2LDAP, que é conveniente para memorizar o objetivo do certificado no WebSphere Application Server. Em seguida, clique em OK. 11. Examine a lista de certificados de signatário para certificar-se de que ela contém o certificado ITIM2LDAP. 12. Saia do utilitário ikeyman. 13. A seguir, inicie o Console Administrativo do WebSphere Application Server para ativar a comunicação SSL entre o Tivoli Identity Manager e o servidor de diretórios. a. Abra o Console Administrativo do WebSphere Application Server. Por exemplo, digite: b. Efetue logon como o administrador do WebSphere Application Server. c. Em cada registro de servidor de membro de cluster, clique em Servidores Servidores de aplicativos Server1 Java e Gerenciamento de Processos Definição de Processo Java Virtual Machine Propriedades Customizadas. Na página Servidores de Aplicativos, selecione Novo para especificar essas propriedades customizadas: Tabela 4. Propriedades Customizadas Nome Valor Descrição javax.net.ssl.truststore /opt/ibm/websphere/ AppServer/java/jre/lib/ security/cacerts Armazenamento confiável do certificado do servidor de diretórios para Tivoli Identity Manager javax.net.ssl.truststorepassword Pa$$word1 Senha que você especificou inicialmente para o certificado autoassinado. 16 Segurança

21 Tabela 4. Propriedades Customizadas (continuação) Nome Valor Descrição javax.net.ssl.truststoretype jks Formato do armazenamento de chaves padrão disponível com a Java VM d. Clique em Salvar. Configurando o IBM Tivoli Identity Manager Server A seguir, configure o Tivoli Identity Manager Server para se comunicar com o computador e porta na qual o servidor de diretórios atende a comunicação segura. Antes de Iniciar Dependendo de como o administrador customizou o seu sistema, você poderá não ter acesso a essa tarefa. Para obter acesso a essa tarefa, ou ter alguém que a conclua para você, entre em contato com o administrador do sistema. Por Que e Quando Desempenhar Esta Tarefa Conclua estas etapas: 1. No computador que possui o Tivoli Identity Manager Server, edite a propriedade que especifica a conexão LDAP. Conclua estas etapas: a. No diretório /opt/ibm/itim/data, edite o arquivo enroleldapconnection.properties. b. No arquivo de propriedades, altere a propriedade java.naming.provider.url para especificar o computador e a porta na qual o servidor de diretório está ouvindo. Neste exemplo, digite o nome do host e a porta segura da máquina que possui o servidor de diretórios. Por exemplo, digite: java.naming.provider.url=test1234:636 c. Além disso, altere a propriedade java.naming.security.protocol para especificar a comunicação SSL: java.naming.security.protocol=ssl 2. Salve e feche o arquivo enroleldapconnection.properties. 3. Reinicie o WebSphere Application Server. Testando a Comunicação SSL Entre Servidores Finalmente, teste a comunicação SSL entre o IBM Tivoli Identity Manager Server e o servidor de diretórios. Antes de Iniciar Dependendo de como o administrador customizou o seu sistema, você poderá não ter acesso a essa tarefa. Para obter acesso a essa tarefa, ou ter alguém que a conclua para você, entre em contato com o administrador do sistema. Por Que e Quando Desempenhar Esta Tarefa Conclua estas etapas: Segurança 17

22 1. Teste para ver se o servidor de diretórios está atendendo. No diretório /opt/ibm/ldap/v6.1/bin do computador que tem o servidor de diretório, digite este comando em uma linha: ldapsearch p 636 K /certs/ldapserver_test1234.kdb -s base objectclass=* -b dc=com O resultado possui entradas para o esquema de nível superior semelhantes a estas: dc=com objectclass=top objectclass=domain dc=com 2. No computador no qual o Tivoli Identity Manager Server está instalado, teste as conexões SSL. Conclua estas etapas: a. No diretório /opt/ibm/itim/bin, para fornecer segurança adicional, copie ldapconfig.lax para ldapconfig.lax.backup e edite o arquivo ldapconfig.lax. Você usará o arquivo ldapconfig.lax.backup posteriormente no processo para ocultar a senha de armazenamento confiável. b. As instruções seguintes fornecem os valores do armazenamento confiável que o WebSphere Application Server utiliza para comunicação SSL entre o IBM Tivoli Identity Manager e o servidor de diretórios. No arquivo, inclua a seguinte instrução como um só linha: v Sistemas UNIX: v lax.nl.java.option.additional= -Djavax.net.ssl.trustStoreType=jks -Djavax.net.ssl.trustStore=/certs -Djavax.net.ssl.trustStorePassword=Pa$$word1 -Djava.ext.dirs= /products/ibm/websphere/appserver/java/jre/lib/ext: /products/ibm/websphere/appserver/plugins: /products/ibm/websphere/appserver/lib: /products/ibm/websphere/appserver/lib/ext No exemplo acima, há espaços necessários: -Djavax.net.ssl.trustStoreType=jks SPACE -Djavax.net.ssl.trustStore=/certs SPACE Sistemas Windows: lax.nl.java.option.additional= -Djavax.net.ssl.trustStoreType=jks -Djavax.net.ssl.trustStore= C:\Progra~1\IBM\WebSphere\AppServer\java\jre\lib\security\cacerts -Djavax.net.ssl.trustStorePassword=Pa$$word1 -Djava.ext.dirs= C:\Progra~1\IBM\WebSphere\AppServer\java\jre\lib\ext; C:\Progra~1\IBM\WebSphere\AppServer\plugins; C:\Progra~1\IBM\WebSphere\AppServer\lib; C:\Progra~1\IBM\WebSphere\AppServer\lib\ext No exemplo acima, há espaços necessários: -Djavax.net.ssl.trustStoreType=jks SPACE -Djavax.net.ssl.trustStore= C:\Progra~1\IBM\WebSphere\AppServer\java\jre\lib\security\cacerts SPACE c. Salve o arquivo ldapconfig.lax. d. No arquivo runconfig.lax, inclua as mesmas instruções adicionadas ao arquivo ldapconfig.lax. Em seguida, salve o arquivo runconfig.lax. e. Inicie o utilitário ldapconfig que o Tivoli Identity Manager Server fornece. f. Na página Testar Conexão LDAP, conclua estas etapas: 18 Segurança

23 1) Digite o DN de administrador (cn=root) e senha. 2) Digite o nome do host e porta na qual o servidor de diretórios atende para comunicação segura. Por exemplo, digite o nome de host test1234 e o número de porta 636. g. Clique em Testar para testar a conexão segura para LDAP e, em seguida, clique em Cancelar para sair do ldapconfig. Se o teste for bem-sucedido, continue na próxima etapa. Se o teste falhar, retorne para as etapas de configuração anteriores, utilizando a mensagem de erro do teste de conexão ldapconfig como orientação. h. Reinicie o WebSphere Application Server. i. Exclua o arquivo ldapconfig.lax e renomeie o arquivo ldapconfig.lax.backup para ldapconfig.lax. Se quiser manter o arquivo ldapconfig.lax que foi usado durante este processo, apague a senha do armazenamento confiável que ele contém. 3. Para confirmar se essa comunicação segura está configurada, tente efetuar login com seu ID de usuário e senha para o Tivoli Identity Manager Server. Um login bem-sucedido indica que você configurou a comunicação SSL entre o Tivoli Identity Manager Server e o servidor de diretórios. 4. Se seu login não foi bem-sucedido, uma mensagem de erro na tela de login indicará que o servidor de diretórios não está disponível. Analise o log de configuração LDAP e o log do Tivoli Identity Manager Server e tente as etapas de configuração novamente. Além disso, você pode determinar se: v As instruções incluídas no arquivo ldapconfig.lax são especificadas corretamente e os espaços exigidos também foram incluídos. v O caminho para o arquivo de armazenamento confiável é válido. v O arquivo de armazenamento confiável está corrompido. Movendo o Servidor HTTP para Segurança e Desempenho Adicionais Para fornecer segurança adicional e para obter um melhor desempenho, configure um servidor HTTP, tal como o IBM HTTP Server, para residir em um computador independente que seja externo a qualquer outro componente do IBM Tivoli Identity Manager. Por padrão, o SSL está configurado como desligado no IBM HTTP Server. Para configurar o uso de SSL, você deve especificar diretivas SSL (propriedades) no arquivo de configuração do servidor (httpd.conf). Uma configuração que fornece segurança adicional e melhor desempenho é semelhante à Figura 6 na página 20 Segurança 19

24 WebSphere Application Server Network Deployment Célula do Tivoli Identity Manager Servidor HTTP IBM Plug-in do Servidor da Web do WebSphere Cluster do Tivoli Identity Manager } } } Servidor de Aplicativos Tivoli Identity Manager Server Driver JDBC Banco de Dados Tivoli Identity Manager Driver JDBC do Gerenciador } de Implementação Armazém de Dados LDAP Figura 6. Configuração do Servidor HTTP para Aumento da Segurança 20 Segurança SSL para o IBM HTTP Server e Plug-in do WebSphere Application Server O IBM HTTP Server externo redireciona pedidos de HTTP que são enviados a ele para o transporte HTTP interno do contêiner de Web do WebSphere Application Server através do plug-in do WebSphere Application Server. Para proteger essa comunicação, você precisa ativar o SSL para o IBM HTTP Server e configurar o plug-in do WebSphere Application Server para estabelecer comunicação segura com o contêiner de Web do WebSphere Application Server. Configurando SSL para o IBM HTTP Server Para configurar o uso de SSL, você deverá especificar as diretivas SSL (propriedades) no arquivo httpd.conf no Servidor HTTP do IBM. Por padrão, o SSL está configurado com um valor igual a desligado no IBM HTTP Server. Antes de Iniciar Dependendo de como o administrador customizou o seu sistema, você poderá não ter acesso a essa tarefa. Para obter acesso a essa tarefa, ou ter alguém que a conclua para você, entre em contato com o administrador do sistema. Antes de iniciar, consulte as informações de configuração no tópico Segurança com Comunicações SSL, localizado no Centro de Informações do IBM HTTP Server for WebSphere Application Server, Versão 6.1, neste Web site: com.ibm.websphere.ihs.doc/info/ihs/ihs/tihs_setupssl.html Por Que e Quando Desempenhar Esta Tarefa Para ativar SSL no IBM HTTP Server, utilize as informações de configuração para concluir estas etapas:

25 1. 1. Utilize o utilitário IBM HTTP Server ikeyman (interface gráfica com o usuário) ou o utilitário ikeyman (linha de comandos) para criar um arquivo de banco de dados de chave CMS e um certificado do servidor autoassinado Ative as diretivas SSL no arquivo de configuração httpd.conf do IBM HTTP Server. a. Remova o comentário da diretiva de configuração do LoadModule ibm_ssl_module modules/mod_ibm_ssl.so. b. Crie uma sub-rotina de host virtual SSL no arquivo httpd.conf utilizando os seguintes exemplos e diretivas. LoadModule ibm_ssl_module modules/mod_ibm_ssl.so <IfModule mod_ibm_ssl.c> Listen 443 <VirtualHost *:443> SSLEnable </VirtualHost> </IfModule> SSLDisable KeyFile "c:/program Files/IBM HTTP Server/key.kdb" Nota: Em plataformas Windows: v O nome do módulo de carregamento é LoadModule ibm_ssl_module modules/mod_ibm_ssl.dll. v Sempre especifique o endereço com a porta na diretiva Listen. Por exemplo, inclua a diretiva Listen no httpd.conf utilizando o endereço padrão para atender no IPv4 porta 443: Listen 0.0.0: Pare e inicie o IBM HTTP Server. 4. Teste a configuração utilizando um navegador em uma sessão HTTPS para o IBM HTTP Server ( Configurando SSL para o Plug-in Depois de ativar o IBM HTTP Server para SSL, configure o plug-in do WebSphere Application Server para que o IBM HTTP Server se comunique de maneira segura com os servidores de aplicativos. Além disso, certifique-se de que o SSL tenha sido ativado para o contêiner de Web do WebSphere Application Server apontando seu navegador para uma URL como Antes de Iniciar Dependendo de como o administrador customizou o seu sistema, você poderá não ter acesso a essa tarefa. Para obter acesso a essa tarefa, ou ter alguém que a conclua para você, entre em contato com o administrador do sistema. Antes de iniciar, configure o IBM HTTP Server para residir em um computador independente que esteja externo a qualquer outro componente do IBM Tivoli Identity Manager. Para obter mais informações sobre a seleção de um diagrama de topologia do servidor da Web e roteiro, consulte este Web site: com.ibm.websphere.nd.doc/info/ae/ae/tins_road_plugins.html A instalação e configuração do plug-in registram o servidor da Web com o Gerenciador de Implementação do WebSphere Application Server e o IBM HTTP Server torna-se um servidor da Web gerenciado. Você pode gerenciar um servidor Segurança 21

26 da Web gerenciado utilizando o Console Administrativo do WebSphere Application Server. Por Que e Quando Desempenhar Esta Tarefa O perfil do servidor de aplicativos para o qual você aponta durante a instalação e configuração do plug-in do WebSphere Application Server deve ser o próprio gerenciador de implementação nesta topologia. Isso resulta na criação de um arquivo-chave chamado plugin-key.kdb que reside no diretório app_server_root/profiles/dm_profile/etc. O arquivo plugin-key.kdb contém os certificados de todos os servidores de aplicativos federados. Faça com que o arquivo de chave do servidor da Web gerenciado para o plug-in seja utilizado para estabelecer o aplicativo seguro com os servidores de aplicativos. Para obter mais informações, consulte o tópico sobre como configurar o plug-in de servidor da Web para SSL, neste Web site: com.ibm.websphere.nd.doc/info/ae/ae/tsec_httpserv2.html O seguinte resumo das etapas descreve como configurar o plug-in do WebSphere Application Server para o IBM HTTP Server: Crie um diretório no host do servidor da Web para armazenar o arquivo de anel de chaves referido pelo plug-in e arquivos associados. Por exemplo, crie um diretório plugin_install_root/etc/keys. 2. No Console Administrativo do WebSphere Application Server, clique em Servidores Servidores da Web. 3. Selecione o nome do servidor da Web. 4. Clique em Propriedades de Plug-in. 5. Clique em Gerenciar Chaves e Certificados para acessar as opções de configuração para suas chaves e certificados. Por padrão, você pode alterar sua senha utilizada para proteger o armazenamento de chaves. 6. Clique em OK. 7. Clique no botão Armazenamentos de Chaves do servidor da Web para copiar o armazenamento de chaves e para guardar arquivos em um servidor da Web gerenciado. Configurando Conexão Única Os serviços de conexão única fornecem uma experiência ininterrupta para um usuário que acessa vários aplicativos na empresa. Você pode habilitar a conexão única para o console administrativo do IBM Tivoli Identity Manager e para aplicativos do console de autoatendimento usando o IBM Tivoli Access Manager. Com a função de conexão única configurada, um usuário efetua login uma vez na segurança da Web do Tivoli Access Manager e sua identidade é propagada para o IBM Tivoli Identity Manager, eliminando a necessidade de outro login. Essa função requer que o Tivoli Access Manager ative o recurso de conexão única com o IBM Tivoli Identity Manager. 22 Segurança

27 1. O Tivoli Access Manager executa a autenticação do usuário e a autorização de alta granularidade antes do acesso ser permitido ao IBM Tivoli Identity Manager. 2. O IBM Tivoli Identity Manager, em seguida, aplica o controle de acesso de baixa granularidade utilizando seu próprio ACI (Access Control Item). Há duas formas de configurar o Tivoli Access Manager e o IBM Tivoli Identity Manager para conexão única. v Utilizando WebSEAL v Utilizando servidores de plug-in do do Tivoli Access Manager Antes de configurar a conexão única com o WebSEAL, certifique-se de que o Tivoli Access Manager e o WebSEAL estejam instalados e configurados. Configurando Conexão Única com o WebSEAL O uso da autenticação do WebSEAL no lugar da autenticação do IBM Tivoli Identity Manager elimina a necessidade de uma senha separada para acessar o IBM Tivoli Identity Manager. O login para WebSEAL pode utilizar qualquer mecanismo de autenticação. A página de logon do IBM Tivoli Identity Manager não aparece durante a operação de conexão única. O WebSEAL suporta junções TCP (HTTP) e de SSL seguro (HTTPS) entre o WebSEAL e o IBM Tivoli Identity Manager Server. Para configurar a conexão única com o WebSEAL, conclua as seguintes etapas: 1. Defina como o Tivoli Access Manager mapeia as contas do Tivoli Access Manager para as contas do IBM Tivoli Identity Manager durante a autenticação. 2. Defina contas de usuário do Tivoli Access Manager para os usuários que precisarão de acesso ao IBM Tivoli Identity Manager. 3. Defina dois grupos do Tivoli Access Manager. Defina um grupo para aqueles usuários que precisam de acesso ao aplicativo do IBM Tivoli Identity Manager Administrator. Defina outro grupo para aqueles usuários que precisam de acesso ao aplicativo do IBM Tivoli Identity Manager Self Service. 4. Inclua os usuários do Tivoli Access Manager que precisam de acesso ao IBM Tivoli Identity Manager em um ou ambos os Grupos. 5. Defina uma Junção do WebSEAL. 6. Defina duas ACLs do Tivoli Access Manager para controlar o acesso ao IBM Tivoli Identity Manager. Defina uma ACL para o aplicativo do IBM Tivoli Identity Manager Administrator. Defina outra ACL para o aplicativo do IBM Tivoli Identity Manager Self Service. 7. Conceda aos Grupos do Tivoli Access Manager o acesso apropriado às suas ACLs do Tivoli Access Manager correspondentes. 8. Associe a junção do WebSEAL às ACLs do Tivoli Access Manager. 9. Configure o IBM Tivoli Identity Manager para utilizar conexão única. Mapeamento de Contas Ao utilizar a conexão única, ocorre o mapeamento de conta entre o Tivoli Access Manager e o IBM Tivoli Identity Manager durante a autenticação de login. Segurança 23