Índice. Índice Remissivo iii

(1)

Segurança

(2)

(3)

Índice

Segurança. . . 1

Segurança do WebSphere e Segurança do Java 2 . . 1

Práticas de Ambiente Seguras. . . 1

Comunicação SSL (Secure Sockets Layer) . . . 3

Terminologia SSL . . . 3

Autenticação SSL Uni e Bidirecional . . . 4

SSL em um Ambiente em Cluster . . . 5

Implementações de SSL. . . 6

Tipos de Arquivos de Certificado . . . 6

Comunicação Segura com Adaptadores . . . 7

Comunicação Segura com Aplicativos Customizados 8 Comunicação Segura com Middleware Suportado 10 Exemplo de Configurações SSL . . . 11

Antes de Iniciar . . . 11

Criando um Certificado . . . 12

Configurando SSL para o Servidor de Diretórios 14 Configurando SSL no WebSphere Application Server . . . 15

Configurando o IBM Tivoli Identity Manager Server . . . 17

Testando a Comunicação SSL Entre Servidores. . 17

Movendo o Servidor HTTP para Segurança e Desempenho Adicionais . . . 19

SSL para o IBM HTTP Server e Plug-in do WebSphere Application Server . . . 20

Configurando Conexão Única . . . 22

Configurando Conexão Única com o WebSEAL 23 Mapeamento de Contas . . . 23

Alterando a Página de Logoff . . . 25

Definindo Contas do Usuário do IBM Tivoli Access Manager . . . 26

Definindo Grupos do IBM Tivoli Access Manager 28 Incluindo uma Conta de Usuário do IBM Tivoli Access Manager em um Grupo . . . 28

Definindo uma Junção SSL do WebSEAL . . . 29

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

Associando a Junção WebSEAL às ACLs. . . . 34

Configurando o IBM Tivoli Identity Manager para Conexão Única . . . 35

Acessando Consoles do IBM Tivoli Identity Manager . . . 36

Comandos Utilizados com Freqüência para Configurar Conexão Única . . . 37

Configurando o Intervalo de Tempo Limite da Sessão para o IBM Tivoli Identity Manager . . . . 38

(4)

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

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

(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 e o WebSphere 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.

(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

(9)

chaves no servidor SSL.

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.

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 Identify Manager (cliente SSL)

Armazenamento Confiável

CA certificado “A”

Tivoli Directory Integrator (servidor SSL)

Armazenamento de chaves

Figura 1. Comunicação SSL Unilateral

Tivoli Identify Manager (cliente SSL)

Certificado “B”

Tivoli Directory Integrator (servidor SSL)

CA certificado “B”

Certificado “A”

(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

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

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

(12)

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 e o recurso 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. Recurso Gerenciado UNIX Recurso Gerenciado LDAP Tivoli Identity Manager Server Outros Adaptadores Tivoli Directory Integrator SSL SSL SSH SSH SSL A d a p t a d o r

= SSL de uma Via ou Duas Vias

= Protocolo Secure Shell

CHAVE: S S L S S L

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

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.

(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 _{Permita somente que APIs publicadas acessem somente EJBs do gerenciador na}

área sem privilégios.

v _{Permita que aplicativos customizados usem somente as funções que as APIs} fornecem.

v _{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 11.

(15)

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 Servidor SSL SSL de Uma Via SSL de Duas Vias

IBM Tivoli Identity Manager Server

Servidor de Diretórios LDAP

Servidor HTTP (IBM HTTP Server)

IBM Tivoli Identity Manager Server

Navegador da Web IBM Tivoli Identity Manager Server

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.

IBM HTTP Server Plug-in de Servidor da Web do WebSphere Navegador SSL SSL SSL

WebSphere Application Server Tivoli Identity Manager Server

Banco de Dados

Tivoli Identity Manager _{Armazém de Dados} LDAP

}

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

(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 e o arquivo 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 Descrição

LDAPSERVER_TEST1234.crl Não utilizado nesse exemplo. LDAPSERVER_TEST1234.der O certificado.

LDAPSERVER_TEST1234.kbd Arquivo de banco de dados de chave que possui o certificado.

LDAPSERVER_TEST1234.rdb Não utilizado nesse exemplo. LDAPSERVER_TEST1234.sth 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} →

(18)

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:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/ com.ibm.IBMDS.doc/admin_gd16.htm

v _{IBM Global Security Kit Secure Sockets Layer Introduction and iKeyman User’s Guide} neste Web site:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/ 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

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:

(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 0 0 9.42.62.72:636 0.0.0.0:* 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

Por Que e Quando Desempenhar Esta Tarefa

1. Copie manualmente todos os arquivos do diretório /certs/

LDAPSERVER_TEST1234 no servidor de diretórios para um diretório idêntico /certsna 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

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

https://test1234:9043/ibm/console/logon.jsp

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.

(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

Por Que e Quando Desempenhar Esta Tarefa

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

Por Que e Quando Desempenhar Esta Tarefa

(22)

1. Teste para ver se o servidor de diretórios está atendendo. No diretório

/opt/IBM/ldap/V6.1/bindo 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.laxpara 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:} 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 v _{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:

(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.backuppara ldapConfig.lax. Se quiser manter o arquivo ldapConfig.laxque 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

(24)

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

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: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/ 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

WebSphere Application Server Network Deployment Célula do Tivoli Identity Manager

Cluster do Tivoli Identity Manager

Servidor de Aplicativos Tivoli Identity Manager Server Driver JDBC

}

Servidor HTTP IBM Plug-in do Servidor da Web do WebSphere Driver JDBC do Gerenciador de Implementação

}

Banco de Dados Tivoli Identity Manager

Armazém de Dados LDAP

(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. 2. 2. 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 0.0.0.0 para atender no IPv4 porta 443:

Listen 0.0.0:443

3. 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 (https://ihs_host).

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 https://dm_host:9043/ibm/console.

Antes de Iniciar

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:

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/ 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

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

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/ 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:

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

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

(28)

Quando um usuário efetua login no IBM Tivoli Identity Manager utilizando o WebSEAL e a conexão única, o usuário precisa especificar uma conta de usuário do Tivoli Access Manager e senha. O Tivoli Access Manager executa a autenticação do usuário e também verifica se o usuário foi autorizado para acessar o aplicativo do IBM Tivoli Identity Manager.

Se a autenticação e a autorização forem bem-sucedidas, a conta do usuário do Tivoli Access Manager será transmitida no cabeçalho do pedido de HTTP iv-user ao IBM Tivoli Identity Manager. O aplicativo do IBM Tivoli Identity Manager transmite as informações no cabeçalho do pedido de HTTP ao IBM Tivoli Identity Manager para processamento adicional. O IBM Tivoli Identity Manager utiliza a conta do usuário do Tivoli Access Manager para localizar uma conta de usuário do IBM Tivoli Identity Manager correspondente no diretório do IBM Tivoli Identity Manager.

Normalmente, a conta do usuário do Tivoli Access Manager e a conta do usuário do IBM Tivoli Identity Manager são idênticas. Se forem idênticas, o IBM Tivoli Identity Manager permitirá que o usuário efetue login no IBM Tivoli Identity Manager.

Se não forem idênticas, você poderá configurar o IBM Tivoli Identity Manager para executar o mapeamento de conta do usuário. Há duas opções de configuração do mapeamento disponíveis que são controladas pelo atributo

enrole.authentication.idsEqual no arquivo enRoleAuthentication.properties localizado no diretório ITIM_HOME/data:

enrole.authentication.idsEqual=true

Nenhum mapeamento é tentado. A conta do usuário do Tivoli Access Manager transmitida no cabeçalho do pedido de HTTP iv-user deve ser idêntica a uma conta de usuário do IBM Tivoli Identity Manager definida no diretório do IBM Tivoli Identity Manager para que o usuário tenha a permissão de efetuar login no IBM Tivoli Identity Manager.

Se a política em sua instalação definir que todas as contas de usuário do IBM Tivoli Identity Manager precisam corresponder com as contas de usuário do Tivoli Access Manager, especifique

enrole.authentication.idsEqual=true para evitar processamento de mapeamento desnecessário e código-extra.

enrole.authentication.idsEqual=false

A conta de usuário do Tivoli Access Manager transmitida no cabeçalho do pedido de HTTP iv-user é utilizada para procurar o diretório do Tivoli Access Manager para obter uma conta de usuário do IBM Tivoli Identity Manager correspondente:

v _{Se for localizado um IBM Tivoli Identity Manager idêntico, o usuário} terá permissão de efetuar login no IBM Tivoli Identity Manager. v _{Se não for localizada uma conta do IBM Tivoli Identity Manager}

idêntica, o IBM Tivoli Identity Manager tentará localizar uma conta de usuário do IBM Tivoli Identity Manager correspondente utilizando a seguinte lógica de mapeamento:

A conta de usuário do Tivoli Access Manager transmitida no cabeçalho do pedido de HTTP iv-user é utilizada para procurar o diretório do IBM Tivoli Identity Manager para obter uma conta de usuário do Tivoli Access Manager.

Se for localizada uma conta de usuário do Tivoli Access Manager

(29)

procura para obter a entidade Pessoa do IBM Tivoli Identity Manager que possui a conta de usuário do Tivoli Access Manager. Se a entidade Pessoa proprietária do IBM Tivoli Identity Manager não puder ser localizada, o usuário não receberá permissão de login.

Se a entidade Pessoa do IBM Tivoli Identity Manager que possui a conta de usuário do Tivoli Access Manager correspondente for localizada, será realizada uma procura de uma conta de usuário do IBM Tivoli Identity Manager de propriedade dessa Pessoa do IBM Tivoli Identity Manager. Se for localizada uma conta de usuário do IBM Tivoli Identity Manager de propriedade da Pessoa do IBM Tivoli Identity Manager, o usuário receberá permissão para efetuar login no IBM Tivoli Identity Manager utilizando essa conta de usuário do IBM Tivoli Identity Manager. Caso contrário, o usuário não terá permissão para efetuar login.

Alterando a Página de Logoff

O Tivoli Identity Manager vem com arquivos diferentes, que podem ser especificados como a página de logoff do Tivoli Identity Manager Console e SelfService GUI.

Antes de Iniciar

Por Que e Quando Desempenhar Esta Tarefa

Os arquivos estão no diretório $WAS_HOME/AppServer/profiles/$PROFILE_NAME/ installedApps/$NODE_NAME/ITIM.ear/itim_console.war/jsp/commone no $WAS_HOME/AppServer/profiles/$PROFILE_NAME/installedApps/$NODE_NAME/ ITIM.ear/itim_self_service.war/jsp/common(sendo que $WAS_HOME é o diretório no qual o WebSphere Application Server está instalado).

Para configurar uma página de logoff diferente da página padrão, modifique os arquivos ui.properties ou SelfServiceUI.properties:

1. Abra o arquivo $ITIM_HOME/data/ui.properties do Tivoli Identity Manager em um editor de texto. Para configurar a página de Logoff para SelfService UI, abra o arquivo SelfServiceUI.properties.

2. Para a propriedade enrole.ui.logoffURL, especifique uma das páginas de logoff descritas na tabela a seguir.

Nota: Os arquivos ssoLogout.jsp e websealLogout.jsp são arquivos de amostra. Elas mostram o código de amostra exigido para usar o botão logout da GUI do Tivoli Identity Manager quando a conexão única do WebSEAL está habilitada. Você pode editar esses arquivos (inclusive o idioma) para executar quaisquer funções apropriadas para seu ambiente.

(30)

Tabela 5. Páginas de Logoff

Nome de arquivo Descrição

websealLogout.jsp Esse arquivo de amostra é o mais seguro. Use-o quando você quiser o seguinte comportamento combinado quando o usuário clicar no botão de Logoff:

v _{o Termine a sessão de logon do Tivoli Identity Manager}

v _{o Termine a sessão de logon do Tivoli Access Manager (a função} pkmslogout é invocada).

Nota: pkmslogout só funciona para clientes que usam um

mecanismo de autenticação que não fornece dados de autenticação com cada pedido. Por exemplo, pkmslogout não funciona para clientes que usam Autenticação Básica, certificados ou informações sobre endereço IP. Nesses casos, você deve fechar o navegador para efetuar logout. pkmslogout fornece essas informações ao usuário em uma mensagem exibida na página de logout. Você pode editar esse arquivo para customizar a funcionalidade de logoff de amostra. Defina os valores:

Para Console UI:

enrole.ui.logoffURL=/itim/console/jsp/common/ websealLogout.jsp

Para SelfService UI:

enrole.ui.logoffURL=/itim/self/jsp/common/ websealLogout.jsp

ssoLogout.jsp Use esse arquivo de amostra quando você quiser o seguinte comportamento combinado quando o usuário clicar no botão de Logoff:

v _{o Termine a sessão de logon atual do Tivoli Identity Manager e} forneça um link para retornar ao Tivoli Identity Manager GUI. v _{o Permaneça conectado ao Tivoli Access Manager (as informações}

do cabeçalho HTTP iv-user ainda estão disponíveis). Isso permite, por exemplo, o uso contínuo de uma página do portal ou voltar para o Tivoli Identity Manager sem um prompt de logon. Você pode editar esse arquivo para customizar a funcionalidade de logoff de amostra

Para Console UI:

enrole.ui.logoffURL=/itim/console/jsp/common/ sso_logout.jsp

Para SelfService UI:

enrole.ui.logoffURL=/itim/self/jsp/logon/SSOLogoff.jsp

Definindo Contas do Usuário do IBM Tivoli Access Manager

Para os usuários que precisarão acessar o IBM Tivoli Identity Manager, você precisará definir as contas do usuário do Tivoli Access Manager além das contas do usuário do Tivoli Identity Manager.

Antes de Iniciar

(31)

Por Que e Quando Desempenhar Esta Tarefa

É recomendado utilizar o Tivoli Identity Manager para provisão das contas do usuário do Tivoli Access Manager.

Este exemplo define myaccount como uma conta do usuário idêntica para ambos os aplicativos. As contas de usuário idênticas são recomendadas para o Tivoli Access Manager e o Tivoli Identity Manager. Caso contrário, você deve configurar o mapeamento de conta do usuário.

Para definir as contas do usuário do Tivoli Access Manager, conclua estas etapas: 1. No computador no qual o Tivoli Access Manager está instalado, inicie o

utilitário Tivoli Access Manager digitando pdadmin em um prompt de

comandos. Ele pode estar no Servidor de Autorização do Tivoli Access Manager ou no Servidor de Política do Tivoli Access Manager. Você também poderá usar o Tivoli Identity Manager. É recomendado utilizar o Tivoli Identity Manager para provisão das contas do usuário do Tivoli Access Manager.

2. Efetue login em um domínio seguro como o usuário de administração

sec_masterpara usar o utilitário. No prompt de comandos, digite login. Digite sec_masterquando solicitado um ID do usuário. Especifique a senha associada no prompt Digitar Senha. Por exemplo:

pdadmin> login

Digite o ID do Usuário: sec_master Digite a Senha: password

pdadmin>

3. Defina a conta de usuário myaccount como exemplo no Tivoli Access Manager usando o comando user create, da seguinte forma:

user create [-gsouser][-no-password-policy] user_name dn cn sn password [groups] em que:

-gsouser

Essa opção ativa as capacidades de conexão global. -no-password-policy

Essa opção permite que o administrador crie o usuário com uma senha inicial que não é verificada pelas políticas de senha globais existentes.

user_name

dn Especifica o identificador de registro atribuído ao usuário que está sendo criado. O formato do nome distinto é semelhante a:

cn=Mary Jones,out=Austing,o=Tivoli,c=us

cn Especifica o nome comum atribuído ao usuário que está sendo criado. Por exemplo, Mary.

sn O sobrenome do usuário. Por exemplo, Jones.

password

A senha da conta do novo usuário. groups

Especifica uma lista de grupos aos quais o novo usuário está atribuído. Por exemplo, digite:

user create "myaccount" "cn=FirstName LastName,o=ibm,c=us" "FirstName LastName" "LastName" password

4. Para tornar válida a conta do usuário, digite: user modify "myaccount" account-valid yes

(32)

Definindo Grupos do IBM Tivoli Access Manager

Use o utilitário pdadmin para definir dois grupos do Tivoli Access Manager.

Antes de Iniciar

Por Que e Quando Desempenhar Esta Tarefa

Um grupo é para usuários que precisam acessar o console administrativo que o IBM Tivoli Identity Manager fornece. O outro grupo é para usuários que precisam de acesso ao console de auto-serviço que o Tivoli Identity Manager fornece. Para criar os dois grupos, conclua estas etapas:

1. Crie um grupo nomeado ITIM-Group para os usuários que precisam de acesso administrativo, digitando o seguinte comando:

group create ITIM-Group cn=ITIM-Group,o=ibm,c=us ITIM-Group

2. Crie um grupo nomeado ITIM-Self-Service-Group para os usuários que precisam de acesso de autoatendimento, digitando o seguinte comando: group create ITIM-Self-Service-Group cn=ITIM-Self-Service-Group,o=ibm,c=us ITIM-Self-Service-Group

Incluindo uma Conta de Usuário do IBM Tivoli Access

Manager em um Grupo

Você precisa incluir contas de usuário do Tivoli Access Manager em grupos do Tivoli Access Manager.

Antes de Iniciar

Por Que e Quando Desempenhar Esta Tarefa

Para incluir contas do usuário em dois grupos, conclua estas etapas usando o utilitário pdadmin:

1. Inclua a conta do usuário myaccount no grupo ITIM-Group digitando este comando:

group modify ITIM-Group add "myaccount"

2. Inclua a conta do usuário do Tivoli Access Manager myaccount no grupo ITIM-Self-Service-Group, digitando o seguinte comando:

group modify ITIM-Self-Service-Group add "myaccount"

O que Fazer Depois

Você também pode usar a interface gráfica com o usuário do Gerenciador do Portal do Tivoli Access Manager ou use o IBM Tivoli Identity Manager. Recomenda-se que você use o Tivoli Identity Manager para fornecer o provisionamento.

(33)

Definindo uma Junção SSL do WebSEAL

A definição de uma junção SSL do WebSEAL requer configuração do certificado antes de poder criar a junção.

Antes de Iniciar

Por Que e Quando Desempenhar Esta Tarefa

Se você utilizar uma junção TCP do WebSEAL em vez de uma junção SSL, pule esta seção e vá para as informações sobre como definir uma junção TCP ou SSL do WebSEAL.

Primeiro você deve extrair o certificado do WebSphere do banco de dados do armazenamento de chaves no WebSphere Application Server, onde o IBM Tivoli Identity Manager está instalado. Em seguida, importe o certificado no banco de dados do armazenamento de chaves do servidor IBM Tivoli Access Manager WebSEAL.

Esse exemplo utiliza o banco de dados do armazenamento de chaves

DummyServerKeyFile.jks padrão no WebSphere Application Server. Para verificar qual armazenamento de chaves seu WebSphere Application Server utiliza, efetue login no Console Administrativo do WebSphere Application Server. Em seguida, conclua estas etapas:

1. Clique em Segurança → SSL → cluster_name/DefaultSSLSettings.

A propriedade Nome do Arquivo de Chave contém o nome do arquivo do banco de dados do armazenamento de chaves.

2. Para extrair o certificado do WebSphere, inicie o utilitário iKeyman do WebSphere Application Server.

O utilitário geralmente está no diretório WAS_HOME/java/jre/bin. 3. Selecione Abrir na tarefa do Arquivo de Banco de Dados de Chaves.

4. Clique em Procurar e localize o arquivo DummyServerKeyFile.jks localizado no diretório WAS_HOME/etc. É exibido um prompt de senha. Se você estiver

utilizando o arquivo fictício, a senha será WebAS. 5. Selecione o certificado e clique em Extrair Certificado.

6. No diálogo Extrair Certificado para um Arquivo, digite o seguinte: Tipo de Dados

Selecione dados ASCII codificados em Base64. Nome do Arquivo de Certificado

Digite um nome de arquivo para o certificado.

Local Digite o caminho do diretório onde o certificado deve estar armazenado.

Para esse exemplo, digite WebSphereServerCert.arm para o nome do arquivo de certificado e armazene o certificado no diretório WAS_HOME\etc.

7. Clique em OK. Depois de salvar o certificado, transfira o certificado extraído para o servidor WebSEAL e, então, importe-o no banco de dados do