Plug-in para Web Servers: Guia de Integração

IBM Tioli Access Manager para e-business Plug-in para Web Serers: Guia de Integração Versão 5.1 S517-7933-00

IBM Tioli Access Manager para e-business Plug-in para Web Serers: Guia de Integração Versão 5.1 S517-7933-00

Nota Antes de utilizar estas informações e o produto a que se referem, leia as informações no Apêndice F, Aisos, na página 237. Primeira Edição (Noembro de 2003) Esta edição aplica-se à ersão 5, release 1, modificação 0 do IBM Tioli Access Manager (número do produto 5724-C08) e a todos os releases e modificações subseqüentes, até que seja indicado de outra maneira em noas edições. Copyright International Business Machines Corporation 2000, 2003. Todos os direitos reserados.

Índice Figuras.................................... ix Tabelas.................................... xi Prefácio................................... xiii Quem Dee Ler Este Manual............................. xiii O Que Este Manual Contém.............................xi Publicações...................................x Informações sobre o Release.............................x Informações de Base...............................x Informações sobre Segurança na Web..........................x Referências para Desenoledores.......................... xi Suplementos Técnicos.............................. xii Publicações Relacionadas............................. xii Acessando Publicações On-line............................xx Acessibilidade.................................. xxi Entrando em Contato com o Suporte ao Software...................... xxi Conenções Utilizadas neste Manual........................... xxi Conenções Tipográficas.............................. xxi Diferenças do Sistema Operacional.......................... xxi Capítulo 1. Apresentando o IBM Tioli Access Manager Plug-in para Web Serers... 1 Tecnologia do Tioli Access Manager Plug-in para Web Serers..................1 Arquitetura e Componentes Operacionais Básicos......................1 Suporte para Hosts Virtuais.............................2 Protegendo o Espaço da Web com o Tioli Access Manager Plug-in para Web Serers...........3 Autenticação do Tioli Access Manager Plug-in para Web Serers.................4 Aquisição de Credenciais...............................5 Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers... 7 Informações Gerais sobre o Plug-in............................7 Diretório Raiz da Instalação do Tioli Access Manager Plug-in para Web Serers...........7 O Arquio de Configuração pdwebpi.conf........................8 O Arquio de Configuração pdwebpimgr.conf.......................9 Iniciando e Parando o Tioli Access Manager Plug-in para Web Serers..............9 Mensagens de Erro HTTP..............................9 Suporte para Macros...............................10 Macros Relacionadas a Formulários..........................11 Configurando o Authorization Serer...........................11 Configurando Encadeamentos Subordinados.......................11 Definindo a Duração Máxima de Sessões para Pedidos IPC..................12 Configurando Páginas de Erro............................12 Configurando para Seridores Host Virtuais........................13 Configuração Específica para Cada Seridor Web.......................16 Considerações sobre Seridores Web..........................18 Personalizando Listas de Objetos............................19 Argumentos de Linha de Comandos..........................19 Saída....................................20 Configurando a Função SU (Comutação de Usuários) para Administradores..............20 Compreendendo o Fluxo do Processo de Comutação de Usuários................21 Atiando a Função Comutação de Usuários.......................21 Configurando o Formulário HTML de Comutação de Usuários.................22 Atiando e Excluindo Usuários da Função Comutação de Usuários................23 Configurando o Mecanismo de Autenticação com Base em Comutação de Usuários..........23 Copyright IBM Corp. 2000, 2003 iii

Causando Impactos sobre Outras Funcionalidades do Plug-in.................25 Configurando o Failoer para Seridores LDAP.......................26 Suportando Cabeçalhos P3P (Platform for Priacy Preferences)..................27 Configurando Cabeçalhos P3P............................28 Configurando a Auditoria, o Registro, o Rastreio e o Banco de Dados de Cache do Plug-in.........30 Registros de Auditoria...............................31 Configuração de Auditoria.............................32 Rastreando Ações do Plug-in............................33 Definições do Banco de Dados de Cache.........................34 Configurando o Seriço da API de Autorização.......................35 Atualização de Credenciais..............................35 Configurando a Atualização de Credenciais.......................35 Configurando o Armazenamento em Cache de Pedidos HTTP..................37 Configurando Parâmetros de Armazenamento em Cache no Lado do Seridor............37 Suporte a Idiomas e Conjuntos de Caracteres........................37 Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers....................... 41 O Processo de Tratamento de Pedidos..........................41 O Processo de Autenticação..............................43 Configurando a Autenticação.............................43 Configurando a Autenticação para Hosts Virtuais......................45 Configurando a Ordem dos Métodos de Autenticação....................46 Configurando o Processamento Pós-Autorização......................51 Gerenciando o Estado de Sessões............................52 Configurando o Cache de Sessão/Credenciais do Plug-in...................53 Mantendo o Estado de Sessões com o ID da Sessão SSL...................55 Mantendo o Estado de Sessões com o Uso da Autenticação Básica................55 Mantendo o Estado de Sessões com Cookies de Sessão....................56 Mantendo o Estado de Sessões com o Uso de Cabeçalhos HTTP.................57 Mantendo o Estado de Sessões com o Uso de Endereços IP..................58 Mantendo o Estado de Sessões com o Uso de Cookies LTPA..................58 Mantendo o Estado de Sessões com o Uso de Cabeçalhos IV..................59 Visão Geral da Configuração de Autenticação........................59 Mecanismos de Autenticação Locais..........................59 Parâmetros de Autenticação do CDAS Externo Personalizado..................60 Configuração Padrão para Plug-ins..........................60 Configurando Vários Métodos de Autenticação......................61 Comandos de Logout, Alteração de Senha e Ajuda.....................61 Configurando a Autenticação Básica...........................62 Atiando a Autenticação Básica............................63 Configurando o Mecanismo de Autenticação Básica.....................63 Definindo o Nome da Região............................63 Manipulando Cabeçalhos BA............................63 Especifique a Codificação UTF-8 de Cabeçalhos BA.....................65 Configurando a Autenticação com Base em Formulários....................66 Atiando a Autenticação com Base em Formulários.....................66 Configurando o Mecanismo de Autenticação com Base em Formulários..............66 Personalizando Formulários de Resposta HTML......................67 Personalizando o URI de Login com base em Formulários...................67 Criando um Cabeçalho BA.............................67 Especifique a Codificação UTF-8 em Cabeçalhos BA.....................68 Configurando a Autenticação com Base em Certificados....................68 Autenticação Mútua Utilizando Certificados.......................68 Atiando a Autenticação com Base em Certificados.....................69 Configurando o Mecanismo de Autenticação com Base em Certificados..............69 Configurando a Autenticação com Base em Token......................70 Autenticação com Base em Token SecurID........................70 Atiando a Autenticação com Base em Token.......................72 Configurando o Mecanismo de Autenticação com Base em Token................73 Personalizando Páginas de Resposta de Tokens......................73 i IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Configurando a Autenticação SPNEGO..........................74 Suporte para Plataformas e Registros de Usuários.....................74 Fazendo o Upgrade da Configuração do SPNEGO a partir da Versão 4.1 para a Versão 5.1........75 Limitações...................................75 Configuração da Conexão Única de Desktops Windows...................76 Dicas de Resolução de Problemas...........................80 Configurando a Autenticação NTLM (Somente para Plataformas IIS)................82 Configurando a Autenticação com Base em Seridor Web (Somente para Plataformas IIS).........83 Configurando a Autenticação com Base em Failoer......................84 Conceitos da Autenticação com Base em Failoer......................84 Configuração da Autenticação com Base em Failoer....................91 Configurando a Autenticação com Base em Cabeçalhos IV................... 100 Atiando a Autenticação com o Uso de Cabeçalhos IV................... 101 Configurando Parâmetros de Cabeçalhos IV....................... 102 Especifique a Codificação UTF-8 de Cabeçalhos IV..................... 102 Configurando o Mecanismo de Autenticação com Base em Cabeçalhos IV para i-remote-address..... 102 Configurando a Autenticação com Base em Cabeçalhos HTTP.................. 103 Atiando a Autenticação com o Uso de Cabeçalhos HTTP.................. 103 Especificando Tipos de Cabeçalhos.......................... 103 Configurando o Mecanismo de Autenticação com Base em Cabeçalhos HTTP............ 104 Configurando a Autenticação com Base em Endereços IP.................... 104 Atiando a Autenticação com o Uso do Endereço IP.................... 105 Configurando o Mecanismo de Autenticação com Base em Endereço IP.............. 105 Configurando a Autenticação LTPA........................... 106 Atiando a Autenticação LTPA........................... 106 Definindo os Detalhes de Chaes........................... 106 Configurando o Processamento Pós-Autenticação LTPA................... 106 Configurando o Redirecionamento de Usuários Após o Logon.................. 106 Atiando o Redirecionamento de Usuários....................... 107 Configurando Parâmetros de Redirecionamento de Usuários................. 107 Adicionando Atributos Estendidos para Credenciais..................... 107 Mecanismos para Adicionar Atributos Estendidos a uma Credencial............... 107 Configuração do Seriço de Autorização........................ 108 Adicionando Atributos Estendidos LDAP ao Cabeçalho HTTP (Valor de Marcação)........... 111 Atiando o Processamento com Base em Valor de Marcação..................112 Configurando Parâmetros de Valores de Marcação.....................112 Oferecendo Suporte para MPAs (Agentes Proxy de Multiplexação)................112 Métodos de Autenticação e Tipos de Dados de Sessão Válidos.................113 Fluxo do Processo de Autenticação para o MPA e Vários Clientes................114 Atiando a Autenticação MPA............................115 Crie uma Conta de Usuário para o MPA........................116 Adicione a Conta do MPA ao Grupo pdwebpi-mpa-serers..................116 Capítulo 4. Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers................................... 117 Critérios ACL (Lista de Controle de Acesso) Específicos do Plug-in................117 /PDWebPI/host ou irtual_host...........................118 Permissões de ACL do Plug-in...........................119 Critério ACL /PDWebPI Padrão...........................119 Três Critérios de Logon de Orientação.......................... 120 Critério de Intensificação de Senha........................... 122 Critério de Intensificação de Senha Definido pelo Utilitário pdadmin............... 122 Definições Globais e Específicas do Usuário....................... 124 Critério de Objetos Protegidos de Intensificação da Autenticação (Progressão)............. 125 Configurando Níeis para a Autenticação Progressia.................... 125 Atiando a Autenticação Progressia......................... 126 Notas e Limitações da Autenticação Progressia...................... 127 Autenticação com Base em Multifatores......................... 128 Atiando a Autenticação com Base em Multifatores.................... 128 Critério de Objetos Protegidos de Reautenticação...................... 129 Condições que Afetam a Reautenticação POP....................... 129 Índice

Criando e Aplicando o POP de Reautenticação...................... 129 Critério de Objetos Protegidos de Autenticação com Base em Rede................ 130 Especificando Faixas e Endereços IP.......................... 130 Desatiando a Autenticação Progressia por Endereço IP................... 131 Algoritmo de Autenticação com Base em Rede...................... 132 Critério de Objetos Protegidos de Qualidade de Proteção.................... 132 Tratando Usuários Não Autenticados (HTTP/HTTPS)..................... 132 Processando um Pedido a partir de um Cliente Anônimo................... 132 Forçando o Logon de Usuários........................... 133 Aplicando o HTTPS Não Autenticado......................... 133 Controlando Usuários Não Autenticados com Critérios ACL/POP................ 133 Capítulo 5. Soluções de Conexão Única para a Web................ 135 Conceitos de Conexão Única............................. 135 Estabelecendo uma Conexão Única Automaticamente com um Aplicatio Protegido........... 136 Configurando a Conexão Única com Aplicatios Protegidos Utilizando Cabeçalhos HTTP........ 136 Conexão Única com o WebSphere Application Serer Utilizando Cookies LTPA........... 137 Conexão Única com o Plug-in a partir do WebSEAL ou de Outro Proxy............... 139 Atiando e Desatiando a Autenticação com o Uso de Cabeçalhos IV.............. 140 Configurando Parâmetros de Cabeçalhos IV....................... 140 Utilizando o Cookie de Failoer para Conexão Única..................... 140 Atiando a Conexão Única com o Uso de Cookies de Failoer................. 141 Utilizando a GSO (Conexão Única Global)......................... 141 Configurando a Conexão Única Global......................... 143 Conexão Única SPNEGO (Security Proider NEGOtiation)................... 144 Conexão Única Utilizando Formulários.......................... 144 Fluxo do Processo da Conexão Única por Formulários.................... 145 Requisitos para o Suporte de Aplicatios........................ 146 Atiando a Conexão Única por Formulários....................... 147 Configurando a Conexão Única por Formulários..................... 147 Exemplo de Arquio de Configuração para o IBM HelpNow................. 150 Capítulo 6. Soluções de Conexão Entre Domínios................ 153 CDSSO (Conexão Única Entre Domínios)......................... 153 Fluxo do Processo de Autenticação para a CDSSO..................... 153 Atiando e Desatiando a Autenticação CDSSO...................... 155 Criptografando os Dados do Token de Autenticação.................... 155 Configurando a Data e a Hora do Token........................ 156 Incluindo Atributos de Credencial nos Tokens de Autenticação................. 156 Especifique as Bibliotecas sso-create e sso-consume..................... 157 Expressando Links CDSSO............................. 158 Protegendo o Token de Autenticação......................... 158 Conexão Única do e-community............................ 159 Recursos e Requisitos da Conexão Única do e-community.................. 159 Fluxo do Processo da Conexão Única do e-community................... 160 O Cookie do e-community............................. 161 O Pedido e a Resposta de Garantia.......................... 162 O Token de Garantia............................... 163 Criptografando o Token de Garantia.......................... 163 Configurando um e-community........................... 164 Configurando a Conexão Única do e-community - um Exemplo................ 168 Capítulo 7. Integração de Aplicatios...................... 173 Mantendo o Estado de Sessões Entre o Cliente e os Aplicatios Backend.............. 173 Atiando o Gerenciamento de IDs de Sessão do Usuário................... 173 Inserindo Dados de Credencial no Cabeçalho HTTP.................... 174 Finalizando Sessões de Usuário........................... 175 Fornecendo Controle de Acesso a URLs Dinâmicos...................... 176 Configurando URLs Dinâmicos........................... 176 i IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Capítulo 8. Recuperação de Informações sobre Decisões de Autorização...... 179 Visão Geral da Recuperação da ADI........................... 179 Recuperando a ADI a partir do Pedido de um Cliente do Plug-in................. 180 Exemplo: Recuperando uma ADI a partir do Cabeçalho do Pedido............... 181 Exemplo: Recuperando uma ADI a partir da Cadeia de Consulta do Pedido............ 181 Exemplo: Recuperando uma ADI a partir do Corpo POST do Pedido............... 182 Recuperando uma ADI a partir da Credencial do Usuário................... 182 Fornecendo um Motio de Falha............................ 182 Configurando a Recuperação Dinâmica da ADI....................... 183 Configurando o Plug-in para Utilizar o Seriço da Web AMWebARS............... 184 Apêndice A. Utilizando pdbackup para Fazer Backup dos Dados do Plug-in..... 187 Funcionalidade.................................. 187 Fazendo Backup dos Dados do Plug-in......................... 187 Restaurando Dados do Plug-in........................... 188 Sintaxe.................................... 188 Exemplos.................................... 189 Exemplos para UNIX............................... 189 Exemplos para Windows............................. 189 Conteúdo de pdinfo-pdwebpi.lst........................... 190 Dados de Backup Adicionais............................ 191 Apêndice B. Referência de pdwebpi.conf.................... 193 Parâmetros de Configuração Gerais........................... 193 Parâmetros de Configuração de Autenticação........................ 197 Parâmetros de Configuração de Sessões......................... 207 Parâmetros de Configuração LDAP........................... 208 Parâmetros de Configuração de Proxy.......................... 208 Parâmetros de Configuração da API de Autorização..................... 209 Parâmetros de Configuração Específicos para um Seridor Web.................211 Apêndice C. Referência Rápida de Módulos................... 217 Apêndice D. Referência Rápida de Comandos.................. 225 pdwebpi_start.................................. 226 pdwebpi.................................... 228 pdwpi-ersion.................................. 229 pdwpicfg action config............................... 230 pdwpicfg action unconfig.............................. 233 Apêndice E. Caracteres Especiais Permitidos em Expressões Comuns....... 235 Apêndice F. Aisos.............................. 237 Marcas.................................... 238 Glossário.................................. 241 Índice Remissio............................... 247 Índice ii

iii IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Figuras 1. Interação dos Componentes Plug-in e Tioli Access Manager..................2 2. Fluxo de Processo do Plug-in para Determinar o Módulo de Autenticação.............50 3. Lógica do Processo de Solicitação de Autenticação.....................51 4. Fluxo de Processo do Plug-in para dderminar o Módulo de Sessão................53 5. Arquitetura de Seridor Comum para Cookies de Failoer..................84 6. Acesso de Usuários a Aplicatios Protegidos Utilizando a GSO................. 142 7. Fluxo do Processo da Conexão Única por Formulários................... 145 8. Fluxo de Processo da CDSSO............................ 154 9. Registrando em um e-community........................... 161 10. Exemplo de Configuração da Conexão Única do e-community................ 169 11. Fluxo de processo do ARS............................. 184 Copyright IBM Corp. 2000, 2003 ix

x IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabelas 1. Campos do EPAC para o Tioli Access Manager.....................5 2. Resumo das Seções de pdwebpi.conf.........................8 3. Substituições de Macros Suportadas.........................10 4. Parâmetros de Configuração de Páginas de Erro de [proxy]..................12 5. Parâmetros de Configuração Específicos para cada Seridor Web................16 6. Parâmetros [p3p-header].............................28 7. Definições de Campos de Registros de Auditoria de Autenticação................31 8. Definições de Parâmetros de Configuração de Auditoria..................32 9. Idiomas Suportados pelo Plug-in com o Diretório Suportado..................38 10. Autenticadores Locais Internos...........................60 11. Parâmetros de Seridores CDAS Externos.......................60 12. Configuração do SPNEGO Equialente entre a Versão 4.1 e a Versão 5.1..............75 13. Nomes de Arquios de Bibliotecas de Autenticação com Base em Failoer............93 14. Descrições de Campos de Cabeçalhos IV....................... 101 15. Tipos de Dados de Sessão Válidos para o MPA.....................113 16. Tipos de Autenticação MPA Válidos.........................113 17. Permissões de ACL do Plug-in...........................119 18. Permissões WebDAV do Plug-in..........................119 19. Comandos de Critério de Logon LDAP pdadmin.................... 122 20. Comandos de Intensificação de Senha LDAP pdadmin................... 123 21. Exemplos de Senhas.............................. 124 22. Descrições de Níeis de QOP........................... 132 23. Descrições de Campos de Cabeçalhos IV....................... 136 24. Parâmetros de Configuração LTPA......................... 139 25. Descrições de Campos de Cabeçalhos IV....................... 139 26. Parâmetros de Configuração Gerais......................... 193 27. Parâmetros de Configuração de Autenticação...................... 197 28. Parâmetros de Configuração de Sessões........................ 207 29. Parâmetros de Configuração LDAP......................... 208 30. Parâmetros de Configuração de Proxy........................ 208 31. Parâmetros de Configuração da API de Autorização................... 209 32. Parâmetros de Configuração Específicos para um Seridor Web................211 33. Referência de Métodos/Módulos de Autenticação de Plug-ins................ 217 34. Módulos de Autenticação Específicos para o Windows................... 219 35. Referência de Módulos de Sessão de Plug-ins...................... 220 36. Referência de Módulos de Pré-autorização de Plug-ins................... 220 37. Referência de Módulos de Pós-autorização de Plug-ins................... 222 38. Referência de Módulos de Resposta......................... 223 Copyright IBM Corp. 2000, 2003 xi

xii IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Prefácio Quem Dee Ler Este Manual O IBM Tioli Access Manager Plug-in para Web Serers gerencia a segurança de recursos com base na Web agindo como um gateway entre clientes e um espaço da Web protegido. O plug-in implementa os critérios de segurança que protegem o espaço de objetos da Web. Ele pode fornecer conexão única, suportar seridores Web em execução como hosts irtuais e incorporar recursos de seridores de aplicatio Web em seu critério de segurança. Nota: Para obter detalhes sobre: plataformas suportadas, requisitos de disco e de memória, pré-requisitos de software e instruções de instalação para o plug-in, consulte o Tioli Access Manager for e-business Web Security: Guia de Instalação. O IBM Tioli Access Manager (Tioli Access Manager) é o software base necessário para executar aplicatios no conjunto de produtos do IBM Tioli Access Manager. Ele permite a integração de aplicatios do IBM Tioli Access Manager que fornecem uma ampla faixa de soluções de autorização e gerenciamento. Vendidos como uma solução integrada, esses produtos fornecem uma solução de gerenciamento de controle de acesso que centraliza o critério de segurança de rede e aplicatio para aplicatios de e-business. Nota: O IBM Tioli Access Manager é o noo nome do software anteriormente liberado denominado Tioli SecureWay Policy Director. Além disso, para os usuários familiarizados com o software e a documentação do Tioli SecureWay Policy Director, o seridor de gerenciamento é agora referido como o seridor de critério. O IBM Tioli Access Manager for e-business Plug-in para Web Serers: Guia de Integração fornece procedimentos administratios e informações de referência técnica para a proteção de um domínio da Web com o uso do aplicatio Plug-in para Web Serers. Este guia está destinado a administradores de sistema responsáeis pela instalação, pela implementação e pela administração do Access Manager Plug-in para Web Serers. Os leitores deem estar familiarizados com o seguinte: Sistemas operacionais PC e UNIX. Arquitetura e conceitos de banco de dados. Gerenciamento de segurança. Protocolos Internet, incluindo o HTTP, o HTTPS e o TCP/IP. LDAP (Lightweight Directory Access Protocol) e seriços de diretório. Um registro de usuários suportado. Autenticação e autorização. Se ocê estier atiando a comunicação SSL (Secure Sockets Layer), também deerá estar familiarizado com o protocolo SSL, troca de chaes (pública e priada), assinaturas digitais, algoritmos criptográficos e autoridades de certificação. Copyright IBM Corp. 2000, 2003 xiii

O Que Este Manual Contém Este manual contém as seguintes seções: Capítulo 1, Apresentando o IBM Tioli Access Manager Plug-in para Web Serers Fornece uma introdução ao aplicatio Access Manager Plug-in para Web Serers, fornecendo detalhes sobre arquitetura do sistema, funcionalidade e ambiente operacional. Capítulo 2, Configuração do IBM Tioli Access Manager Plug-in para Web Serers Fornece informações sobre os requisitos de configuração para o Access Manager Plug-in para Web Serers. Capítulo 3, Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers Discussão sobre como o plug-in mantém o estado de sessões, trata o processo de autenticação e executa qualquer processamento pós-autorização necessário nas sessões autorizadas. Capítulo 4, Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers Informações sobre a configuração e a personalização do critério de segurança do Access Manager Plug-in para Web Serers. Capítulo 5, Soluções de Conexão Única para a Web Discussão sobre as soluções de conexão única para o espaço da Web protegido pelo Access Manager Plug-in para Web Serers. Capítulo 6, Soluções de Conexão Entre Domínios Discussão sobre as soluções de conexão única entre domínios do Access Manager Plug-in para Web Serers. Capítulo 7, Integração de Aplicatios, na página 173 Discussão sobre a integração de aplicatios de terceiros por meio da grande ariedade de ariáeis de ambiente e de cabeçalhos HTTP e por meio da capacidade de URLs dinâmicos do plug-in. Capítulo 8, Recuperação de Informações sobre Decisões de Autorização, na página 179 Discussão sobre como o plug-in pode fornecer, ou adquirir, a ADI (informação sobre decisões de autorização) necessária para aaliar regras de autorização que protegem recursos no domínio do Tioli Access Manager. Apêndice A, Utilizando pdbackup para Fazer Backup dos Dados do Plug-in, na página 187 Informações sobre como usar o utilitário pdbackup. Apêndice B, Referência de pdwebpi.conf Uma lista dos parâmetros de configuração do Access Manager Plug-in para Web Serers, com descrições associadas. Apêndice C, Referência Rápida de Módulos Uma lista de todos os métodos de autenticação, de sessão e de pós-autorização do plug-in, com descrições associadas. Apêndice D, Referência Rápida de Comandos Uma lista dos utilitários disponíeis do plug-in, com uma descrição das ações que cada um executa. Apêndice E, Caracteres Especiais Permitidos em Expressões Comuns, na página 235 xi IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Uma lista dos caracteres especiais permitidos em expressões regulares utilizadas no arquio de configuração pdwebpi.conf. Publicações Reise as descrições da biblioteca do Tioli Access Manager, as publicações de pré-requisitos e as publicações relacionadas para determinar quais publicações podem ser úteis. Depois de determinar as publicações necessárias, consulte as instruções para acessar publicações on-line. Informações adicionais sobre o produto IBM Tioli Access Manager para e-business em si podem ser encontradas em: http://www.ibm.com/software/tioli/products/access-mgr-e-bus/ A biblioteca do Tioli Access Manager está organizada nas seguintes categorias: Informações sobre o Release Informações de Base Informações sobre Segurança na Web Referências para Desenoledores na página xi Suplementos Técnicos na página xii Informações sobre o Release IBM Tioli Access Manager para e-business: Leia isto Primeiro (G517-7925-00) Fornece informações para instalar e começar a utilizar o Tioli Access Manager. IBM Tioli Access Manager para e-business: Notas sobre o Release (G517-7926-00) Fornece as últimas informações, como limitações de software, soluções e atualizações de software. Informações de Base IBM Tioli Access Manager Base: Guia de Instalação (S517-7927-00) Explica como instalar e configurar o software base do Tioli Access Manager, incluindo a interface de Web Portal Manager. Este manual é um subconjunto de IBM Tioli Access Manager para e-business: Guia de Instalação de Segurança da Web e dee ser utilizado com outros produtos do Tioli Access Manager, como IBM Tioli Access Manager para Business Integration e IBM Tioli Access Manager para Sistemas Operacionais. IBM Tioli Access Manager Base Administration Guide (SC32-1360-00) Descree os conceitos e procedimentos para utilizar os seriços do Tioli Access Manager. Fornece instruções para a execução de tarefas a partir da interface do Web Portal Manager e utilizando o comando pdadmin. Informações sobre Segurança na Web IBM Tioli Access Manager para e-business: Guia de Instalação de Segurança da Web (S517-7928-00) Fornece instalação, configuração e instruções de remoção para o software base de Tioli Access Manager e também os componentes do Web Security. Este manual é um super conjunto de IBM Tioli Access Manager Base: Guia de Instalação. IBM Tioli Access Manager Upgrade Guide (SC32-1369-00) Prefácio x

Explica como fazer a atualização do Tioli SecureWay Policy Director Versão 3.8 ou ersões anteriores do Tioli Access Manager para o Tioli Access Manager Versão 5.1. IBM Tioli Access Manager para e-business WebSEAL Administration Guide (SC32-1359-00) Fornece informações sobre material de segundo plano, sobre procedimentos administratios e sobre referência técnica para utilizar o WebSEAL para gerenciar os recursos de seu domínio Web seguro. IBM Tioli Access Manager para e-business IBM WebSphere Application Serer: Guia de Integração (S517-7930-00) Fornece instruções de instalação, remoção e administração para integrar o Tioli Access Manager com o IBM WebSphere Application Serer. IBM Tioli Access Manager para e-business IBM WebSphere Edge Serer: Guia de Integração (S517-7931-00) Fornece instruções de instalação, remoção e administração para integrar o Tioli Access Manager com o aplicatio IBM WebSphere Edge Serer. IBM Tioli Access Manager para e-business Plug-in para Web Serers: Guia de Integração (S517-7933-00) Fornece instruções de instalação, procedimentos de administração e informações de referência técnica para proteger o domínio da Web utilizando o plug-in para seridores da Web. IBM Tioli Access Manager para e-business BEA WebLogic Serer: Guia de Integração (S517-7929-00) Fornece instruções de instalação, remoção e administração para integrar o Tioli Access Manager com o BEA WebLogic Serer. IBM Tioli Access Manager para e-business IBM Tioli Identity Manager Proisioning Fast Start Guide (SC32-1364-00) Fornece uma isão geral das tarefas relacionadas à integração do Tioli Access Manager e do Tioli Identity Manager e explica como utilizar e instalar a coleta do Proisioning Fast Start. Referências para Desenoledores IBM Tioli Access Manager para e-business Authorization C API Deeloper Reference (SC32-1355-00) Fornece material de referência que descree como utilizar a API C de autorização do Tioli Access Manager e a interface de plug-in de seriço do Tioli Access Manager para incluir segurança do Tioli Access Manager em aplicatios. IBM Tioli Access Manager para e-business Authorization Jaa Classes Deeloper Reference (SC32-1350-00) Fornece informações de referência para o uso da implementação da linguagem Jaa da API de autorização para permitir que um aplicatio utilize a segurança do Tioli Access Manager. IBM Tioli Access Manager para e-business Administration C API Deeloper Reference (SC32-1357-00) Fornece informações de referência sobre o uso da API de administração para permitir que um aplicatio execute tarefas administratias do Tioli Access Manager. Esse documento descree a implementação C da API de administração. IBM Tioli Access Manager para e-business Administration Jaa Classes Deeloper Reference (SC32-1356-00) xi IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Fornece informações de referência para o uso da implementação da linguagem Jaa da API de administração para permitir que um aplicatio execute tarefas administratias do Tioli Access Manager. IBM Tioli Access Manager para e-business Web Security Deeloper Reference (SC32-1358-00) Fornece informações de administração e programação para o CDAS (Cross-Domain Authentication Serice), o CDMF (Cross-Domain Mapping Framework) e o módulo de força da senha. Suplementos Técnicos IBM Tioli Access Manager para e-business Command Reference (SC32-1354-00) Fornece informações sobre os utilitários da linha de comandos e scripts fornecidos com o Tioli Access Manager. IBM Tioli Access Manager Error Message Reference (SC32-1353-00) Fornece explicações e as ações recomendadas para as mensagens produzidas pelo Tioli Access Manager. IBM Tioli Access Manager para e-business Problem Determination Guide (SC32-1352-00) Fornece informações sobre determinação de problemas para o Tioli Access Manager. IBM Tioli Access Manager para e-business Performance Tuning Guide (SC32-1351-00) Fornece informações de ajuste de desempenho para um ambiente que consiste no Tioli Access Manager com o IBM Tioli Directory serer como o registro do usuário. Publicações Relacionadas Esta seção lista publicações relacionadas à biblioteca do Tioli Access Manager. O Tioli Software Library fornece uma ariedade de publicações Tioli como documentos técnicos, planilhas de dados, demonstrações, liros de registros e cartas de anúncio. O Tioli Software Library está disponíel na Web em: http://www.ibm.com/software/tioli/library/ O Tioli Software Glossary inclui definições para ários termos técnicos relacionados ao software Tioli. O Tioli Software Glossary está disponíel, somente em Inglês, a partir do link Glossary, ao lado esquerdo da página da Web do Tioli Software Library Library http://www.ibm.com/software/tioli/library/ IBM Global Security Kit O Tioli Access Manager fornece criptografia de dados atraés do uso do IBM GSKit (Global Security Kit) Versão 7.0. O GSKit está incluído no CD do IBM Tioli Access Manager Base para sua plataforma particular e também nos CDs do IBM Tioli Access Manager Web Security, nos CDs do IBM Tioli Access Manager Web Administration Interfaces e nos CDs do IBM Tioli Access Manager Directory Serer. O pacote GSKit fornece o utilitário de gerenciamento de chaes do ikeyman, gsk7ikm, que é utilizado para criar bancos de dados chae, pares de chaes pública-priada e pedidos de certificados. O documento a seguir está disponíel no site do Tioli Information Center, na mesma seção que a documentação do produto IBM Tioli Access Manager: IBM Global Security Kit Secure Sockets Layer and ikeyman: Guia do Usuário (S517-7932-00) Prefácio xii

Fornece informações para administradores de segurança de rede ou de sistema que planejam atiar a comunicação SSL em seu ambiente do Tioli Access Manager. IBM Tioli Directory Serer O IBM Tioli Directory Serer, Versão 5.2, é incluído no CD do IBM Tioli Access Manager Directory Serer para o sistema operacional desejado. Nota: IBM Tioli Directory Serer é o noo nome para o software liberado anteriormente conhecido como: IBM Directory Serer (Versão 4.1 e Versão 5.1) IBM SecureWay Directory Serer (Versão 3.2.2) O IBM Directory Serer Versão 4.1, o IBM Directory Serer Versão 5.1 e o IBM Tioli Directory Serer Versão 5.2 são todos suportados pelo IBM Tioli Access Manager Versão 5.1. Informações adicionais sobre o IBM Tioli Directory Serer podem ser encontradas em: http://www.ibm.com/software/network/directory/library/ IBM DB2 Uniersal Database O IBM DB2 Uniersal Database Enterprise Serer Edition, Versão 8.1 é fornecido no CD do IBM Tioli Access Manager Directory Serer e é instalado com o software IBM Tioli Directory Serer. O DB2 é necessário ao utilizar o IBM Tioli Directory Serer, os seridores LDAP z/os ou OS/390 como o registro de usuário para o Tioli Access Manager. Informações adicionais sobre o DB2 podem ser encontradas em: http://www.ibm.com/software/data/db2/ IBM WebSphere Application Serer O IBM WebSphere Application Serer, Adanced Single Serer Edition 5.0, é incluído no CD do IBM Tioli Access Manager Web Administration Interfaces para o sistema operacional desejado. O WebSphere Application Serer atia o suporte da interface do Web Portal Manager, que é utilizada para administrar o Tioli Access Manager e o Web Administration Tool, que é utilizado para administrar o IBM Tioli Directory Serer. O IBM WebSphere Application Serer Fix Pack 2 também é requerido pelo Tioli Access Manager e é fornecido no CD do IBM Tioli Access Manager WebSphere Fix Pack. Informações adicionais sobre o IBM WebSphere Application Serer podem ser encontradas em: http://www.ibm.com/software/webserers/appser/infocenter.html IBM Tioli Access Manager para Business Integration O IBM Tioli Access Manager para Business Integration, disponíel como um produto solicitado separadamente, fornece uma solução de segurança para mensagens do IBM MQSeries, Versão 5.2 e o IBM WebSphere MQ para Versão 5.3. O IBM Tioli Access Manager para Business Integration permite que os aplicatios MQSeries do WebSphere eniem dados com priacidade e integridade, utilizando chaes associadas a aplicatios de enio e recepção. Como o WebSEAL e o IBM Tioli Access Manager para Sistemas Operacionais, o IBM Tioli Access xiii IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Manager para Business Integration é um dos gerenciadores de recursos que utilizam os seriços do IBM Tioli Access Manager. Informações adicionais sobre o IBM Tioli Access Manager para Business Integration podem ser encontradas em: http://www.ibm.com/software/tioli/products/access-mgr-bus-integration/ Os seguintes documentos associados ao IBM Tioli Access Manager para Business Integration Versão 5.1 estão disponíeis no Web site do Tioli Information Center: IBM Tioli Access Manager para Business Integration: Guia de Administração (S517-7600-01) IBM Tioli Access Manager for Business Integration Problem Determination Guide (GC23-1328-00) IBM Tioli Access Manager para Business Integration: Notas sobre o Release (G517-7602-01) IBM Tioli Access Manager para Business Integration: Leia isto Primeiro (G517-7821-00) IBM Tioli Access Manager para WebSphere Business Integration Brokers O IBM Tioli Access Manager para WebSphere Business Integration Brokers, disponíel como parte do IBM Tioli Access Manager para Business Integration, fornece uma solução de segurança para o WebSphere Business Integration Message Broker, Versão 5.0 e o WebSphere Business Integration Eent Broker, Versão 5.0. O IBM Tioli Access Manager para WebSphere Business Integration Brokers opera juntamente com o Tioli Access Manager para dar segurança a aplicatios de publicação/assinatura JMS fornecendo senha e autenticação baseada em credenciais, autorização definida centralmente e seriços de auditoria. Informações adicionais sobre o IBM Tioli Access Manager para WebSphere Integration Brokers podem ser encontradas em: http://www.ibm.com/software/tioli/products/access-mgr-bus-integration/ Os seguintes documentos associados ao IBM Tioli Access Manager para WebSphere Integration Brokers, Versão 5.1 estão disponíeis no Web site do Tioli Information Center: IBM Tioli Access Manager para WebSphere Business Integration Brokers: Guia de Administração (S517-7910-00) IBM Tioli Access Manager para WebSphere Business Integration Brokers: Notas sobre o Release (G517-7911-00) IBM Tioli Access Manager para Business Integration: Leia isto Primeiro (G517-7821-00) IBM Tioli Access Manager para Sistemas Operacionais O IBM Tioli Access Manager para Sistemas Operacionais, disponíel como um produto que pode ser solicitado separadamente, fornece uma camada de aplicação do critério de autorização em sistemas UNIX, além da fornecida pelo sistema operacional natio. O IBM Tioli Access Manager para Sistemas Operacionais, como o WebSEAL e o IBM Tioli Access Manager para Business Integration, é um dos gerenciadores de recursos que utilizam os seriços do IBM Tioli Access Manager. Prefácio xix

Informações adicionais sobre o IBM Tioli Access Manager para Sistemas Operacionais podem ser encontradas em: http://www.ibm.com/software/tioli/products/access-mgr-operating-sys/ Os seguintes documentos associados ao IBM Tioli Access Manager para Sistemas Operacionais Versão 5.1 estão disponíeis no Web site do Tioli Information Center: IBM Tioli Access Manager para Sistemas Operacionais: Guia de Instalação (S517-7609-00) IBM Tioli Access Manager for Operating Systems Administration Guide (SC23-4827-00) IBM Tioli Access Manager for Operating Systems Problem Determination Guide (SC23-4828-00) IBM Tioli Access Manager para Sistemas Operacionais: Notas sobre o Release (G517-7610-00) IBM Tioli Access Manager para Sistemas Operacionais: Leia isto Primeiro (G517-7611-00) IBM Tioli Identity Manager O IBM Tioli Identity Manager Versão 4.5, disponíel como um produto que pode ser solicitado separadamente, permite gerenciar centralmente usuários (como IDs de usuários e senhas) e proisões (que estejam fornecendo ou cancelando o acesso a aplicatios, recursos ou sistemas operacionais). O Tioli Identity Manager pode ser integrado com o Tioli Access Manager atraés do uso do Tioli Access Manager Agent. Entre em contato com o representante de contas IBM para obter informações adicionais sobre como comprar o Agent. Informações adicionais sobre o IBM Tioli Identity Manager podem ser encontradas em: http://www.ibm.com/software/tioli/products/identity-mgr/ Acessando Publicações On-line As publicações para esse produto estão disponíeis on-line no formato PDF (Portable Document Format) ou HTML (Hypertext Markup Language) ou em ambos no Tioli software library: http://www.ibm.com/software/tioli/library Para localizar publicações do produto na biblioteca, clique no link Product manuals à esquerda da página de bibliotecas. Em seguida, localize e clique no nome do produto na página central de informações do software Tioli. As publicações de produto incluem notas sobre o release, guias de instalação, guias de usuário, guias de administrador e referências de desenoledor. Nota: Para garantir a impressão correta de publicações PDF, selecione a caixa de opções Ajustar à página na janela Imprimir do Adobe Acrobat (disponíel quando ocê clica em Arquio Imprimir). xx IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Acessibilidade Os recursos de acessibilidade ajudam usuários que possuem alguma limitação física, como mobilidade restrita ou isão limitada, a utilizar os produtos de software com êxito. Com este produto, é possíel utilizar tecnologias de assistência para ouir e naegar a interface. Você também pode usar o teclado em lugar do mouse para operar todos os recursos da interface gráfica com o usuário. Entrando em Contato com o Suporte ao Software Antes de entrar em contato com o suporte do IBM Tioli Software com um problema, consulte o site de suporte do IBM Tioli Software clicando no link Tioli support no Web site a seguir: http://www.ibm.com/software/support/ Se precisar de ajuda, entre em contato com o suporte a software, utilizando os métodos descritos no IBM Software Support Guide, no seguinte Web site: http://techsupport.serices.ibm.com/guides/handbook.html O guia fornece as seguintes informações: Requisitos de registro e elegibilidade para receber suporte Números de telefone, dependendo do país em que ocê esteja localizado Uma lista de informações que ocê dee reunir antes de entrar em contato com o suporte ao cliente Conenções Utilizadas neste Manual Este guia utiliza árias conenções para termos e ações especiais e para comandos e caminhos que dependem do sistema operacional. Conenções Tipográficas As seguintes conenções tipográficas são utilizadas nesta referência: Negrito Comandos em letra minúscula ou mistura de letras maiúsculas e minúsculas que são difíceis de distinguir no texto, palaras-chae, parâmetros, opções, nomes de classes Jaa e objetos ao redor aparecem em negrito. Itálico Variáeis, títulos de publicações e palaras e frases especiais que são enfatizadas aparecem em itálico. Espaçamento fixo Exemplos de códigos, linhas de comandos, saída de tela, nomes do arquio e diretório que são difíceis de distinguir no texto, mensagens do sistema, texto que o usuário dee digitar e alores para argumentos ou opções de comando ao redor aparecem em espaçamento fixo. Diferenças do Sistema Operacional Este manual utiliza a conenção UNIX para especificar ariáeis de ambiente e para notação do diretório. Ao utilizar a linha de comandos do Windows, substitua $ariable por %ariable% para ariáeis de ambiente e substitua cada barra (/) por uma barra inertida (\) nos caminhos de diretório. Se ocê for utilizar o shell bash em um sistema Windows, poderá utilizar as conenções UNIX. Prefácio xxi

xxii IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Capítulo 1. Apresentando o IBM Tioli Access Manager Plug-in para Web Serers O IBM Tioli Access Manager (Tioli Access Manager) Plug-in para Web Serers é uma solução de integração que facilita a implementação e o gerenciamento do critério de segurança para um espaço da Web protegido. Instalado como parte do mesmo processo que o seridor Web, o plug-in age como o gateway de segurança entre clientes e o espaço da Web protegido. Este capítulo introdutório fornece uma isão geral da tecnologia do Tioli Access Manager Plug-in para Web Serers, identifica os requisitos técnicos para o produto e fornece uma introdução aos processos para assegurar a segurança do espaço da Web com o uso desse plug-in. Nota: Para obter detalhes sobre plataformas suportadas, requisitos de disco e de memória, pré-requisitos de software e instruções de instalação para o plug-in, consulte o Tioli Access Manager for e-business Web Security: Guia de Instalação. Para obter detalhes sobre como fazer o upgrade do Tioli Access Manager Plug-in para Web Serers para a ersão 5.1, consulte o IBM Tioli Access Manager: Guia de Upgrade. Este capítulo introdutório contém os seguintes tópicos: Tecnologia do Tioli Access Manager Plug-in para Web Serers Protegendo o Espaço da Web com o Tioli Access Manager Plug-in para Web Serers na página 3 Autenticação do Tioli Access Manager Plug-in para Web Serers na página 4 Aquisição de Credenciais na página 5 Tecnologia do Tioli Access Manager Plug-in para Web Serers O Tioli Access Manager Plug-in para Web Serers pode ser integrado ao aplicatio Tioli Access Manager para fornecer uma solução de segurança completa para recursos da Web. O plug-in opera como parte do mesmo processo que o seridor Web, interceptando cada pedido que chega, determinando se uma decisão de autorização é requerida e fornecendo um meio para a autenticação do usuário, se necessário. Esse plug-in pode fornecer soluções de conexão única e incorporar recursos de aplicatios Web em seu critério de segurança. Arquitetura e Componentes Operacionais Básicos Dois componentes básicos de arquitetura compõem o Tioli Access Manager Plug-in para Web Serers o componente Plug-in e o Authorization Serer. O componente Plug-in opera com encadeamentos do seridor Web, eniando detalhes de cada pedido com o uso de uma interface IPC (Inter-Process Communication) com o Authorization Serer. O Authorization Serer executa a autenticação e a autorização de pedidos de entrada. Ele consistem em um aplicatio AZNAPI de modo local que aceita e processa pedidos a partir do plug-in e também fornece respostas, informando ao plug-in como tratar cada pedido. Copyright IBM Corp. 2000, 2003 1

Figura 1. Interação dos Componentes Plug-in e Tioli Access Manager. O Authorization Serer determina para qual host irtual o pedido é endereçado (se hosts irtuais estierem presentes no seridor Web) e determina se esse pedido requer autorização. Os pedidos que não requerem autorização são transmitidos diretamente ao seridor Web para processamento. Os pedidos que requerem autorização são processados pelo Authorization Serer da seguinte maneira: 1. As informações sobre sessão e autenticação são extraídas de pedidos que foram anteriormente autenticados. 2. Se necessário, uma interação de autenticação é iniciada com o usuário. 3. Uma credencial do Tioli Access Manager é criada. 4. Os recursos que o usuário pode acessar são identificados e, em seguida, mapeados para o nome do objeto protegido correspondente do Tioli Access Manager. Um nome de objeto protegido representa uma entidade eletrônica, como uma parte protegida de um site da Web ou um aplicatio que somente determinados usuários têm permissão para acessar. 5. É determinado se o pedido ou a resposta requer modificação. 6. As respostas requeridas pelo plug-in ou pelo seridor Web host são geradas por meio da inclusão de cookies ou de cabeçalhos no pedido ou na resposta ou por meio da geração de uma resposta (por exemplo, uma resposta autenticada ou uma resposta não autorizada). Suporte para Hosts Virtuais A capacidade de hospedagem irtual de um seridor Web permite que ele apareça como mais de um host na Internet. Todos os seridores Web suportados pelo Tioli Access Manager Plug-in para Web Serers fornecem essa capacidade de hospedagem irtual. O Tioli Access Manager Plug-in para Web Serers oferece a capacidade de implementar um critério de segurança para cada host irtual. A configuração de aplicatios necessária para implementar esse capacidade é discutida posteriormente neste documento. 2 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Protegendo o Espaço da Web com o Tioli Access Manager Plug-in para Web Serers O Tioli Access Manager Plug-in para Web Serers oferece os seguintes recursos: Suporta ários métodos de autenticação, incluindo autenticação básica, endereço IP, token, certificados e formulários, entre outros. Aceita pedidos HTTP e HTTPS. Protege os recursos do seridor Web autenticando e autorizando pedidos de usuários que dependem de um critério organizacional. Suporta a autenticação e a autorização de pedidos em um ambiente de host irtual. Gerencia o controle de acesso ao espaço do seridor Web. Os recursos suportados incluem URLs, expressões comuns com base em URL, programas CGI, arquios HTML, serlets Jaa e arquios de classes Jaa. Armazena em cache as informações de sessões e de credenciais para eliminar consultas repetitias no banco de dados de registros de usuários durante erificações de autorização. Fornece capacidades de conexão única. Um critério de segurança corporatio identifica os recursos da Web que requerem proteção, bem como o níel de proteção necessário para cada um desses recursos da Web. O Tioli Access Manager utiliza uma representação irtual desses recursos da Web, denominada espaço de objetos protegidos. O espaço de objetos protegidos contém objetos que representam os recursos físicos reais em uma rede. O critério de segurança é implementado com a aplicação dos mecanismos de segurança apropriados aos objetos que requerem proteção. Esses mecanismos de segurança incluem: Critérios ACL (lista de controle de acesso) Os critérios ACL identificam tipos de usuários que podem ser leados em consideração em termos de acesso e também especificam as operações permitidas sobre o objeto para cada um desses tipos. POPs (critérios de objetos protegidos) Um POP especifica condições adicionais que goernam o acesso ao objeto protegido, como acesso de priacidade, de integridade, de auditoria e de horário do dia. Regras de autorização Regras de autorização são condições contidas em um critério de autorização que são utilizadas para tomar decisões de acesso com base em atributos como usuário, aplicatio e contexto de ambiente. Atributos estendidos Atributos estendidos são alores adicionais colocados em um objeto, uma ACL ou um POP que podem influenciar uma decisão de autorização. É o componente Authorization Serer do Tioli Access Manager Plug-in para Web Serers que permite ou nega o acesso a recursos protegidos com base nas credenciais do usuário e nos controles de acesso estabelecidos sobre os objetos. Para implementar com êxito um critério de segurança, é necessário organizar logicamente os diferentes tipos de conteúdo e aplicar os critérios apropriados de ACL e POP. O gerenciamento do controle de acesso pode ser complexo, mas é facilitado por meio de uma cuidadosa categorização dos tipos de conteúdo. Capítulo 1. Apresentando o IBM Tioli Access Manager Plug-in para Web Serers 3

Informações abrangentes sobre o Tioli Access Manager, incluindo detalhes de critérios de definição, podem ser encontradas no documento IBM Tioli Access Manager Base: Guia do Administrador. Autenticação do Tioli Access Manager Plug-in para Web Serers Autenticação é o método de identificar uma entidade ou um processo indiidual que está tentando efetuar logon em um domínio protegido. Autorização é o método de determinar se um usuário autenticado tem o direito de executar uma operação em um recurso específico. A autenticação garante que o indiíduo é realmente quem ele alega ser, mas não esclarece nada sobre a capacidade de executar operações em um recurso. O Tioli Access Manager Plug-in para Web Serers impõe um alto grau de segurança em um domínio protegido, exigindo que cada cliente forneça uma proa de identidade. Uma segurança de rede abrangente pode ser oferecida fazendo com que o Tioli Access Manager Plug-in para Web Serers controle a autenticação e a autorização dos clientes. As condições a seguir aplicam-se à autenticação do Tioli Access Manager Plug-in para Web Serers: O plug-in suporta um conjunto padrão de métodos de autenticação. É possíel personalizar o plug-in para suportar outros métodos de autenticação. O processo do plug-in não depende do método de autenticação. O plug-in requer apenas uma identidade de cliente. A partir dessa identidade, ele obtém uma credencial autenticada (ou não autenticada) que pode ser utilizada pelo Authorization Serer para permitir ou negar o acesso a recursos. Essa abordagem flexíel sobre a autenticação permite que o critério de segurança tenha como base exigências de negócios em ez de uma topologia de rede física. O processo de autenticação do Tioli Access Manager Plug-in para Web Serers resulta nas seguintes ações: 1. A autenticação do cliente resulta em uma identidade de cliente. A autenticação do cliente apenas será bem-sucedida se o usuário tier uma conta definida no registro de usuários do Tioli Access Manager. Caso contrário, o usuário será designado como não autenticado. 2. O Tioli Access Manager Plug-in para Web Serers utiliza a identidade do cliente para obter credenciais para esse cliente. O plug-in corresponde a identidade do cliente autenticado a um usuário registrado do Tioli Access Manager. Em seguida, obtém as credenciais de usuário apropriadas. Esse processo é conhecido como aquisição de credenciais. Credenciais incluem o nome do usuário e qualquer grupo no qual o usuário possua uma participação. Essas credenciais estão disponíeis ao plug-in, que permite ou nega o acesso a objetos solicitados no espaço de objetos protegidos do Tioli Access Manager. Credenciais podem ser utilizadas por qualquer seriço Tioli Access Manager que necessite de informações sobre o cliente. Elas permitem que o Tioli Access Manager execute com segurança uma grande ariedade de seriços, como autorização, auditoria e delegação. 4 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Aquisição de Credenciais Consulte o Capítulo 3, Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers, na página 41 para obter informações adicionais sobre o suporte para métodos de autenticação específicos. A principal meta do processo de autenticação é a aquisição de informações de credenciais que descream o usuário do cliente. A credencial do usuário é um requisito essencial para participação no domínio protegido. O Tioli Access Manager faz uma distinção entre a autenticação do usuário e a aquisição de credenciais. A identidade de um usuário sempre é constante. Entretanto, as credenciais que definem os grupos ou as funções dos quais um usuário participa são ariáeis. Credenciais específicas para cada contexto podem ser alteradas ao longo do tempo. Por exemplo, quando uma pessoa é promoida, suas credenciais deem refletir o noo níel de responsabilidade. O processo de autenticação resulta em informações de identidade do usuário específicas para cada método. Essas informações são erificadas com base nas informações sobre a conta do usuário que residem no registro de usuários do Tioli Access Manager (LDAP por padrão). O Tioli Access Manager Plug-in para Web Serers faz o mapeamento das informações sobre grupo e nome do usuário para um formato e uma representação comuns em níel de domínio que recebem o nome de EPAC (Extended Priilege Attribute Certificate). Informações de identidade específicas para cada método, como senhas, tokens e certificados, representam propriedades físicas de identidade do usuário. Essas informações podem ser utilizadas para estabelecer uma sessão protegida com o seridor. A credencial resultante, que representa os priilégios de um usuário no domínio protegido, descree esse usuário em um contexto mais específico e apenas é álida durante a permanência dessa sessão. As credenciais do Tioli Access Manager contêm a identidade do usuário e os grupos dos quais ele participa. Credenciais são utilizadas por qualquer seriço Tioli Access Manager que necessite de informações sobre o cliente. Por exemplo, o Tioli Access Manager Authorization Serer utiliza credenciais para determinar se um usuário está autorizado a executar operações específicas em um recurso protegido no domínio protegido. Credenciais também são utilizadas em outras tarefas, como registro e auditoria. EPACs contêm os UUIDs (Unique Uniersal Identifiers) necessários para que o Tioli Access Manager trabalhe com ACLs (listas de controle de acesso). Os seguintes campos do EPAC são apropriados ao Tioli Access Manager: Tabela 1. Campos do EPAC para o Tioli Access Manager Atributo ID do Domínio Protegido UUID do Responsáel UUIDs de Grupos Descrição Identificador do domínio protegido inicial do responsáel UUID do responsáel UUIDs de grupos aos quais o responsáel pertence Capítulo 1. Apresentando o IBM Tioli Access Manager Plug-in para Web Serers 5

O Tioli Access Manager Plug-in para Web Serers pode ser configurado para atualizar as informações de credenciais para um usuário e, ao mesmo tempo, manter sua sessão atual. Essa funcionalidade é muito útil nos casos em que um usuário requer acesso extra a determinados aplicatios protegidos ou quando ocê deseja restringir o acesso de um usuário sem fazer com ele efetue logout de sua sessão atual. Para obter informações adicionais sobre como configurar o plug-in para a atualização de credenciais, consulte Atualização de Credenciais na página 35. 6 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers Este capítulo descree tarefas gerais de administração e de configuração que podem ser executadas para personalizar o IBM Tioli Access Manager (Tioli Access Manager) Plug-in para Web Serers. Os tópicos deste capítulo incluem: Informações Gerais sobre o Plug-in Configurando o Authorization Serer na página 11 Configurando para Seridores Host Virtuais na página 13 Configuração Específica para Cada Seridor Web na página 16 Personalizando Listas de Objetos na página 19 Configurando a Função SU (Comutação de Usuários) para Administradores na página 20 Configurando o Failoer para Seridores LDAP na página 26 Suportando Cabeçalhos P3P (Platform for Priacy Preferences) na página 27 Configurando a Auditoria, o Registro, o Rastreio e o Banco de Dados de Cache do Plug-in na página 30 Configurando o Seriço da API de Autorização na página 35 Atualização de Credenciais na página 35 Configurando o Armazenamento em Cache de Pedidos HTTP na página 37 Suporte a Idiomas e Conjuntos de Caracteres na página 37 Informações Gerais sobre o Plug-in As seções a seguir descreem informações gerais sobre a configuração do Tioli Access Manager Plug-in para Web Serers: Diretório Raiz da Instalação do Tioli Access Manager Plug-in para Web Serers O Arquio de Configuração pdwebpi.conf na página 8 O Arquio de Configuração pdwebpimgr.conf na página 9 Iniciando e Parando o Tioli Access Manager Plug-in para Web Serers na página 9 Mensagens de Erro HTTP na página 9 Suporte para Macros na página 10 Macros Relacionadas a Formulários na página 11 Diretório Raiz da Instalação do Tioli Access Manager Plug-in para Web Serers Os arquios de programas do Tioli Access Manager Plug-in para Web Serers são instalados no seguinte diretório raiz: UNIX: Windows: /opt/pdwebpi/ Copyright IBM Corp. 2000, 2003 7

C:\Arquios de programas\tioli\pdwebpi\ É possíel configurar esse caminho durante uma instalação do plug-in no Windows. Esse caminho não pode ser configurado em instalações no UNIX. Este guia utiliza a ariáel install_path para representar o diretório raiz. Em instalações no UNIX, o seguinte diretório separado contém arquios que podem ser expandidos, como arquios de auditoria e de log: /ar/pdwebpi/ Arquios de log serão graados no Diretório Tioli comum se ele tier sido escolhido durante a configuração do Tioli Access Manager Runtime. O Arquio de Configuração pdwebpi.conf É possíel personalizar a operação do plug-in configurando os parâmetros localizados no arquio de configuração pdwebpi.conf. Esse arquio está localizado no seguinte diretório: UNIX: Windows: install_path/etc/ install_path\etc\ A tabela a seguir categoria as sub-rotinas do arquio de configuração. Tabela 2. Resumo das Seções de pdwebpi.conf GENERAL Seções AUTHENTICATION SINGLE SIGNON VIRTUAL HOSTS SESSIONS LDAP LOGGING AUTHORIZATION SERVER P3P AUTHORIZATION API WEB SERVER Sub-rotinas [module-mgr] [modules] [wpiconfig] [pdweb-plugins] [performance] [common-modules] [authentication-leels] [authentication-mechanisms] [user-agent] [acctmgmt] [BA] [failoer] [failoer-add-attributes] [failoer-restore-attributes] [forms] [login-form-1] [ltpa] [tag-alue] [token-card] [http-hdr] [i-headers] [login-redirect] [ntlm] [spnego] [boolean-rules] [switch-user] [dynurl] [cred-refresh] [ext-auth-int] [auth-data] [http-method-perms] [web-serer-authn] [fsso] [ecsso] [ecsso-domain-keys] [ecsso-tokenattributes] [ecsso-incoming-attributes] [cdsso] [cdsso-domain-keys] [cdsso-token-attributes] [cdsso-incoming-attributes] [irtual-host-name] [sessions] [session-cookie] [ldap] [web-log] [proxy-if] [proxy] [p3p-header] [aznapi-entitlement-serices] [aznapi-configuration] [ihs] [iis] [iplanet] [apache] 8 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Consulte o Apêndice B, Referência de pdwebpi.conf, na página 193 para obter uma descrição dos parâmetros configuráeis no arquio de configuração pdwebpi.conf. Nota: Sempre que uma alteração é feita no arquio pdwebpi.conf, ocê dee iniciar noamente o Tioli Access Manager Plug-in para Web Serers de forma manual para que as noas alterações sejam reconhecidas. Consulte Iniciando e Parando o Tioli Access Manager Plug-in para Web Serers para obter informações sobre como iniciar e parar o aplicatio. O Arquio de Configuração pdwebpimgr.conf Instalações no UNIX do plug-in incluem o arquio de configuração pdwebpimgr.conf. Esse arquio de configuração contém parâmetros que são utilizados para iniciar noamente o daemon de autorização de forma automática se esse daemon apresentar uma falha. Esse arquio está localizado no diretório: install_path/etc/ Não existem motios para alterar os parâmetros nesse arquio. Iniciando e Parando o Tioli Access Manager Plug-in para Web Serers Para iniciar e parar o processo do plug-in, utilize o comando pdwebpi_start no UNIX e o Painel de Controle de Seriços no Windows. UNIX: pdwebpi_start {start stop restart status} Por exemplo, para parar o plug-in e, em seguida, iniciá-lo noamente, utilize: # pdwebpi_start restart O comando pdwebpi_start está localizado no seguinte diretório: install_path/sbin/ Windows: Identifique o processo do plug-in no Painel de Controle de Seriços e utilize os botões de controle apropriados. Nota: pdwebpi corresponde ao processo do Authorization Serer. Em instalações no UNIX, o processo pdwebpimgrd iniciará noamente, de forma automática, o Authorization Serer se ele apresentar uma falha. No Windows, o Authorization Serer é iniciado automaticamente, de forma automática, pelos seriços do Windows. Mensagens de Erro HTTP Em algumas situações, o Tioli Access Manager Plug-in para Web Serers tenta atender a um pedido e apresenta uma falha. Pode haer árias causas para essa falha. Duas causas comuns de falha são: Um arquio não existe As definições de permissão proíbem o acesso Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 9

Quando ocorre uma falha ao atender a um pedido, o plug-in retorna um código de erro ao seridor Web, que interpreta esse código e exibe uma página de erro correspondente. Personalizando a Exibição de Mensagens de Erro do IIS O IIS fornece a capacidade de personalizar o formato e o conteúdo das páginas de erro exibidas aos clientes. Isso é útil para a exibição de informações de erro mais detalhadas a esses clientes. O plug-in pode utilizar esse recurso de personalização de erros no IIS. Com o uso do parâmetro use-error-pages na sub-rotina [iis] do arquio de configuração pdwebpi.conf, é possíel escolher se as páginas de erro configuradas ou as páginas de códigos de erro padrão do IIS serão retornadas ao naegador do cliente. Definido como yes, o parâmetro use-error-pages faz com que o plug-in utilize qualquer página de erro personalizada do IIS. Definido como no, páginas de erro padrão são exibidas para os erros encontrados pelo Authorization Serer. Por padrão, o parâmetro use-error-pages é definido como no. Nota: Definir use-error-pages como yes, o que conseqüentemente permite a exibição de páginas de erro personalizadas do IIS para erros do Authorization Serer, causa uma degradação significatia no desempenho do plug-in. Suporte para Macros As macros a seguir estão disponíeis para uso na personalização de páginas de erro HTML. Essas macros substituem dinamicamente as informações apropriadas que estão disponíeis. Tabela 3. Substituições de Macros Suportadas Macro %USERNAME% %ERROR_CODE% %ERROR_TEXT% %URL% %HOSTNAME% %HTTP_BASE% %HTTPS_BASE% %HTTP_BODY% %REFERER% %BACK_URL% %BACK_NAME% %POST_URL% %COOKIES% Descrição O nome do usuário que efetuou login Um código de erro numérico associado a um erro Texto de erro associado a um erro O URL solicitado pelo cliente Nome completo do host URL HTTP base do seridor: http://host:tcpport/ URL HTTPS base do seridor: https://host:sslport/ O corpo do pedido, se houer. O alor do cabeçalho referente do pedido ou Unknown se não houer um cabeçalho referente O alor do cabeçalho referente do pedido ou / se não houer um cabeçalho referente O alor BACK se um cabeçalho referente estier presente no pedido ou HOME se não houer um cabeçalho referente. O URL POST configurado para qualquer um dos formulários fornecidos pelo Tioli Access Manager. Qualquer cookie encontrado no pedido. 10 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Macros Relacionadas a Formulários O Tioli Access Manager Plug-in para Web Serers fornece os seguintes formulários, localizados no diretório /opt/pdwebpi/nls/html/lang/charset: comutação de usuários, token, login por formulários, alteração de senha. Esses formulários foram configurados com a macro %POST_URL%. Essa macro permite que o plug-in enie noamente quaisquer dados POST que possam ter sido incluídos no pedido original. Sem a macro %HTTP_BODY%, todos os dados POST fornecidos com o pedido original serão perdidos depois que o plug-in concluir o processamento do formulário. Os formulários padrão também foram configurados para armazenar em cache todos os dados de sessão necessário dentro do próprio formulário. Esses dados de sessão incluem o URL originalmente solicitado, o referente para esse URL originalmente solicitado e o corpo do pedido original. Configurando o Authorization Serer A maioria do processamento de autorizações e de autenticações é tratada pelo Authorization Serer. O Authorization Serer oferece um conjunto de encadeamentos subordinados que: Aceitam pedidos do plug-in, Eniam resultados de cada pedido de olta ao plug-in. O plug-in comunica-se com o Authorization Serer por meio de um mecanismo IPC implementado com o uso de memória compartilhada. A sub-rotina [proxy-if] no arquio de configuração pdwebpi.conf especifica parâmetros de configuração relacionados à comunicação entre o plug-in e o Authorization Serer. Configurando Encadeamentos Subordinados Os parâmetros number-of-workers e worker-size na sub-rotina [proxy-if] do arquio de configuração especificam alores que podem ser ajustados para proporcionar o desempenho ideal do plug in e do Authorization Serer. Considere a quantidade e o tipo de tráfego na rede ao definir esses alores. [proxy-if] number-of-workers = 10 worker-size = 10000 cleanup-interal=300 O parâmetro number-of-workers especifica o número de pedidos de entrada simultâneos que podem ser atendidos pelo plug-in. Os pedidos que chegam quando todos os encadeamentos subordinados estão ocupados são armazenados no buffer até que um encadeamento subordinado fique disponíel. Esse parâmetro simplesmente especifica o número de encadeamentos disponibilizados para atender a uma fila de trabalho potencialmente ilimitada. Ele dee ser aumentado de acordo com o número máximo de pedidos que ocê espera que o seridor Web aceite simultaneamente. Em plataformas UNIX, o sistema operacional pode impor limites sobre esse alor. Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 11

Ao aumentar o número de encadeamentos, ocê, em geral, diminui o tempo médio necessário para finalizar os pedidos. Entretanto, aumentar esse número influencia outros fatores que poderiam exercer um efeito colateral sobre o desempenho do seridor. O parâmetro worker-size define a quantidade de memória (em bytes) que está pré-alocada para cada encadeamento subordinado. O parâmetro cleanup-interal corresponde ao tempo, em minutos, entre limpezas sucessias da memória compartilhada do Authorization Serer. Nota: Altere os parâmetros cleanup-interal e worker-size apenas para solucionar problemas de desempenho. Definindo a Duração Máxima de Sessões para Pedidos IPC O parâmetro max-session-lifetime na sub-rotina [proxy-if] do arquio de configuração pdwebpi.conf define o tempo, em segundos, durante o qual o plug-in aguarda uma resposta do Authorization Serer antes de atingir o tempo limite. Esse parâmetro apenas está relacionado à sessão de curta duração estabelecida entre o plug-in e o Authorization Serer para o tratamento de pedidos. Se esse tempo limite for atingido, uma página de erro será eniada ao cliente. Esses tempos limites são muito improáeis. [proxy-if] max-session-lifetime = 300 Nota: O parâmetro max-session-lifetime não controla a duração de sessões autenticadas. A duração de sessões autenticadas é controlada pelo parâmetro timeout na sub-rotina [sessions]. Configurando Páginas de Erro Na sub-rotina [proxy] do arquio de configuração pdwebpi.conf, existem parâmetros para a especificação das páginas HTML a serem exibidas quando ocorrerem erros no proxy. Os parâmetros definidos na sub-rotina [proxy] são: error-page, acct-locked-page, retry-limit-reached-page e login-success. Existem arquios padrão para esses parâmetros. Esses arquios podem ser editados ou um noo arquio pode ser especificado para atender às exigências da sua organização. A tabela a seguir resume os parâmetros. Tabela 4. Parâmetros de Configuração de Páginas de Erro de [proxy]. error-page acct-locked-page Parâmetro retry-limit-reached-page Descrição O caminho para a página exibida no naegador do usuário quando ocorre um erro inesperado do seridor. O caminho para a página exibida quando um usuário tenta acessar uma conta bloqueada. O caminho para a página exibida quando o número máximo permitido de tentatias fracassadas de logon for atingido. O número máximo de falhas de logon permitidas é definido no LDAP. Consulte Três Critérios de Logon de Orientação na página 120 para obter detalhes sobre como definir esse alor. 12 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 4. Parâmetros de Configuração de Páginas de Erro de [proxy]. (continuação) login-success Parâmetro Descrição Especifica a página a ser exibida quando o plug-in não possui uma página para a qual redirecionar o usuário após um login bem-sucedido de token ou formulários. Essa situação pode ocorrer quando ocê constrói um formulário de login que retorna diretamente ao plug-in os dados POST de login. Por padrão, as páginas HTML de amostra estão localizadas no seguinte diretório: install_path/nls/html/lang/charset. Em que: lang é obtido a partir da configuração do NLS. Em uma instalação no idioma inglês (EUA), lang será definido como C. charset corresponde ao conjunto de caracteres no qual a página é codificada. O padrão é utf-8. Para obter detalhes sobre o suporte a idiomas do plug-in, consulte Suporte a Idiomas e Conjuntos de Caracteres na página 37. Configurando para Seridores Host Virtuais Hosts irtuais são identificados no Tioli Access Manager Plug-in para Web Serers por um nome arbitrário que é definido na sub-rotina [pdweb-plugins] do arquio de configuração pdwebpi.conf. O plug-in pode aplicar um critério de segurança distinto de acordo com duas características de um pedido: um ID para o host irtual ao qual o pedido foi endereçado, o protocolo (http ou https) pelo qual o pedido chegou. O ID do host irtual é deriado das informações de configuração do seridor Web host e é específico para cada seridor Web. Ele é determinado da seguinte maneira: IHS e Apache O algoritmo de configuração utilizado para construir IDs de hosts irtuais é: 1. Se existir uma diretriz SererName em um bloco <VirtualHost {hosta}:{port} {hostb}:{port}...>, esse nome será utilizado para construir o espaço de objetos para cada host na lista de hosts irtuais. Não será feita nenhuma tentatia de resoler o nome do seridor fornecido em um nome do host completo. 2. Se não existir uma diretriz SererName no bloco VirtualHost e os nomes de host na lista não forem endereços IP numéricos, será feita uma tentatia de qualificar totalmente cada nome e, em seguida, de criar espaços de objetos para cada nome de host distinto. 3. Se não existir uma diretriz SererName no bloco VirtualHost e os nomes de host na lista forem endereços IP numéricos, será feita uma tentatia de resoler cada endereço IP em um nome de host completo. 4. Se ainda não existir um nome de host e se um nome tier sido especificado em uma diretriz SererName global, esse nome será utilizado (sem nenhuma resolução). 5. Se não existir uma diretriz SererName global, a ersão completa do nome do host do sistema será utilizada. Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 13

IIS 5.0 e 6.0 Sun ONE Web Serer (antigo iplanet) O ID corresponde exatamente ao nome do site da Web que é mostrado no snap-in de gerenciamento do Internet Information Serices. Por exemplo, o site da Web padrão criado quando o IIS é configurado recebe o nome de Site da Web Padrão, que corresponde ao ID utilizado pelo Tioli Access Manager Plug-in para Web Serers. O ID corresponde exatamente ao nome do host irtual especificado durante a criação desse host irtual na GUI de configuração do Sun ONE Web Serer. Esse nome é armazenado no elemento <VS id= > do arquio serer.xml. O Tioli Access Manager Plug-in para Web Serers define o critério de segurança em termos de hosts irtuais. Um host irtual do Tioli Access Manager Plug-in para Web Serers é identificado por um ID de host irtual, conforme definido anteriormente, e pelo conjunto de protocolos (http, https ou ambos) que ele dee proteger. O host irtual define o conjunto e a precedência de esquemas de autenticação, de esquemas de identificação de sessões e do tratamento pós-autorização que dee ser aplicado a pedidos para o host irtual do seridor Web por meio de um dos protocolos correspondentes. O host irtual também define o mapeamento de URIs para nomes do Espaço de Objetos Protegidos do Tioli Access Manager. Os hosts irtuais do Tioli Access Manager Plug-in para Web Serers são definidos na sub-rotina [pdweb-plugins] do arquio de configuração. Eles podem ser definidos como protegidos ou não protegidos. Um host irtual não protegido não terá um critério de segurança do Tioli Access Manager aplicado. Se um pedido for recebido e ele não corresponder a nenhum dos hosts irtuais protegidos ou não protegidos definidos, uma mensagem de aiso será gerada no arquio de log do Authorization Serer indicando o ID do host irtual e o protocolo do pedido, e o acesso será concedido a esse pedido. Isso facilita o diagnóstico de problemas de configuração. Hosts irtuais protegidos são definidos pelo parâmetro irtual-host da sub-rotina [pdweb-plugins]. Hosts irtuais não protegidos são definidos pelo parâmetro unprotected-irtual-host da sub-rotina [pdweb-plugins]. O nome do host irtual utilizado normalmente corresponde ao ID do host irtual ao qual esse host irtual corresponde, mas isso nem sempre é necessariamente o caso. Na erdade, os nomes dos hosts irtuais definidos na sub-rotina [pdweb-plugins] são utilizados para definir o critério de segurança específico para cada host irtual. O critério de segurança para um host irtual específico é definido pelos parâmetros de configuração determinados em uma sub-rotina com o nome desse host irtual. Todos os parâmetros que podem ser definidos na sub-rotina do host irtual possuem alores padrão apropriados e, portanto, não é necessário ter uma sub-rotina para cada host irtual. Somente será necessário ter essa sub-rotina se o critério de segurança para o host irtual for diferente do padrão. Dois parâmetros do host irtual são utilizados para corresponder um pedido de entrada para o host irtual que define o critério de segurança que dee ser aplicado a esse pedido. Esses parâmetros são id e protocols. O parâmetro id é definido para ser o ID do host irtual ao qual esse host irtual será correspondido. O alor padrão para o parâmetro id é o próprio nome do host irtual. O parâmetro protocols define o conjunto de protocolos ao qual o host irtual será correspondido. Esse alor pode ser http, https ou both. O alor padrão é both. 14 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Os parâmetros restantes do host irtual definem o critério de segurança que dee ser aplicado a pedidos que correspondem a esse host irtual. Hosts irtuais são associados a uma sub-ramificação específica do espaço de objetos protegidos. O URI de um pedido é prefixado com essa sub-ramificação para construir um nome de espaço de objetos protegidos. Esse nome de espaço de objetos protegidos é utilizado para a tomada de decisões de autorização. O parâmetro de configuração branch define o nome desse espaço de objetos protegidos. [irtual_host_name] branch = irtual_host_id Se o alor do ID do host irtual não tier uma barra inertida (/) à esquerda, a entrada será prefixada com /PDWebPI/. O parâmetro branch assume como padrão o alor do parâmetro id, resultando em um prefixo de nome de objeto padrão igual a /PDWebPI/irtual-host-id. Explicação das ramificações de hosts irtuais Durante a configuração do plug-in, é criado um espaço de objetos denominado /PDWebPI. Dentro desse espaço de objetos, são criadas entradas para cada um dos hosts irtuais protegidos pelo plug-in. O espaço de objetos em um objeto Host Virtual pertence ao Authorization Serer do plug-in que toma decisões de autorização para os recursos no espaço de objetos desse host irtual. Por padrão, a ramificação do espaço de objetos utilizado para um host irtual obtém seu nome a partir do ID do host irtual. Se for necessário utilizar uma ramificação diferente do espaço de objetos /PDWebPI, a extensão branch será utilizada para especificar isso. Ramificações podem ser compartilhadas entre hosts irtuais. Isso pode acontecer quando os hosts irtuais são aliases entre si. Nota: Quando uma ramificação é alterada, um objeto precisa ser criado com o noo nome. Todas as ACLs anexadas à ramificação antiga permanecem anexadas aos objetos que, nesse ponto, não existem mais. O exemplo a seguir mostra os parâmetros de configuração necessários para um seridor Web que possui quatro hosts irtuais: ibm.com, lotus.com-http, lotus.com-https, domino.com. Os hosts irtuais lotus.com-http e lotus.com-https são realmente o mesmo host irtual, pois compartilham a mesma ramificação. Entretanto, são diferenciados pelo tipo de acesso (HTTP ou HTTPS). Nesse caso, a configuração da autenticação pode ser definida de maneira diferente, dependendo do tipo de acesso. domino.com não está protegido pelo plug-in, e ibm.com é outro host irtual no mesmo seridor. [pdweb-plugins] irtual-host = ibm.com irtual-host = lotus.com-https irtual-host = lotus.com-http unprotected-irtual-host = domino.com web-serer = iplanet [lotus.com-https] id = lotus.com protocols = https Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 15

branch = lotus.com [lotus.com-http] id = lotus.com protocols = http branch = lotus.com [ibm.com] id = ibm.com protocols = http, https branch = ibm.com Certifique-se de iniciar noamente o seridor Web sempre que ocê fizer uma alteração na configuração de hosts irtuais no arquio de configuração pdwebpi.conf. Uma configuração adicional para cada host irtual é necessária de forma a definir os parâmetros de autenticação para cada host irtual indiidual. Consulte Configurando a Autenticação para Hosts Virtuais na página 45 para obter detalhes sobre como configurar métodos de autenticação para hosts irtuais. Configuração Específica para Cada Seridor Web Algumas das ações do plug-in são específicas para o seridor Web e, portanto, requerem uma configuração específica, dependendo do tipo de seridor Web no qual esse plug-in está operando. Utilize o parâmetro web-serer na sub-rotina [pdweb-plugins] do arquio de configuração pdwebpi.conf para definir o tipo de seridor Web. Os alores álidos são ihs, iplanet, iis ou apache. Por exemplo: [pdweb-plugins] web-serer = ihs Existem itens de configuração específicos para cada seridor Web nas sub-rotinas [iis], [ihs], [apache] e [iplanet] do arquio de configuração pdwebpi.conf. Alguns parâmetros de configuração do seridor Web podem ser definidos para cada ramificação, anexando a ramificação completa do host irtual à sub-rotina. Por exemplo, [iplanet:/pdwebpi/lotus.com]. Os parâmetros relacionados à naegação no espaço da Web podem ser configurados dessa maneira. A tabela a seguir explica os parâmetros configuráeis para tipos específicos de seridores Web. Tabela 5. Parâmetros de Configuração Específicos para cada Seridor Web [ihs] Parâmetro query-contents query-log-file Descrição Especifica o programa de conteúdo de consultas a ser utilizado para naegar no espaço da Web do IBM HTTP Serer pelo comando pdadmin> object list. Esse parâmetro pode ser substituído para cada ramificação por meio da especificação de um alor para ele em uma sub-rotina denominada [ihs:branch], por exemplo, [ihs:/pdwebpi/lotus.com] Localização do arquio de log para erros encontrados pelo programa de conteúdo de consultas. 16 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 5. Parâmetros de Configuração Específicos para cada Seridor Web (continuação) [apache] query-contents query-log-file doc-root [iis] [iplanet] Parâmetro doc-root query-contents query-log-file log-file Descrição Especifica a raiz da documentação que fornece a capacidade de naegação no espaço da Web necessária para executar comandos pdadmin> object list. Esse parâmetro é definido pelo utilitário de configuração ao configurar hosts irtuais. Ele é especificado para cada ramificação de critério em uma sub-rotina [ihs:branch], por exemplo, [ihs:/pdwebpi/lotus.com] Especifica o programa de conteúdo de consultas a ser utilizado para naegar no espaço da Web do Apache pelo comando pdadmin> object list. Esse parâmetro pode ser substituído para cada ramificação por meio da especificação de um alor para ele em uma sub-rotina denominada [apache:branch], por exemplo, [apache:/pdwebpi/lotus.com] Localização do arquio de log para erros encontrados pelo programa de conteúdo de consultas. Especifica a raiz da documentação que fornece a capacidade de naegação no espaço da Web necessária para executar comandos pdadmin> object list. Esse parâmetro é definido pelo utilitário de configuração ao configurar hosts irtuais. Ele é especificado para cada ramificação de critério em uma sub-rotina [apache:branch], por exemplo, [apache:/pdwebpi/lotus.com] Especifica o programa de conteúdo de consultas para naegar no espaço da Web do IIS pelo comando pdadmin. Esse parâmetro pode ser substituído para cada ramificação por meio da especificação de um alor para ele em uma sub-rotina denominada [iis:branch], por exemplo, [iis:/pdwebpi/lotus.com] Localização do arquio de log para erros encontrados pelo programa de conteúdo de consultas. Define o arquio de log para mensagens de rastreio e erro a partir do plug-in para ISS. Essas mensagens são mantidas separadas do arquio de log do Authorization Serer de forma a garantir a consistência dos arquios. Se for especificado como um caminho relatio, a localização estará relacionada ao subdiretório de log do diretório de instalação. Se for especificado como um caminho absoluto, esse caminho absoluto será utilizado. Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 17

Tabela 5. Parâmetros de Configuração Específicos para cada Seridor Web (continuação) Parâmetro query-contents query-log-file doc-root Descrição Especifica o programa de conteúdo de consultas para naegar no espaço da Web do Sun ONE (iplanet) pelo comando pdadmin. Esse parâmetro pode ser substituído para cada ramificação por meio da especificação de um alor para ele em uma sub-rotina denominada [iplanet:branch], por exemplo, [iplanet:/pdwebpi/lotus.com] Localização do arquio de log para erros encontrados pelo programa de conteúdo de consultas. Especifica a raiz da documentação que fornece a capacidade de naegação no espaço da Web necessária para executar comandos pdadmin> object list. Esse parâmetro é definido pelo utilitário de configuração ao configurar hosts irtuais. Ele é especificado para cada ramificação de critério em uma sub-rotina [iplanet:branch], por exemplo, [iplanet:/pdwebpi/lotus.com] No exemplo a seguir, os hosts irtuais ibm.com e lotus.com possuem uma sub-rotina correspondente no arquio de configuração: [iplanet:/pdwebpi/ibm.com] e [iplanet:/pdwebpi/lotus.com], em que parâmetros de configuração específicos estão definidos. [pdweb-plugins] irtual-host = ibm.com irtual-host = lotus.com web-serer = iplanet [iplanet] query-contents = /opt/pdweb/bin/wpi_iplanet_ls [iplanet:/pdwebpi/ibm.com] doc-root = /usr/local/ibm.com/doc/root [iplanet:/pdwebpi/lotus.com] doc-root = /usr/local/lotus.com/doc/root Considerações sobre Seridores Web IIS Ao configurar definições de segurança do IIS com o uso da guia Directory Security (Segurança de Diretórios) no diálogo Properties (Propriedades) do seridor Web, é importante lembrar que algumas das definições de segurança configuráeis podem ser herdadas por meio da hierarquia do espaço da Web. O plug-in cria dinamicamente objetos irtuais do espaço da Web para tratar diersas funções. As definições de segurança nesses objetos são geralmente importantes. É essencial que as propriedades de segurança nesses objetos não sejam alteradas. Após a modificação das definições de segurança do IIS na guia Directory Security (Segurança de Diretórios) do diálogo Properties (Propriedades), o diálogo Inheritance Oerrides (Substituições de Herança) é exibido. O diálogo Inheritance Oerrides (Substituições de Herança) lista Child Nodes (Nós Filho) que substituem o alor que 18 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

ocê acabou de definir. Existe a opção de escolher quais nós deem utilizar o noo alor. Os nós PDWebPI não deem ser selecionados nesse diálogo. Apache e IHS Desatiando Multiiews: Ao utilizar o Apache Web Serer ou o IHS Web Serer, a diretriz MultiViews no diretório raiz dee ser desatiada. A atiação da diretriz MultiViews faz com que a erificação de autenticação feita pelo Tioli Access Manager Plug-in para Web Serers seja ignorada, comprometendo a segurança do seridor Web. A diretriz Multiiews está atiada por padrão no diretório raiz de documentos do Apache. Configuração para Scripts PHP: O Tioli Access Manager Plug-in para Web Serers apenas funciona corretamente quando os scripts PHP são tratados internamente para o seridor Web, com o uso do suporte PHP configurado como uma implementação de módulo. Personalizando Listas de Objetos O Tioli Access Manager Plug-in para Web Serers fornece um arquio binário para cada seridor Web suportado que é utilizado para determinar a saída para um comando de exibição de objetos ou uma lista de objetos de administração pdadmin. A tabela a seguir indica os nomes binários padrão e suas localizações: iplanet install_path/bin/wpi_apache_ls IHS install_path/bin/wpi_ihs_ls IIS install_path/bin/wpi_iis_ls Se ocê precisar de capacidades de naegação que não fazem parte da funcionalidade padrão, será necessário desenoler seu próprio binário personalizado de forma a substituir o binário fornecido com o plug-in. Ao desenoler um binário personalizado, as seguintes orientações são aplicáeis: Argumentos de Linha de Comandos iplanet,ihs,apache directory irtual_host log_file [-d] Em que: directory O caminho absoluto para o diretório ou arquio a ser listado ou exibido. irtual_host O host irtual para o diretório ou o arquio. log_file O caminho absoluto para um arquio que conterá todas as informações sobre erros geradas pela ação. -d Quando a opção -d é especificada, uma exibição de objetos é executada em ez de uma lista de objetos. IIS [-log log_file] -path directory -host irtual_host [-d] Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 19

Em que: log_file directory irtual_host O caminho absoluto para um arquio que conterá todas as informações sobre erros geradas pela ação. O caminho absoluto para o diretório ou arquio a ser listado ou exibido. O host irtual para o diretório ou o arquio. -d Quando a opção -d é especificada, uma exibição de objetos é executada em ez de uma lista de objetos. Saída Para cada entrada listada, o formato da saída será: <Object Type=[type] Description=[description] Attachable=[yes/no]> [name] </Object> Em que: tipo description attachable name Um número que indica o tipo de objeto. Os alores atuais incluem: 0 Desconhecido 1 Domínio 2 Arquio 3 Programa 4 Diretório 5 Campos de Junção 9 Seridor HTTP 10 Objeto Inexistente 11 Contêiner 12 Folha 14 Contêiner de Aplicatio 15 Folha de Aplicatio Uma descrição textual do objeto. Se o critério pode ou não ser anexado ao objeto. O nome do objeto. Esse nome não dee conter nomes de diretório na frente. Por exemplo: <Object Type=2 Description="File" Attachable="yes"> apache.gif </Object> Configurando a Função SU (Comutação de Usuários) para Administradores A funcionalidade de comutação de usuários do Plug-in para Web Serers permite que administradores específicos assumam a identidade de um usuário que é membro do domínio protegido do Tioli Access Manager. A implementação da função Comutação de Usuários é semelhante ao comando su em ambientes UNIX. No ambiente do plug-in, o administrador obtém as credenciais erdadeiras do usuário e interage com recursos e aplicatios backend possuindo exatamente as mesmas habilidades do usuário real. 20 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

A função Comutação de Usuários é uma ferramenta de Suporte útil para a resolução e o diagnóstico de problemas. Essa função também pode ser utilizada para testar o acesso de um usuário a recursos e para executar testes de integração de aplicatios. Os itens a seguir realçam as características importantes da função Comutação de Usuários: A função Comutação de Usuários não requer a senha do usuário. O administrador utiliza uma credencial que representa o usuário real. A função Comutação de Usuários está restrita a membros de um grupo especial do administrador. Um administrador não pode utilizar essa função com nenhum outro membro desse grupo. Processos do Tioli Access Manager, o usuário sec_master e outros usuários selecionados podem ser excluídos das capacidades da função Comutação de Usuários por meio de uma associação em um grupo de exclusão. Um formulário HTML especial é utilizado para fornecer informações sobre a função Comutação de Usuários e para atiar um mecanismo de autenticação especial que retorna a credencial do usuário especificado sem exigir uma senha. O administrador usa o utilitário pkmslogout para finalizar uma sessão de comutação de usuários. Compreendendo o Fluxo do Processo de Comutação de Usuários A seqüência a seguir descree o fluxo do processo de comutação de usuários: 1. O processo é iniciado com um administrador autenticado que é membro do grupo su-admins. 2. Esse administrador conecta-se a um formulário HTML de comutação de usuários pré-configurado. Esse formulário apenas pode ser acessado por membros do grupo su-admins. Se o usuário não for membro do grupo su-admins, uma página Not Found (Não Encontrado) será retornada. 3. O formulário de comutação de usuários é preenchido e retornado com as seguintes informações: nome do usuário (o administrador é comutado para esse usuário), um URL de destino e um método de autenticação. Essa ação resulta no enio de um pedido POST para /pkmssu.form. 4. Duas erificações são feitas antes que a comutação seja autorizada. a. O plug-in erifica se o usuário comutado é membro do grupo su-admins. Um usuário não pode se transformar em outro usuário que é membro do grupo su-admins. b. O plug-in erifica se o usuário comutado é membro do grupo su-excluded. Nenhum usuário tem permissão para se transformar em um membro do grupo su-excluded. Será retornado um erro se ocorrer uma falha em uma dessas erificações. Todos os pedidos subseqüentes são gerados como se tiessem sido feitos pelo usuário comutado. 5. O administrador permanece como o usuário comutado até o utilitário padrão /pkmslogout do Tioli Access Manager ser chamado. Nesse momento, o usuário comutado efetua logout e o administrador retorna à sua sessão original. Atiando a Função Comutação de Usuários A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a funcionalidade de Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 21

comutação de usuários, o módulo switch-user precisa ser configurado como um módulo de pré-autorização. Isso permite que a função Comutação de Usuários acesse um usuário antes que a autorização seja executada. [common-modules]... pre-authzn = switch-user... Nota: Se o módulo acctmgmt for configurado como um módulo de pré-autorização junto com o módulo switch-user, o módulo switch-user deerá aparecer na lista antes do módulo acctmgmt. Assegure-se de que a entrada para a função Comutação de Usuários esteja presente na sub-rotina [modules] do arquio de configuração pdwebpi.conf. Por exemplo: [modules]... switch-user = pdwpi-su-module... Configurando o Formulário HTML de Comutação de Usuários O formulário de comutação de usuários é definido na sub-rotina [switch-user] do arquio de configuração pdwebpi.conf. O parâmetro switch-user-form especifica o nome do arquio. Por padrão, o nome do arquio é switchuser.html e está localizado no diretório install_path/nls/html/lang/charset. Em sistemas no idioma inglês (EUA), o diretório lang é chamado de C e charset corresponde a utf-8. [switch-user] switch-user-form = switchuser.html O parâmetro switch-user-uri contém o URI que é utilizado para chamar a função Comutação de Usuários. Obsere que o critério de autorização padrão não é aplicado a esse URI. A erificação de autorização com base em grupos é realizada no lugar da erificação de ACLs. [switch-user] switch-user-uri = /switchuser.html O parâmetro switch-user-post-uri especifica o URI para o qual o formulário de comutação de usuários será submetido: [switch-user] switch-user-post-uri = /pkmssu.form O formulário de comutação de usuários pode ser editado para obter uma aparência e uma funcionalidade personalizadas. Esse formulário contém pedidos para: Nome do usuário (o administrador é comutado para esse usuário) Esse usuário não pode ser membro de su-excluded, de securitygroup ou de su-admins. URL de Destino Essa página é exibida após uma operação bem-sucedida de comutação de usuários. É possíel configurar esse URL como uma entrada oculta que contém uma home page apropriada ou uma página de confirmação de comutação de usuários bem-sucedida. Método de autenticação O método de autenticação determina os tipos de informações utilizadas para construir a credencial do usuário. É possíel configurar esse campo como uma entrada oculta. Consulte as notas a seguir para conhecer uma lista dos parâmetros álidos de método de autenticação. 22 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

A macro %CUSTOM% está incluída no formulário padrão e pode ser utilizada para incluir automaticamente no formulário todos os mecanismos configurados de autenticação com base em comutação de usuários. Notas sobre o formulário de comutação de usuários: O formulário apenas está disponíel para membros do grupo su-admins. Uma ACL não é necessária nesse arquio. O plug-in executa uma erificação de associação de grupos com um código permanente interno. O plug-in retorna um erro 404 Not Found (Não Encontrado) quando ocorre uma falha na erificação de associação de grupos. O nome do usuário, o URL de destino e o método de autenticação são dados necessários. Os dados necessários podem ser construídos no formulário como campos ocultos. O plug-in erifica se todos esses dados necessários estão presentes no formulário submetido. Se houer dados ausentes, o formulário será retornado ao administrador com uma mensagem descritia. Os alores álidos para o método de autenticação incluem: su-password su-token-card su-certificate su-http-request su-cdsso Esses parâmetros de método de autenticação especificam qual mecanismo de autenticação o plug-in dee utilizar. Os dados do formulário de comutação de usuários são submetidos ao URL da ação /pkmssu.form. Atiando e Excluindo Usuários da Função Comutação de Usuários Somente os administradores que são membros do grupo su-admins podem utilizar a função Comutação de Usuários e receber o formulário HTML de comutação de usuários. A funcionalidade de comutação de usuários é atiada para qualquer usuário que seja membro do grupo su-admins. Os administradores podem utilizar a função Comutação de Usuários com qualquer conta do Tioli Access Manager, exceto com as contas que pertencem a determinados grupos. É possíel excluir da função Comutação de Usuários outros usuários do Tioli Access Manager por meio da associação no grupo su-excluded. Além disso, os membros do grupo securitygroup do Tioli Access Manager estão excluídos da funcionalidade de comutação de usuários. Normalmente, o usuário sec_master e os processos do Tioli Access Manager são membros de securitygroup. Durante a comutação de usuários, o plug-in executa erificações em todos os três grupos. Não é possíel comutar um usuário que seja membro do grupo su-admins, su-excluded ou securitygroup. Configurando o Mecanismo de Autenticação com Base em Comutação de Usuários A principal responsabilidade do mecanismo de autenticação com base em comutação de usuários (uma biblioteca interna compartilhada) é criar uma Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 23

credencial que represente o usuário comutado, com base no nome do usuário e no método de autenticação fornecidos, sem exigir uma senha como entrada. Um mecanismo de autenticação CDAS personalizado dee atender ao mesmo requisito. Os mecanismos de autenticação com base em comutação de usuários são especificados na sub-rotina [authentication-mechanisms] do arquio de configuração pdwebpi.conf. Os mecanismos de autenticação a seguir são suportados: [authentication-mechanisms ] #su-password = su-password-library #su-token-card = su-token-card-library #su-certificate = su-certificate-library #su-http-request = su-http-request-library #su-cdsso = su-cdsso-library O Tioli Access Manager oferece uma única biblioteca de comutação de usuários que pode ser utilizada para atiar qualquer um dos mecanismos de autenticação acima em um ambiente padrão não personalizado. Essa biblioteca de comutação de usuários é diferente das bibliotecas de autenticação padrão. Ela especifica um mecanismo de autenticação que obtém a identidade do usuário (fornecida no formulário de comutação de usuários) e retorna uma credencial álida para esse usuário sem exigir a inserção da senha do usuário. A biblioteca interna compartilhada de comutação de usuários fornecida com o Tioli Access Manager é denominada: UNIX libsuauthn Windows suauthn A funcionalidade de comutação de usuários também suporta mecanismos de autenticação CDAS personalizados. Esse suporte é importante porque um CDAS personalizado freqüentemente fornece informações adicionais para a credencial do usuário. Você é responsáel por graar um CDAS personalizado de comutação de usuários que faça uma emulação do comportamento do CDAS existente e que, ao mesmo tempo, ofereça suporte para o requisito de retornar uma credencial sem exigir a inserção da senha do usuário. Cada biblioteca configurada de autenticação com base em comutação de usuários dee ter um nome exclusio, mesmo quando a biblioteca padrão (libsuauthn) é utilizada para mais de um método de autenticação. Exemplo: No exemplo a seguir (para uma plataforma Solaris), um ambiente existente possui três métodos de autenticação atiados: 1. Autenticação com base em formulários utilizando a biblioteca interna libldapauthn 2. Autenticação com base em certificados utilizando a biblioteca interna libsslauthn 3. Autenticação com base em token utilizando um mecanismo CDAS personalizado 24 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Agora, o ambiente é expandido para suportar a funcionalidade de comutação de usuários para qualquer um desses três métodos de autenticação. Três parâmetros de autenticação adicionais para a função Comutação de Usuários deem estar atiados no arquio de configuração pdwebpi.conf. Além disso, uma noa biblioteca CDAS personalizada dee ser graada de forma a emular o CDAS de tokens existente e suportar os requisitos da autenticação com base em comutação de usuários: [authentication-mechanisms ] passwd-ldap =/opt/policydirector/lib/libldapauthn.so cert-ssl =/opt/policydirector/lib/libsslauthn.so token-cdas =/opt/policydirector/lib/libcustom.so su-password =/opt/policydirector/lib/libsuformauthn.so su-certificate =/opt/policydirector/lib/libsucert.so su-token-card =/opt/policydirector/lib/libsucustom.so Causando Impactos sobre Outras Funcionalidades do Plug-in Impacto sobre a Configuração de Tempo Limite do Cache de Sessão A funcionalidade dos alores configurados de tempo limite de duração e de inatiidade do cache de sessão do plug-in não são afetados pela operação de comutação de usuários. Os temporizadores de duração e de inatiidade estão associados à entrada do cache de sessão do administrador e não aos dados de sessões que são alterados durante uma operação de comutação de usuários. O temporizador de inatiidade de sessões continua a ser zerado enquanto o administrador executa pedidos como o usuário comutado. Quando o administrador finalizar a sessão de comutação de usuários, a inatiidade ainda será álida para a sessão do administrador noamente estabelecida. O alor de duração da sessão não é estendido por uma operação de comutação de usuários. É possíel que o tempo limite de duração da sessão do administrador seja atingido durante uma operação de comutação de usuários. Se esse tempo limite for atingido, as sessões serão excluídas, efetuando o logout do administrador e do usuário comutado. O administrador deerá fazer uma noa autenticação e iniciar a operação de comutação de usuários mais uma ez. Incorporando Níeis de Autenticação Progressia A especificação de biblioteca compartilhada pode aceitar argumentos adicionais no formato: library&arg1 arg2... argx É possíel designar níeis de autenticação progressia utilizando a opção l e, em seguida, o número do níel. Por exemplo: su-password =/opt/policydirector/lib/libsuformauthn.so&-l 1 su-certificate =/opt/policydirector/lib/libsucert.so&-l 0 su-token-card =/opt/policydirector/lib/libsucustom.so&-l 2 Nota: Para esta ersão do Tioli Access Manager, o administrador dee conhecer a senha do usuário para executar com êxito a autenticação progressia. Suporte para Reautenticação A funcionalidade de reautenticação do plug-in é reconhecida pela operação de comutação de usuários. Se a reautenticação for necessária durante uma operação de comutação de usuários, o administrador deerá fazer a autenticação como o usuário comutado. Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 25

Nota: Para esta ersão do Tioli Access Manager, o administrador dee conhecer a senha do usuário comutado para fazer a reautenticação com êxito. Suporte para o Gerenciamento de Sessões do Usuário A operação de comutação de usuários suporta o gerenciamento de sessões do usuário. O administrador possui um ID de Sessão do Usuário exclusio. Além disso, durante uma operação de comutação de usuários, existe um ID de Sessão do Usuário exclusio para o usuário comutado. As tarefas finalizar sessão de um único usuário e finalizar todas as sessões de usuários operam como mostrado a seguir: a sessão do usuário comutado é finalizada quando o ID de sessão comutada ou o ID de sessão do usuário é especificado. tanto a sessão do administrador quanto a sessão do usuário comutado são finalizadas quando o ID de sessão do administrador ou o ID de sessão do usuário é especificado. Suporte para Tag-Value A capacidade de tag-alue, geralmente utilizada por um CDAS, é reconhecida e suportada pela funcionalidade de comutação de usuários. Fazendo a Auditoria do Administrador Durante a Comutação de Usuários É possíel auditar o administrador durante uma operação de comutação de usuários. A funcionalidade de comutação de usuários adiciona um atributo estendido à credencial do usuário comutado que identifica esse administrador. O atributo estendido, conforme armazenado na credencial, é denominado tag_alue_prefix_su-admin: tag_alue_prefix_su-admin = su-admin-name Em que tag_alue_prefix_ representa o alor do parâmetro tag_alue_prefix configurado na sub-rotina [pdwebpi-plugins] do arquio de configuração do plug-in. Esse atributo estendido está disponíel para qualquer mecanismo de auditoria. Configurando o Failoer para Seridores LDAP O Tioli Access Manager Plug-in para Web Serers conecta-se a qualquer seridor LDAP disponíel master ou réplica, dependendo da prioridade no momento que é inicializado. Se o seridor master LDAP for desatiado por qualquer motio, o plug-in deerá ter a capacidade de se conectar a um seridor réplica LDAP disponíel para todas as operações de leitura. Essa é a configuração padrão de réplicas LDAP do Tioli Access Manager. Para obter detalhes adicionais, consulte o documento IBM Tioli Access Manager Base: Guia do Administrador. O IBM Directory (LDAP) suporta a existência de um ou mais seridores réplica LDAP somente leitura. O Sun ONE (antigo iplanet) Directory Serer (LDAP) suporta a existência de um ou mais seridores réplica LDAP somente leitura, chamados de consumidores. É necessário adicionar linhas à sub-rotina [ldap] do arquio de configuração pdwebpi.conf de forma a identificar qualquer seridor réplica disponíel para o plug-in. Utilize a sintaxe a seguir para cada réplica: replica =ldap_serer,port,type,preference em que: ldap-serer O nome da rede do seridor réplica LDAP. 26 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

port type preference A porta na qual esse seridor atende. Geralmente, utilize 389 para comunicações não criptografadas ou 636 para comunicações por SSL. A funcionalidade do seridor réplica - ou read-only (somente leitura) ou read-write (leitura-graação). Normalmente, utilize read-only. Um tipo read-write representaria um seridor master. Um número entre 1 e 10. O seridor com o maior alor de preferência é escolhido para conexões LDAP. Consulte Definindo Valores de Preferências para Seridores Réplica LDAP no documento IBM Tioli Access Manager Base: Guia do Administrador. Exemplo: replica =replica1.ldap.tioli.com,389,readonly,5 replica =replica2.ldap.tioli.com,389,readonly,5 Suportando Cabeçalhos P3P (Platform for Priacy Preferences) O Projeto P3P (Platform for Priacy Preferences) é um padrão do World Wide Web Consortium que oferece uma forma de descreer uniformemente as preferências de priacidade do usuário e as informações sobre critérios de priacidade de seridores Web. Utilizando o P3P, um usuário pode configurar preferências de priacidade que determinam quais informações são diulgadas a um seridor Web e como essas informações são utilizadas. Com o P3P, um seridor Web pode especificar quais informações sobre critérios de priacidade dos usuários serão reunidas e para qual finalidade essas informações serão utilizadas. O critério de priacidade de um seridor Web é disponibilizado em um formato legíel para clientes e que pode ser lido por naegadores atiados para P3P e comparado com as próprias preferências de priacidade do usuário. O usuário é alertado quando o critério de priacidade do seridor Web e a sua configuração de priacidade não correspondem. Um uso comum para o P3P é permitir que os naegadores tomem decisões inteligentes sobre se deem ou não aceitar cookies recebidos de um seridor Web. O suporte para esse uso é atiado por padrão no Internet Explorer 6.0. Se o naegador Internet Explorer 6.0 receber um cookie de um site que não enia um critério P3P ou que enia um critério não correspondente às preferências de priacidade do usuário, ele poderá optar por bloquear automaticamente esse cookie. O plug-in depende de cookies para manter informações sobre sessões e também, por exemplo, para manter informações sobre failoer. O Internet Explorer, utilizando suas definições padrão, bloqueia cookies e, portanto, não armazenará os cookies do plug-in, o que limita efetiamente a funcionalidade do plug-in. O plug-in oferece opções de configuração P3P que especificam uma instrução de critério P3P compacto eniada com páginas quando um cookie do plug-in é definido. Essas opções de configuração P3P do plug-in permitem criar um critério P3P compacto que corresponde ao critério de priacidade de uma organização. Dessa forma, o cliente é responsáel por decidir se ele permitirá que os cookies do Tioli Access Manager sejam definidos. Nota: Você não dee configurar um critério P3P que não corresponda ao critério de priacidade da sua organização apenas para permitir que o Internet Explorer aceite cookies. Antes de atiar critérios P3P para cookies do plug-in, assegure-se de estar familiarizado com a especificação P3P e de compreender exatamente o que ocê está reiindicando como critério de priacidade da sua organização. Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 27

Configurando Cabeçalhos P3P O plug-in oferece parâmetros de configuração que correspondem à definição da sintaxe de critério compacto das recomendações do W3C para o P3P. Esses parâmetros deem ser configurados de forma a permitir os cookies do plug-in e, ao mesmo tempo, manter a integridade do critério de priacidade de uma organização. A primeira etapa da configuração de cabeçalhos P3P e definir o parâmetro send-p3p-header na sub-rotina [pdweb-plugins] do arquio de configuração pdwebpi.conf. Essa entrada pode ser definida para cada host irtual por meio da sua configuração em uma sub-rotina [irtual_host_name] definida pelo usuário. Definido como true, o parâmetro send-p3p-header especifica se o plug-in adicionará ou não um cabeçalho P3P contendo uma instrução de critério compacto a qualquer resposta HTTP na qual ele tenha definido cookies. O enio de um critério P3P é desatiado por padrão. Se ocê tier atiado o enio de cabeçalhos P3P, será necessário definir os parâmetros na sub-rotina [p3p-header] ou [p3p-header:irtual_host]. Esses parâmetros definem o critério compacto que se aplica a todos os cookies HTTP definidos. As definições padrão nessa sub-rotina permitem que cookies de sessão sejam armazenados em um naegador Internet Explorer 6 mesmo que apareçam como cookies de terceiros. Tabela 6. Parâmetros [p3p-header] Parâmetro p3p-element Uso Esse parâmetro pode ser utilizado para especificar uma referência a um critério XML completo além do critério compacto configurado com o uso de outros parâmetros nessa sub-rotina. access disputes Desfazer o comentário da linha p3p-element = policyref="/w3c/p3p.xml", direciona o naegador para eniar a referência especificada ao critério XML completo. Nota: Uma ACL que permite acesso não autenticado dee ser definida no diretório /w3c de forma a permitir o acesso ao critério. Isso é necessário porque o Internet Explorer não enia com o pedido informações sobre autenticação que permitem a isualização do critério. Especifica o acesso do usuário às informações contidas e inculadas pelo cookie. Valores possíeis: none all nonident contact-and-other ident-contact other-ident Especifica se o critério P3P completo contém ou não algumas informações relacionadas a disputas sobre as informações contidas no cookie. Os alores álidos são true ou false. Esse parâmetro é definido como false por padrão. 28 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 6. Parâmetros [p3p-header] (continuação) Parâmetro remedies Uso Especifica as possíeis soluções para disputas. Os alores possíeis são: correct money law non-identifiable purpose Se não for especificado, nenhuma informação sobre soluções será incluída no critério. Quando definido como true, esse parâmetro especifica que nenhuma informação no cookie, ou que nenhuma informação inculada pelo cookie, identifica pessoalmente o usuário de nenhuma maneira. Os alores álidos são true ou false. Esse parâmetro é definido como false por padrão. Especifica a finalidade das informações no cookie e inculadas pelo cookie. Os alores possíeis são: current admin deelop tailoring pseudo-analysis pseudo-decision indiidual-analysis indiidual-decision contact historical telemarketing e other-purpose. Para todos os alores, com exceção de current, um especificador adicional pode ser configurado. Os alores possíeis são: always opt-in opt-out. recipient retention Para finalidades não especificadas, o alor padrão é always. Esse alor é especificado após a finalidade, separado por um caractere de dois pontos, por exemplo: purpose = contact:opt-in Especifica os destinatários das informações no cookie e das informações inculadas pelo cookie. Os alores possíeis são: ours deliery same unrelated public other-recipient. Especifica por quanto tempo as informações no cookie ou as informações inculadas pelo cookie deem ser mantidas. Os alores possíeis são: no-retention stated-purpose legal-requirement business-practices indefinitely. Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 29

Tabela 6. Parâmetros [p3p-header] (continuação) Parâmetro categories Uso Especifica os tipos de informações armazenadas no cookie ou inculadas pelo cookie. Se o parâmetro non-identifiable for definido como true, nenhuma categoria precisará ser configurada. Os alores possíeis são: physical online uniqueid purchase financial computer naigation interactie demographic content state political health preference location goernment other-category Exemplo de configuração P3P: [pdweb-plugins] or [irtual_host_name] send-p3p-header = true... [p3p-header] or [p3p-header:irtual_host_name] # p3p-element = policyref="/w3c/p3p.xml" access = none disputes = false non-identifiable = false purpose = current purpose = other-purpose:opt-in recipient = ours retention = no-retention categories = uniqueid Configurando a Auditoria, o Registro, o Rastreio e o Banco de Dados de Cache do Plug-in Os recursos de registro e auditoria podem fornecer informações que ajudarão a identificar qualquer problema que possa ocorrer com o plug-in. Se ocê achar que existem problemas e precisar de uma isualização em tempo real das mensagens de erro, inicie o plug-in no primeiro plano utilizando a opção -foreground: pdwebpi -foreground Nota: Para instalações no IIS, inicie noamente o IIS antes de iniciar o plug-in no modo em primeiro plano para liberar qualquer memória compartilhada existente. Mensagens de erro e de status são registradas no arquio configurado nos parâmetros log-file, logs e log-entries da sub-rotina [pdweb-plugins] do arquio de configuração pdwebpi.conf. 30 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

A configuração do banco de dados de cache básico e da auditoria do plug-in é executada com o uso dos parâmetros na sub-rotina [aznapi-configuration] do arquio de configuração pdwebpi.conf. Registros de Auditoria Os seriços básicos da API de autorização possibilitam a captura de eentos de auditoria de autenticação (authn) e de autorização (azn). Entretanto, os eentos de auditoria authn padrão não fazem o encapsulamento de informações suficientes sobre uma tentatia de autenticação no sentido de permitir a correlação desses eentos com um host irtual específico, no qual um plug-in esteja protegendo mais de um único host. Por esse motio, o plug-in implementa sua própria categoria de eentos de auditoria para capturar informações de autenticação específicas para cada host irtual. Os eentos de auditoria azn padrão capturam informações releantes de hosts irtuais do plug-in, pois o nome do objeto protegido é construído com o prefixo /PDWebPI/irtual_host_name. Os eentos de auditoria de autenticação específicos do plug-in são registrados em conjuntos de eentos de auditoria específicos para cada host irtual. Esses conjuntos são construídos da seguinte maneira: wpi.irtual_host_name.authn.authentication_module_name Os eentos de auditoria de autenticação específicos do plug-in estão em conformidade com a definição DTD descrita no documento IBM Tioli Access Manager Base: Guia do Administrador. Os elementos dos registros de auditoria wpi em estilo XML estão descritos na tabela a seguir. Tabela 7. Definições de Campos de Registros de Auditoria de Autenticação. <eent> <date> <outcome> <originator> Marcação XML <component> Descrição Faz o encapsulamento da marcação para o registro de auditoria. O elemento inclui um atributo que descree a reisão da definição de tipo de documento do registro. Registro da data e da hora de ocorrência do eento. O elemento de marcação inclui um parâmetro status, que identifica o código de erro do Tioli Access Manager ou do plug-in. O elemento descree o resultado geral do eento. Os alores possíeis são: 0 = Success 1 = Failure 2 = Pending 3 = Unknown Marcação de cabeçalho para a seção iniciadora do registro de auditoria. O elemento da marcação inclui o parâmetro blade, que identifica o blade do Tioli Access Manager responsáel pelo eento. A marcação identifica o componente que capturou o registro de auditoria. Esse componente é registrado no formato: wpi.irtual_host_name.type_of_eent.module_name Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 31

Tabela 7. Definições de Campos de Registros de Auditoria de Autenticação. (continuação) <action> Marcação XML Descrição Identifica o método de autenticação tentado. Os códigos de ação e seus mecanismos de autenticação correspondentes são: 16961 - BA 17236 - Client side certificate 17731 - Ecsso 17999 - Failoer cookie 17997 - Forms 18504 - Http Header 18768 - IP address 4806211 - IV header: PAC credential 4806229 - IV header:username 4806220 - IV header:distinguished name 300609 - IV header:ip address 21579 - Token <location> <accessor> <principal> <target> <object> <data> Define o nome do seridor que iniciou o eento. Marcação de cabeçalho para a seção acessor do registro de auditoria. O elemento da marcação pode incluir o nome do acessor. A marcação principal inclui o parâmetro auth, que identifica o seriço de diretório que está fazendo a autenticação. Essa marcação define o nome do usuário alidado. A marcação target inclui o parâmetro resource, que pode consistir em um d os alores a seguir: 0 = authorization 1 = process 2 = TCB 3 = credential 4 = general Os registros de auditoria de autenticação sempre definem esse alor para como 3 - credential. Contém dados de auditoria que possuem pouco significado para o processo de autenticação. Informações extras sobre falhas de autenticação. Por exemplo, uma falha durante uma tentatia de autenticação com o uso das informações de um cabeçalho HTTP fará com que um registro de log de auditoria recorde nesse campo o cabeçalho HTTP com falha. Configuração de Auditoria A tabela a seguir exibe os parâmetros de configuração de auditoria e explica suas funções. Tabela 8. Definições de Parâmetros de Configuração de Auditoria logsize Parâmetro Descrição O tamanho (em bytes) no qual os arquios de log são transferidos para um noo arquio. Se definido como 0, os arquios de log não serão transferidos. Um número negatio transferirá os logs diariamente, independentemente do tamanho. 32 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 8. Definições de Parâmetros de Configuração de Auditoria (continuação) logflush logaudit auditlog auditcfg Parâmetro Descrição O interalo, em segundos, no qual os logs são descarregados. O alor máximo é 6 horas e o alor padrão é 20 segundos. Atia ou desatia a auditoria. Especifica o nome do arquio de auditoria. Atia ou desatia a auditoria de autorização e/ou de autenticação. Por exemplo: [aznapi-configuration] logsize = 2000000 logflush = 20 logaudit = no auditlog = audit.log auditcfg = azn #auditcfg = authn auditcfg = wpi Rastreando Ações do Plug-in O Tioli Access Manager Plug-in para Web Serers oferece a capacidade de rastrear ações e de armazenar os resultados em um arquio para finalidades de depuração. Essencialmente, o rastreio é uma ferramenta de análise e de diagnóstico de problemas utilizada pelo suporte de aplicatios para obter uma exibição completa das ações que estão causando erros. Na condição de usuário, ocê pode considerar úteis alguns dos recursos de rastreio do plug-in, embora a maioria desses recursos apenas proporcione grandes benefícios em casos de diagnósticos de problemas complexos. É possíel rastrear as mensagens HTTP no plug-in. Esse rastreio pode ser muito útil, pois mostra exatamente o que é recebido do usuário e o que é retornado a esse usuário, mesmo que a comunicação ocorra por HTTPS. O rastreio é atiado e desatiado com o uso dos comandos de rastreio padrão pdadmin. As entradas e os resultados de decisões de autorização podem ser rastreados de forma a facilitar o diagnóstico de problemas de configuração de critérios de autorização. Esse rastreio mostra informações de credenciais de usuários, incluindo nomes, UUIDs, IDs de sessão e atributos. Além disso, também mostra o nome do objeto protegido do Tioli Access Manager, que está sendo utilizado para tomar a decisão, e as permissões necessárias. O resultado da decisão também é mostrado com todos os atributos de decisão retornados. Comandos de Rastreio pdadmin Listando Componentes de Rastreio: O comando list gera uma lista de todas as ações do plug-in que podem ser rastreadas. Sintaxe: pdadmin> serer task PDWebPI-serer-name trace list [component] A maioria das tarefas de rastreio listadas é específica para o Tioli Access Manager. Os itens de rastreio específicos para o plug-in são prefixados com pdwebpi. Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 33

Definindo Componentes de Rastreio: que podem ser úteis para depuração: pdwebpi.request pdwebpi.plugin pdwebpi.azn Existem três itens de rastreio principais Quando o componente pdwebpi.request é definido como two, o rastreio ocorre em cada pedido que passa pelo plug-in. Quando o componente pdwebpi.request é definido como nine, o cabeçalho do pedido é incluído no rastreio. O componente pdwebpi.plugin atia o rastreio no seridor do plug-in. Todas as mensagens são eniadas ao arquio de log do seridor Web ou, no caso do IIS, a um log diferente do utilizado para o Authorization Serer. Definido como one, o componente pdwebpi.azn rastreia informações resumidas sobre cada decisão de autorização, incluindo o nome do objeto protegido, a cadeia de permissão, o nome do usuário, o ID da sessão, o método HTTP, o URI do HTTP e o resultado da decisão. Quando o componente pdwebpi.azn é definido como two, o rastreio ocorre para informações adicionais de atributos de credenciais e também para atributos de decisão de entrada e de saída. Quando o componente pdwebpi.azn é definido como fie, são incluídas informações adicionais sobre o processamento progressio e de reautenticação. O comando de rastreio set possui a seguinte sintaxe: pdadmin> serer task PDWebPI-serer-name trace set component leel [file path=file other-log-agent-config] Em que component corresponde ao nome do componente de rastreio, conforme mostrado pelo comando list. Um rastreio é definido para esse componente. leel corresponde à quantidade de detalhes reunidos para o rastreio. A faixa aria entre 1 e 9, sendo que 1 corresponde ao níel menos detalhado e 9 corresponde ao níel mais detalhado. O parâmetro opcional file path especifica a localização da saída de rastreio. Por padrão, a saída de rastreio é eniada ao arquio de log padrão configurado do plug-in (exceto com o uso do componente pdwebpi.plugin). Para instalações no IIS, o nome do arquio para o qual o rastreio de componentes do plug-in é eniado sempre é configurado com o uso do parâmetro log-file, na sub-rotina [iis] do arquio de configuração. A saída pode ser exibida na tela com o uso da opção -foreground. Ou seja: pdwebpi -foreground Mostrando Componentes de Rastreio: Para mostrar componentes de rastreio, utilize o comando show no seguinte formato: pdadmin> serer task PDWebPI-serer-name trace show [component] Definições do Banco de Dados de Cache É possíel configurar o plug-in para colocar regularmente em pool o banco de dados de autorização master para obter informações de atualização. O parâmetro cache-refresh-interal pode ser definido como default, como disable ou como um interalo de tempo específico em segundos. A definição padrão é disable. [aznapi-configuration] cache-refresh-interal = 60 O parâmetro db-file define o caminho completo para o banco de dados de cache de ACLs. Por padrão, esse parâmetro não é definido. 34 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

[aznapi-configuration] db-file = /ar/pdwebpi/db/pdwebpi.db O parâmetro listen-flags atia ou desatia a recepção de notificações sobre atualizações do cache de critérios. Um alor disable desatia o atendente das notificações. Esse parâmetro é definido pelo utilitário srsslcfg. [aznapi-configuration] listen-flags = disable Configurando o Seriço da API de Autorização A sub-rotina [aznapi-entitlement-serices] do arquio de configuração pdwebpi.conf atribui IDs de seriço a seriços. Cada entrada da sub-rotina define tipos diferentes do seriço aznapi. Para obter informações adicionais, consulte o documento IBM Tioli Access Manager Administration C API Deeloper s Reference. Cada entrada está no formato: Atualização de Credenciais serice_id = path_to_dll [ & params... ] Os IDs de Seriço são utilizados pelo cliente aznapi para identificar os seriços. É possíel especificar parâmetros a serem transmitidos ao seriço quando ele for inicializado pelo aznapi. Os parâmetros acompanham o símbolo & na entrada. As informações reunidas no momento da autenticação do usuário são armazenadas em cache na credencial durante a permanência na sessão consulte Aquisição de Credenciais na página 5 para obter detalhes adicionais sobre credenciais de usuário do plug-in. A menos que sejam configuradas para a atualização de credenciais, as alterações feitas na origem das informações de credenciais do usuário, como a inclusão ou a remoção do usuário em um grupo, não serão refletidas na sessão desse usuário até que uma noa sessão de usuário seja criada. Estas são algumas das utilidades da atualização de credenciais: É possíel atualizar a credencial de um usuário sem exigir que ele efetue logout e, em seguida, efetue login em um aplicatio. Isso aprimora a experiência do usuário. Fornece a um administrador a capacidade de fornecer acesso adicional a objetos da Web protegidos para um usuário durante sua sessão atual. Aprimora a segurança permitindo que um administrador restrinja as permissões de acesso de um usuário durante uma sessão atual se esse administrador tier motios para acreditar que o usuário não esteja se comportando de maneira adequada. Configurando a Atualização de Credenciais A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a funcionalidade de atualização de credenciais, o módulo cred-refresh precisa ser configurado como um módulo de pré-autorização. [common-modules]... pre-authzn = cred-refresh... Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 35

Assegure-se de que a entrada para a atualização de credenciais esteja presente na sub-rotina [modules] do arquio de configuração pdwebpi.conf, ou seja: [modules]... cred-refresh = pdwpi-cred-refresh-module... Durante a atualização de credenciais, ocê pode julgar necessário preserar algumas informações sobre o usuário contidas na credencial original. Por exemplo, um atributo personalizado pode registrar o tempo de login do usuário, que poderá ser útil manter inalterado quando a credencial for atualizada. O plug-in permite configurar atributos a serem mantidos quando uma atualização for executada. Eles são configurados com base no nome do atributo. A sub-rotina [cred-refresh] ou [cred-refresh:irtual-host] especifica os atributos que deerão ser preserados a partir da credencial original e os atributos que deerão ser atualizados na noa credencial quando ocorrer uma operação de atualização de credenciais. Os alores são especificados no formato presere = attribute_pattern para os atributos a serem preserados a partir do original. Os alores a serem atualizados são especificados no formato refresh = attribute_pattern. As regras de correspondência de padrões do plug-in aplicam-se aos padrões de atributos, com a exceção de que as comparações entre caracteres não fazem distinção entre maiúsculas e minúsculas. Consulte o Apêndice E, Caracteres Especiais Permitidos em Expressões Comuns, na página 235 para obter informações adicionais sobre as regras de correspondência permitidas. As regras a seguir aplicam-se à lista de atributos: As regras que aparecem em primeiro lugar na sub-rotina têm precedência sobre as regras que aparecem por último. As regras que não correspondem a nenhum atributo são atualizadas por padrão. Alguns atributos sempre são preserados, independentemente de como a sub-rotina [cred-refresh] está configurado. Esses atributos são: AZN_CRED_AUTHNMECH_INFO, AZN_CRED_BROWSER_INFO, AZN_CRED_IP_ADDRESS, AZN_CRED_PRINCIPAL_NAME AZN_CRED_QOP_INFO Os atributos marcados pelo aznapi como somente leitura sempre são preserados, independentemente do conteúdo da sub-rotina [cred-refresh]. Se um atributo não estier presente na credencial original, ele não será preserado, independentemente da configuração dessa sub-rotina. Nota: Uma credencial apenas é atualizada a partir do registro quando ela não existe na cache de credenciais. Após a configuração da funcionalidade de atualização de credenciais, será possíel usar o utilitário de linha de comandos pdadmin para atualizar a credencial de um usuário específico. O exemplo a seguir mostra os comandos para adicionar um usuário a um noo grupo e para atualizar sua credencial durante o logon, fornecendo efetiamente a esse usuário as permissões de acesso do noo grupo. pdadmin> group modify group_name add user_name pdadmin> serer task serer_name refresh all_sessions user_name 36 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Nota: Em plataformas UNIX, a reinicialização do plug-in não é necessária depois de ajustar a configuração da atualização de credenciais. No Windows, como ocorre com todas as alterações feitas no componente pdwebpi.conf, a reinicialização do plug-in é necessária para que as alterações na configuração da atualização de credenciais sejam efetiadas. Configurando o Armazenamento em Cache de Pedidos HTTP O plug-in armazenará em cache os dados de pedidos e utilizará esses dados em cache para reconstruir um pedido durante um redirecionamento HTTP se uma exigência de reautenticação interromper a conclusão do processamento desse pedido. Essa funcionalidade gera benefícios para pedidos POST e PUT, pois esses tipos de pedidos podem incluir uma ariedade de campos de informações. Quando uma exigência de autenticação interrompe um pedido, o plug-in armazena em cache todas as informações necessárias para reconstruir esse pedido durante o redirecionamento HTTP que ocorre após a reautenticação. Os dados de pedidos em cache incluem URL, METHOD, Corpo da Mensagem, cadeias de consulta e todos os cabeçalhos HTTP (incluindo cookies). Esses dados são temporariamente armazenados no cache de credenciais/sessões do plug-in. Após a autenticação (ou reautenticação) bem-sucedida, o plug-in enia um redirecionamento HTTP ao naegador. O naegador segue o redirecionamento até o URL original contido nesse redirecionamento. O plug-in intercepta o redirecionamento e reconstrói o pedido utilizando os dados em cache. O pedido reconstruído é entregue ao destino de URL. Configurando Parâmetros de Armazenamento em Cache no Lado do Seridor O parâmetro max-cached-http-body na sub-rotina [pdweb-plugins] do arquio de configuração especifica a quantidade máxima de dados do corpo HTTP que são armazenados em cache para qualquer pedido determinado. Quando a quantidade de dados do corpo excede o máximo configurado, todos esses dados são descartados. O parâmetro worker-size na sub-rotina [proxy-if] controla a quantidade de memória alocada para qualquer pedido determinado. O tamanho de max-cached-http-body, em um alor mínimo, dee estar em conformidade com o seguinte algoritmo: max-cached-http-body * 4/3 * 2 + 3000 <= worker-size # # Esse algoritmo assume que 3000 bytes consistam em uma memória suficiente para conter o pedido, excluindo todos os dados POST, e o formulário retornado, excluindo os dados POST em cache. Se houer possibilidades de que o tamanho do pedido, incluindo o tamanho do formulário retornado, exceda 3000 bytes, coném aumentar a entrada worker-size ou diminuir o alor de max-cached-http-body. Suporte a Idiomas e Conjuntos de Caracteres O Tioli Access Manager Plug-in para Web Serers pode exibir páginas HTML geradas pelo Tioli Access Manager no idioma preferencial do usuário. O idioma utilizado para exibição nas páginas HTML é obtido a partir do cabeçalho padrão Accept-Language localizado no pedido HTTP. Os alores de idiomas são Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 37

representados por dois caracteres. Os alores específicos para cada localização são expressos em um formato de duas partes, indicando o idioma e o país no qual essa ersão do idioma é utilizada. Alguns exemplos incluem: es (espanhol) de (alemão) en (inglês) it (italiano) en-us (inglês/estados Unidos) en-gr (inglês/reino Unido) es-es (espanhol/espanha) es-mx (espanhol/méxico) pt-br (português/brasil) Se o plug-in não encontrar um código de idioma apropriado no pedido HTTP, tentará noamente a lista de idiomas sem o dialeto de qualificação (por exemplo, es-mx será tentado noamente como es). Se um idioma apropriado ainda não for encontrado, o seridor utilizará o idioma inglês. Apenas as páginas geradas pelo Tioli Access Manager, contidas em install_path/nls/html/lang/charset, são apresentadas em ários idiomas. Alguns exemplos dessas páginas incluem todos os formulários de autenticação do Tioli Access Manager e as páginas de gerenciamento de contas do Tioli Access Manager. Os idiomas especificados no campo Accept Language do cabeçalho HTTP são diretamente mapeados para os diretórios localizados no diretório install_path/nls/html. Copiando os diretórios de idiomas, um seridor pode ser modificado de forma a atender às exigências das ariações de especificadores de idioma. Para modificar um seridor, os diretórios de idiomas reais que deem ser copiados são: am base install directory/nls/msg/lang am webpi install directory/nls/html/lang/charset am webpi install directory/nls/msg/lang/charset A tabela a seguir lista os idiomas suportados pelo plug-in, com o nome do subdiretório associado: Tabela 9. Idiomas Suportados pelo Plug-in com o Diretório Suportado. Idioma Inglês (padrão) Tcheco Alemão Espanhol Francês Húngaro Italiano Japonês Coreano Polonês Português, Brasil Diretório do Sistema b cs de es fr hu it ja ko pl pt_br 38 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 9. Idiomas Suportados pelo Plug-in com o Diretório Suportado. (continuação) Idioma Diretório do Sistema Russo ru Chinês, China zh_cn Chinês, Taiwan zh_tw Até dez especificações de idioma no campo Accept Language do cabeçalho HTTP são reconhecidas. Diferentes conjuntos de caracteres para um determinado idioma estão localizados em um diretório abaixo do diretório de suporte a idiomas. O diretório de conjunto de caracteres utilizado é selecionado com base no alor do cabeçalho accept-charset recebido do cliente. Se nenhuma correspondência for encontrada (ou se o cabeçalho não estier definido), o diretório utf-8 será utilizado. É possíel atiar e desatiar o suporte para diferentes idiomas e conjuntos de caracteres com base nos cabeçalhos accept-language e accept-charset. As definições padrão para esses parâmetros são configuradas na sub-rotina [pdweb-plugins], mas poderão ser substituídas para cada host irtual se forem definidas em uma sub-rotina com o nome do ID do host irtual. [pdweb-plugins] or [irtual-host]... use-accept-langauge-header = true... use-accept-charset-header = false Por padrão, o uso do cabeçalho accept-charset é desatiado. O parâmetro use-accept-language-header atia ou desatia o uso do cabeçalho HTTP accept-language durante a tentatia de localizar o idioma para a resposta HTML gerada. O parâmetro use-accept-charset-header atia ou desatia o uso do cabeçalho HTTP accept-charset durante a tentatia de localizar o conjunto de caracteres no qual descodificar elementos de um pedido HTTP ou de gerar uma resposta HTML. O alor padrão (se não for encontrado nesse arquio de configuração) é false. O cabeçalho user-agent pode ser utilizado como uma alternatia para os cabeçalhos accept-language e accept-charset no sentido de selecionar um idioma e um conjunto de caracteres. O cabeçalho user-agent contém informações específicas para cada dispositio que podem ser utilizadas para fornecer informações sobre idiomas e caracteres quando os requisitos de um dispositio são conhecidos. O cabeçalho user-agent apenas será utilizando quando os cabeçalhos accept-language e accept-charset, ou um deles, não forem encontrados ou se o uso desses cabeçalhos estier desatiado. O mapeamento padrão a partir de user-agent para o idioma e o conjunto de caracteres é configurado na sub-rotina [user-agent] e pode ser substituído para cada host irtual. A sub-rotina inclui uma lista de padrões que são correspondidos, na ordem especificada, ao conteúdo do cabeçalho user-agent. Para conhecer uma lista de caracteres coringa disponíeis, consulte o Apêndice E, Caracteres Especiais Permitidos em Expressões Comuns, na página 235. Se uma correspondência for encontrada, o respectio diretório para o idioma e o conjunto de caracteres será utilizado. Além de especificar um idioma e um conjunto de caracteres para um Capítulo 2. Configuração do IBM Tioli Access Manager Plug-in para Web Serers 39

determinado padrão de user-agent, também é possíel especificar um diretório. Nesse caso, o nome do diretório especificado é utilizado no lugar do nome do diretório do conjunto de caracteres durante o enio de páginas do Tioli Access Manager. Esse diretório dee estar localizado abaixo do diretório de idioma especificado. 40 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers Este capítulo discute como o IBM Tioli Access Manager (Tioli Access Manager) Plug-in para Web Serers mantém o estado de sessões, trata o processo de autenticação e executa qualquer processamento pós-autorização necessário em sessões autorizadas. Este capítulo inclui os seguintes tópicos: O Processo de Tratamento de Pedidos Configurando a Autenticação na página 43 Gerenciando o Estado de Sessões na página 52 Visão Geral da Configuração de Autenticação na página 59 Configurando a Autenticação Básica na página 62 Configurando a Autenticação com Base em Formulários na página 66 Configurando a Autenticação com Base em Certificados na página 68 Configurando a Autenticação com Base em Token na página 70 Configurando a Autenticação SPNEGO na página 74 Configurando a Autenticação NTLM (Somente para Plataformas IIS) na página 82 Configurando a Autenticação com Base em Seridor Web (Somente para Plataformas IIS) na página 83 Configurando a Autenticação com Base em Failoer na página 84 Configurando a Autenticação com Base em Cabeçalhos IV na página 100 Configurando a Autenticação com Base em Cabeçalhos HTTP na página 103 Configurando a Autenticação com Base em Endereços IP na página 104 Configurando a Autenticação LTPA na página 106 Configurando o Redirecionamento de Usuários Após o Logon na página 106 Adicionando Atributos Estendidos para Credenciais na página 107 Adicionando Atributos Estendidos LDAP ao Cabeçalho HTTP (Valor de Marcação) na página 111 Oferecendo Suporte para MPAs (Agentes Proxy de Multiplexação) na página 112 O Processo de Tratamento de Pedidos O Tioli Access Manager Plug-in para Web Serers processa cada pedido da Web que chega ao seridor Web. O processo de tratamento de pedidos consiste em oito etapas: 1. Identificação do host irtual A primeira etapa do processamento de pedidos é a identificação do host irtual ao qual o pedido está destinado. A identificação de hosts irtuais é discutida em Configurando para Seridores Host Virtuais na página 13. 2. Identificação da sessão Após a determinação do host irtual, o pedido é examinado para erificar a existência de informações de sessões autenticadas. Essas informações podem Copyright IBM Corp. 2000, 2003 41

corresponder a um cookie de sessão ou a um ID de sessão SSL. As informações utilizadas para identificar a sessão são determinadas pelos módulos de sessão configurados. A seção Gerenciando o Estado de Sessões na página 52 discute cada um dos módulos de sessão disponíeis. 3. Autenticação Se nenhuma sessão existente for identificada, o pedido será examinado para erificar a existência de informações de autenticação. Essas informações podem consistir em um nome de usuário e uma senha de Autenticação Básica, uma submissão para um formulário de login ou um certificado de cliente. As informações utilizadas para autenticar o cliente são determinadas pelos módulos de autenticação configurados. A seção O Processo de Autenticação na página 43 discute cada um dos módulos de autenticação disponíeis. Se houer informações de autenticação álidas no pedido, uma noa sessão de usuário autenticada será criada. Se não houer informações de autenticação, o pedido será tratado como não autenticado. Se houer informações de autenticação inálidas no pedido e o método de autenticação oferecer suporte para uma noa entrada (por exemplo, Autenticação Básica) de informações de autenticação, o usuário será solicitado a fornecer noamente sua autenticação. Se o método de autenticação não oferecer suporte para uma noa entrada (por exemplo, certificado de cliente), um erro será retornado ao cliente. 4. Pré-autorização Em alguns casos, o processamento inicial de pedidos pode ser exigido antes que o acesso a um recurso solicitado seja autorizado. Esse processamento é executado por qualquer módulo de pré-autorização configurado. Os módulos de pré-autorização fornecem funções que não requerem autorização ou fornecem suporte para capacidades que requerem acesso ao pedido antes da decisão de autorização. 5. Autorização Durante a autorização, o critério do Tioli Access Manager é consultado com o uso das informações de credenciais associadas à sessão de forma a determinar se o acesso dee ou não ser concedido ao recurso solicitado e, em caso positio, sob quais condições. Os critérios que podem ser especificados para controlar o acesso a recursos estão definidos no Capítulo 4, Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers, na página 117. 6. Upgrade de autenticação Em casos nos quais o níel de autenticação do usuário não é apropriado para acessar um recurso solicitado ou nos quais um pedido não está autenticado, esse pedido é noamente examinado para erificar a existência de informações de autenticação que autenticariam o usuário no níel de autenticação necessário. Se essas informações não estierem presentes, e um módulo de autenticação com suporte para a capacidade de solicitar ao usuário a especificação de informações no níel de autenticação necessário estier configurado, esse usuário será solicitado a especificar essas informações. Se não houer uma forma de fazer o upgrade da sessão de usuário autenticada até um níel suficiente para acessar o recurso, o acesso será negado. 7. Pós-autorização Em algumas situações, após a tomada da decisão de autorização, um determinado processamento pode ser necessário para: modificar o pedido da Web antes que ele seja tratado pelo seridor Web, por exemplo, inserir um cabeçalho; modificar a resposta da Web gerada pelo seridor Web, por exemplo, definir um cookie; 42 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

O Processo de Autenticação Configurando a Autenticação gerar uma resposta completa sem que o seridor Web trate o pedido, por exemplo, redirecionar o usuário a uma página específica após um logon bem-sucedido. Essas operações ocorrem depois que o resultado do processo de autorização é conhecido, pois a decisão pode afetar o modo como o pedido dee ser tratado. Essas capacidades são fornecidas por módulos de pós-autorização. 8. Tratamento de respostas Funções como a FSSO (Conexão Única por Formulários) e o processamento EAI (Interface de Autenticação Externa) requerem que a resposta gerada pelo seridor Web seja processada pelo plug-in em ez de ser eniada ao cliente. Geralmente, com o tratamento de respostas, o plug-in processa respostas a partir do seridor Web antes de transmitir uma resposta alternatia ao usuário. Os módulos que exigem essa capacidade são chamados de módulos de resposta. Autenticação é o método de identificar uma entidade ou um processo indiidual que está tentando efetuar logon em um domínio protegido. A autenticação bem-sucedida resulta em uma identidade do Tioli Access Manager que representa o usuário. O plug-in utiliza essa identidade para obter credenciais para esse usuário. Credenciais são utilizadas pelo Authorization Serer para permitir ou negar o acesso a recursos protegidos após a aaliação das permissões de ACLs, das condições POP e das regras de autorização que goernam o critério para cada recurso. Nota: ACL = lista de controle de acesso POP = critério de objetos protegidos Por padrão, o Tioli Access Manager Plug-in para Web Serers suporta ários métodos de autenticação e pode ser personalizado para utilizar outros métodos. Todos os métodos de autenticação disponíeis, com seus nomes associados de bibliotecas compartilhadas, são definidos na sub-rotina [modules] do arquio de configuração pdwebpi.conf. A sub-rotina [modules] também lista os módulos utilizados para a identificação de sessões e para o tratamento pós-autorização. Esses módulos serão descritos posteriormente. As bibliotecas compartilhadas deem existir no diretório pdwebpi/lib. Os nomes de bibliotecas compartilhadas são especificados sem nenhum prefixo específico para um sistema operacional (como lib) e sem nenhum sufixo específico para um sistema operacional (como dll). Por exemplo: BA = pdwpi-ba-module No exemplo anterior, a biblioteca do módulo BA é determinada como pdwpi-ba-module. No Windows, o plug-in procurará um arquio denominado pdwpi-ba-module.dll, no Solaris, um arquio denominado libpdwpi-ba-module.so e, no AIX, um arquio denominado libpdwpi-ba-module.a. Nota: Uma alternatia para o caminho de pesquisa padrão dos arquios de biblioteca pode ser definida na sub-rotina [module-mgr]. Cada rótulo definido na sub-rotina [modules] possui uma própria sub-rotina correspondente; por exemplo, [BA], [cert] e [token]. Informações de configuração específicas para cada método de autenticação são determinadas nessas sub-rotinas Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 43

e aplicam-se a esse método de autenticação, independentemente do host irtual a partir do qual ele é chamado. Se uma configuração especial for necessária para cada host irtual, a configuração padrão poderá ser substituída com o uso de uma sub-rotina que qualifique o rótulo do módulo com um rótulo de host irtual. Por exemplo: [BA] basic-auth-realm = "Access Manager" [BA:ibm.com] basic-auth-realm = "ibm.com" No exemplo anterior, os usuários que estierem acessando o host irtual ibm.com com o uso da Autenticação Básica estarão sujeitos aos parâmetros de configuração especificados na sub-rotina [BA:ibm.com]. Uma configuração padrão de módulos permite que apenas uma instância de uma biblioteca de módulo seja especificada para um determinado método de autenticação, por exemplo: [modules] BA = pdwpi-ba-module Algumas instalações podem exigir que árias instâncias de uma biblioteca de autenticação sejam especificadas. Isso pode ser feito quando comportamentos diferentes de um módulo são necessários para níeis de autenticação distintos. O exemplo a seguir mostra a configuração para duas instâncias do módulo de autenticação com base em formulários. [modules] BA = pdwpi-ba-module forms-authn-leel1 = pdwpi-forms-module forms-authn-leel2 = pdwpi-forms-module [common-modules] authentication = forms-authn-leel1 authentication = forms-authn-leel2 authentication = BA [forms-authn-leel1] login-form = leel1-form [forms-authn-leel2] login-form = leel2-form [BA]... A última etapa da configuração de métodos de autenticação é especificar esses métodos de autenticação. Eles são definidos na sub-rotina [common-modules] do arquio de configuração, seguindo uma ordem de preferência. Por exemplo: [common-modules] session = ssl-id session = BA session = session-cookie authentication = cert authentication = BA post-authzn = ltpa No exemplo anterior, as definições de configuração asseguram que: 44 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

IDs de sessão SSL sejam utilizados para manter informações de sessões como primeira opção. Cabeçalhos BA (se disponíeis) sejam utilizados para manter informações de sessões quando não houer um ID de sessão SSL disponíel. Cookies de sessão sejam utilizados como último recurso para manter informações de sessões quando não houer IDs de sessão SSL ou cabeçalhos BA disponíeis. Certificados sejam utilizados como o método de autenticação como primeira opção. BA seja utilizado para autenticação quando não houer um certificado disponíel. Cookies LTPA deam ser adicionados ao pedido como parte do processamento pós-autorização. Configurando a Autenticação para Hosts Virtuais A configuração de métodos de autenticação pode ser realizada para cada host irtual por meio da especificação direta desses métodos na sub-rotina de cada host irtual. Por exemplo: [pdweb-plugins] irtual-host = ibm.com [ibm.com]... session = ssl-id session = BA session = session-cookie authentication = cert authentication = BA post-authzn = ltpa Uma forma alternatia de especificar os métodos de autenticação para hosts irtuais é definir uma sub-rotina para a configuração desses métodos de autenticação. Isso permite que ários hosts irtuais compartilhem uma configuração de módulos. A sub-rotina de configuração de módulos é especificada pelo parâmetro modules na sub-rotina irtual-host. Por exemplo: [pdweb-plugins] irtual-host = ibm.com irtual-host = lotus.com [ibm.com] modules = ibm-lotus-module-stanza [lotus.com] modules = ibm-lotus-module-stanza [ibm-lotus-module-stanza] authentication = BA session = BA post-authzn = ltpa Quando sub-rotinas separadas para a configuração de métodos de autenticação para cada host irtual não estão definidas no arquio de configuração, todos os hosts irtuais utilizam os parâmetros configurados na sub-rotina [common-modules]; ou seja, o alor padrão para o parâmetro modules é common modules. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 45

O exemplo a seguir configura um host irtual denominado ibm.com que está configurado para utilizar IDs de sessão SSL onde for possíel, utilizar cabeçalhos BA onde não for possíel utilizar um ID SSL e houer cabeçalhos BA e utilizar cookies de sessões como último recurso para manter informações de sessões. Esse host irtual suporta a autenticação com base em certificados antes da autenticação básica e, após uma autenticação bem-sucedida, adiciona um cookie LTPA ao pedido a ser tratado pelo seridor Web. O exemplo apenas mostra os parâmetros definidos aqui. [pdweb-plugins] irtual-host = ibm.com [modules] ssl-id = pdwpi-ssl-id session-cookie = pdwpi-session-cookie BA = pdwpi-ba cert = pdwpi-cert ltpa = pdwpi-ltpa [ibm.com] session = ssl-id session = BA session = session-cookie authenitcation = cert post-authzn = ltpa A configuração adicional dos parâmetros de autenticação pode ser realizada para cada host irtual por meio da criação de sub-rotinas de configuração de autenticação também específicas para cada host irtual. O exemplo a seguir mostra a configuração para dois hosts irtuais: ibm.com e lotus.com. Cada host irtual possui uma configuração de autenticação específica para cada módulo. [pdweb-plugins] irtual-host = ibm.com irtual-host = lotus.com [modules]... [ibm.com] session = BA session = session-cookie authenitcation = BA authentication = forms [lotus.com] session = session-cookie authenitcation = BA authentication = cert [BA:ibm.com] basic-auth-realm = "Access Manager - ibm.com" [BA:lotus.com] basic-auth-realm = "Access Manager - lotus.com" Configurando a Ordem dos Métodos de Autenticação A ordem na qual os métodos de autenticação configurados são exibidos no arquio de configuração é essencial para a operação correta do software do plug-in. Os 46 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

tipos de métodos de autenticação escolhidos precisam ser cuidadosamente considerados, sendo implementados de forma a não apresentarem falhas e para atender aos seus objetios de segurança. O Tioli Access Manager Plug-in para Web Serers suporta diersos métodos de autenticação, podendo ser ajustado a diferentes requisitos de clientes para necessidades de segurança distintas. Conforme descrito em seções anteriores deste documento, a sub-rotina [common-modules] do arquio de configuração pdwebpi.conf é o local em que ocê especifica os métodos de autenticação que deseja utilizar. A sub-rotina [authentication-leels] do arquio de configuração define níeis de autenticação progressia (consulte Critério de Objetos Protegidos de Intensificação da Autenticação (Progressão) na página 125) e também a ordem dos métodos de autenticação configurados na sub-rotina [common-modules]. Um método de autenticação assume como padrão um níel igual a 1 quando não existe uma entrada definida para esse método na sub-rotina [authenticationleels]. Dessa forma, a ordem de autenticação é determinada como o níel de autenticação mais alto até o níel de autenticação mais baixo para os métodos de autenticação definidos na sub-rotina [authentication-leels]. Se um níel de autenticação for compartilhado por ários módulos, a sub-ordem será determinada pela ordem na qual esses módulos aparecem na sub-rotina [common-modules]. Para compreender a autenticação do plug-in, é útil imaginá-lo fazendo duas perguntas para cada pedido que ele processa: 1. Posso autenticar esse pedido utilizando o método de autenticação configurado? Se a resposta para essa pergunta for negatia, o plug-in fará a próxima pergunta. 2. Posso gerar um pedido de autenticação utilizando o método de autenticação configurado? Considere a configuração a seguir. [common-modules] authentication = BA Para um pedido de entrada, a autenticação do usuário será necessária se a ACL não permitir usuários não autenticados. O plug-in, considerando BA como o único método de autenticação configurado, pergunta: Posso autenticar esse pedido utilizando a autenticação básica? Se o pedido for noo, a resposta será negatia o plug-in não obterá informações sobre esse usuário. Em seguida, o plug-in pergunta: Posso gerar um pedido de autenticação utilizando a autenticação básica? Se a autenticação básica tier sido configurada corretamente, a resposta será positia. O plug-in solicitará que o usuário especifique um ID e uma senha. Esse é um exemplo simples de autenticação com o uso da Autenticação Básica. É bastante proáel que ocê queira configurar mais de um método de autenticação, dependendo dos requisitos de segurança do seu espaço de objetos. As informações a seguir representam um exemplo mais detalhado da lógica utilizada pelo plug-in para dar prioridade a métodos de autenticação específicos. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 47

A lógica de autenticação discutida nos parágrafos a seguir assume que usuários não autenticados não têm permissão para acessar o recurso e que as seguintes configurações foram feitas no arquio de configuração pdwebpi.conf. [common-modules] authentication = BA authentication = failoer authentication = forms post-authzn = failoer [authentication-leels] 1 = BA 2 = failoer A configuração anterior especifica três métodos de autenticação: BA, cookies de failoer e formulários com cookies de failoer utilizados para o processamento pós-autorização. Os níeis definidos na sub-rotina [authentication-leels] determinam a ordem na qual os métodos de autenticação são chamados para autenticar pedidos. A autenticação com base em formulários assume como padrão um níel igual a 1, pois nenhum níel foi definido para essa autenticação na sub-rotina [authentication-leels]. Utilizando a configuração acima, o plug-in, ao receber um pedido, procura um cookie de failoer no cabeçalho do pedido. O plug-in procura um cookie de failoer antes de dados BA porque o failoer está especificado como níel 2 na sub-rotina [authentication-leels]. A sub-rotina [authentication-leels] tem precedência sobre a ordem das definições de módulos de autenticação na sub-rotina [common-modules]. O plug-in faz a primeira pergunta: Posso autenticar esse pedido utilizando um cookie de failoer? Se o pedido não tier sido anteriormente autenticado, a resposta será negatia, pois um cookie de failoer para esse pedido ainda não foi construído pelo plug-in. Em seguida, o plug-in faz a segunda pergunta: Posso gerar um pedido de autenticação utilizando o cookie de failoer? A resposta será negatia, pois o módulo de cookies de failoer não consegue gerar pedidos para autenticação. O plug-in aança para o próximo método de autenticação configurado na sub-rotina [authentication-leels], que, no exemplo, corresponde a BA. Ele faz a primeira pergunta: Posso autenticar esse pedido utilizando o cabeçalho BA? A resposta será negatia, pois o pedido não foi anteriormente autenticado. Em seguida, o plug-in faz a segunda pergunta: Posso gerar um pedido de autenticação utilizando BA? A resposta será proaelmente positia, e o usuário será solicitado a inserir um ID de usuário e uma senha. Uma autenticação bem-sucedida gera uma sessão autorizada, e um cookie de failoer é inserido no cabeçalho do pedido e utilizado como o primeiro método de autenticação para pedidos subseqüentes durante a mesma sessão. Se o módulo BA não conseguisse gerar um método para autenticar o usuário, o plug-in assumiria como padrão a ordem de métodos listadas na sub-rotina [common-modules] do arquio de configuração. No exemplo de configuração anterior, o plug-in atribuiria a prioridade dos métodos de autenticação da seguinte maneira: níel 1 = BA, formulários níel 2 = cookie de failoer 48 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Se os cookies de failoer e a BA não conseguissem fornecer um método para a autenticação do usuário, o plug-in faria a autenticação com o uso de formulários. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 49

O fluxograma a seguir mostra a lógica do plug-in utilizada para selecionar um módulo de autenticação. Figura 2. Fluxo de Processo do Plug-in para Determinar o Módulo de Autenticação. O plug-in chama cada módulo de autenticação na ordem configurada até que um dos módulos retorne uma credencial para o usuário. Se nenhum dos módulos de autenticação configurados conseguir gerar uma credencial, uma solicitação de autenticação será eniada ao usuário para que ele forneça informações de autenticação. Se uma solicitação de autenticação for necessária, o primeiro módulo de autenticação adequado na lista configurada será chamado para gerar os comandos necessários para criar a solicitação. Nem todos os módulos de autenticação podem criar uma solicitação. Por exemplo, não existe uma solicitação para Cabeçalhos HTTP eles estão simplesmente presentes ou ausentes no pedido. Além disso, um módulo de autenticação pode não estar disponíel deido ao fato de já estar sendo utilizado para identificar um agente proxy que está encaminhando pedidos ao plug-in. Os mecanismos de autenticação mais comuns que podem gerar uma solicitação para o usuário são a Autenticação Básica (uma solicitação BA é eniada ao usuário) e a autenticação com base em formulários (um formulário de logon é eniado ao usuário). Se não houer um método de autenticação disponíel, o usuário não poderá ser autenticado, e o plug-in retornará uma página Forbidden (Proibido). O fluxograma na figura 2 mostra o processo de seleção de um método de autenticação para eniar uma solicitação ao usuário. Cada método de autenticação configurado é examinado na respectia ordem de configuração até que seja encontrado um método que atenda ao níel necessário de autenticação. Se for encontrado um módulo que atenda aos critérios de autenticação, ele será chamado para construir a solicitação que é eniada ao usuário. Se nenhum dos métodos de autenticação configurados for adequado, não 50 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

será possíel fazer a autenticação. O plug-in retornará ao usuário uma página Forbidden (Proibido), pois esse usuário não possui as permissões necessárias para acessar o recurso solicitado e não há nenhuma possibilidade de eniar uma solicitação para que ele faça a autenticação no níel necessário. Figura 3. Lógica do Processo de Solicitação de Autenticação. Configurando o Processamento Pós-Autorização Os módulos de pós-autorização configurados serão chamados depois que um pedido tier sido autorizado. Esses módulos determinam se alguma outra ação dee ser realizada antes que um pedido seja noamente transmitido ao plug-in para processamento por parte do seridor Web. Todos os módulos de pós-autorização configurados são chamados para determinar se há necessidade de realizar uma ação nesse pedido. Os módulos de pós-autorização podem ser categorizados como: Pedidos de Modificação para SSO Esses módulos de pós-autorização adicionam informações (cookies ou cabeçalhos) que são utilizadas pelo aplicatio Web para identificar o usuário sem exigir uma segunda autenticação. Respostas de Modificação Esses módulos de pós-autorização modificam respostas geralmente por meio da inclusão de cabeçalhos ou de cookies nessas respostas. Por exemplo, o módulo de failoer adiciona um cookie de failoer às respostas. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 51

Funções Especiais Esses módulos de pós-autorização reconhecem o URI que está sendo solicitado como o acionador para alguma função especial. Uma função especial indica que o pedido é tratado pelo plug-in. Um exemplo disso são os pedidos de garantia ecsso. Os módulos de pós-autorização são chamados na ordem em que aparecem no arquio de configuração. Os módulos de pós-autorização especificados posteriormente na lista têm a capacidade de desfazer ou de sobrescreer as alterações feitas pelos módulos de pós-autorização anteriores. Por exemplo: a configuração a seguir resultará em diferentes comportamentos do plug-in, dependendo da ordem em que BA e forms estierem especificados na sub-rotina [common-modules]. [common-modules]... post-authzn = BA post-authzn = forms [BA]... strip-hdr = always [forms]... create-ba-hdr = yes A configuração anterior é um exemplo simples do grande níel de flexibilidade que pode ser obtido por meio da ordenação de módulos de pós-autorização e da configuração de módulos. Gerenciando o Estado de Sessões Informações de estado de sessões são utilizadas pelo plug-in para identificar a origem dos pedidos de entrada. O plug-in utiliza a identidade da origem do pedido para manter o estado da sessão entre o cliente e o seridor quando o cliente executa diersos pedidos em uma única sessão. Sem um estado de sessão estabelecido entre o cliente e o seridor, a comunicação entre eles deerá ser noamente negociada para cada pedido subseqüente. As informações de estado de sessões aprimoram o desempenho, eliminando a necessidade de repetir a autenticação. O cliente pode efetuar logon uma ez e fazer diersos pedidos sem efetuar um logon separado para cada um desses pedidos. O Tioli Access Manager Plug-in para Web Serers trata a comunicação HTTP e a comunicação HTTPS. O plug-in foi desenolido para utilizar qualquer um dos tipos de informações a seguir para manter o estado da sessão com um cliente: 1. ID da Sessão SSL 2. Autenticação Básica 3. Cookie de sessão específico do seridor 4. Dados de cabeçalhos HTTP 5. Endereço IP 6. Cookies LTPA 7. Cabeçalhos IV O plug-in chama cada módulo de sessão configurado de acordo com a respectia ordem. Ele continua a pesquisar os tipos de módulos de sessão configurados até que um deles retorne uma credencial. Em seguida, o plug-in determina se o 52 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

aplicatio faz referência a um MPA (Agente Proxy de Multiplexação). Se for um Agente Proxy, outra sessão deerá existir para o usuário final real. Para encontrar essa outra sessão, o plug-in continua a chamar o restante dos módulos de sessão configurados. Uma credencial de usuário é retornada quando o plug-in encontra uma sessão existente para a qual já ocorreu uma autenticação de usuário. Essa credencial é utilizada para autorizar o pedido. Se nenhum dos módulos de sessão configurados retornar uma credencial de usuário, significa que a sessão é noa ou é uma sessão para a qual nenhuma credencial foi estabelecida. Figura 4. Fluxo de Processo do Plug-in para dderminar o Módulo de Sessão. Configurando o Cache de Sessão/Credenciais do Plug-in O cache de sessão do plug-in permite que um seridor armazene as informações de IDs de sessão a partir de diersos clientes. O cache de sessão acomoda informações de estados de sessões HTTPS e HTTP. O cache do plug in armazena as informações de IDs de sessão e também as informações de credenciais obtidas para cada cliente. Essas informações de credenciais são armazenadas em cache para eliminar consultas repetitias no banco de dados de registros de usuários durante erificações de autorização. Esse cache também mantém informações de estado de sessões para conexões SSL entre o plug-in e o registro de usuários LDAP. Existem ários parâmetros de configuração disponíeis para o cache do plug-in que permitem aprimorar o desempenho desse cache. Nota: Os alores configurados na sub-rotina [sessions] do arquio de configuração pdwebpi.conf podem ser substituídos na sub-rotina [module_name], e alguns desses alores podem ser adicionalmente substituídos na sub-rotina [module_name:irtual_host_name] para cada host irtual. Definindo o Valor Máximo de Entradas Simultâneas O parâmetro max-entries, localizado na sub-rotina [sessions] do arquio de configuração pdwebpi.conf, define o número máximo de entradas simultâneas no cache de sessão/credenciais de cada módulo de sessão. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 53

Esse alor corresponde ao número de sessões de logon simultâneas para um módulo de sessão específico. Quando o tamanho do cache atingir esse alor, as entradas serão remoidas desse cache, de acordo com o algoritmo menos recentemente utilizado, para permitir noos logons de entrada. O número padrão de sessões de logon simultâneas é 4096: [sessions] max-entries = 4096 Definindo o Valor de Tempo Limite de Entradas do Cache O parâmetro timeout, localizado na sub-rotina [sessions] do arquio de configuração pdwebpi.conf, define o tempo limite de duração máximo para uma entrada no cache de sessão/credenciais do plug-in. O plug-in armazena as informações de credenciais internamente no cache. O parâmetro de tempo limite do cache de sessão determina o tempo durante o qual as informações de credenciais de autorização permanecem na memória. Esse parâmetro não corresponde a um tempo limite de inatiidade. O alor é mapeado para uma duração de credencial e não para um tempo limite de credencial. Sua finalidade é aprimorar a segurança forçando o usuário a fazer uma reautenticação quando o tempo limite especificado for atingido. O tempo limite (em segundos) de sessões de logon padrão é 3600: [sessions] timeout = 3600 É possíel configurar a duração do cache de sessão de forma que ele seja redefinido sempre que ocorrer uma reautenticação. Sempre que essa reautenticação ocorrer, o alor de timeout do cache de sessão será redefinido. Para configurar a redefinição da duração do cache de sessão, utilize o parâmetro reauth-lifetime-reset na sub-rotina [sessions] do arquio de configuração pdwebpi.conf: [sessions] reauth-lifetime-reset = yes O alor padrão é no. É possíel que o alor de duração do cache de sessão expire enquanto o usuário estier executando uma reautenticação. A duração do cache de sessão pode expirar após o enio do formulário de logon de reautenticação para o usuário e antes do retorno do formulário de logon preenchido. Quando o alor de duração do cache de sessão expirar, a entrada desse cache será excluída. Quando o formulário de logon for retornado ao plug-in, não haerá mais uma sessão para esse usuário. Além disso, todos os dados de pedidos do usuário armazenados em cache serão perdidos. Será possíel configurar uma extensão de tempo, ou um período de tolerância, para a duração do cache de sessão se ela expirar durante a reautenticação. O parâmetro reauth-grace-period na sub-rotina [sessions] do arquio de configuração pdwebpi.conf fornece essa extensão de tempo, em segundos. Por exemplo: [reauthentication] reauth-grace-period = 20 54 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

O alor padrão, 0, não fornece uma extensão para o alor de tempo limite do cache de sessão. O parâmetro reauth-grace-period aplica-se a usuários com entradas existentes no cache de sessão e que precisam executar uma reautenticação. Por exemplo: Usuários que executam uma reautenticação resultante de um critério de segurança POP, Usuários que executam uma reautenticação resultante da inatiidade do cache de sessão, Usuários que executam uma autenticação progressia. A opção reauth-grace-period está destinada para uso junto com a opção reauth-lifetime-reset = yes. Definindo o Valor de Tempo Limite de Inatiidade de Entradas do Cache O parâmetro inactie-timeout, localizado na sub-rotina [sessions] do arquio de configuração pdwebpi.conf, define o alor de tempo limite para a inatiidade de sessões de logon. O tempo limite (em segundos) de inatiidade de sessões de logon padrão é 600: [sessions] inactie-timeout = 600 Para desatiar esse recurso de tempo limite, defina o alor do parâmetro como 0. Mantendo o Estado de Sessões com o ID da Sessão SSL O Tioli Access Manager Plug-in para Web Serers pode rastrear sessões utilizando o ID da sessão SSL de pedidos HTTPS de entrada. Esse recurso não está disponíel no IIS, pois o IIS não disponibiliza IDs de sessão SSL para o plug-in. Nota: IDs de sessão SSL não são utilizados para a autenticação de pedidos. A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de sessão, autenticação e pós-autorização com o uso do formato module_type = module-name. Para manter o estado de sessões com o uso de IDs de sessão SSL, atribua a expressão ssl-id ao parâmetro session, conforme mostrado a seguir: [common-modules] session = ssl-id Assegure-se de que a biblioteca compartilhada para ssl-id esteja configurada na sub-rotina [modules] do arquio de configuração pdwebpi.conf. Ou seja: [modules] ssl-id = pdwpi-sslsessid-module Mantendo o Estado de Sessões com o Uso da Autenticação Básica A BA (Autenticação Básica) é um método de autenticar usuários e manter o estado de sessões por meio da entrada de um nome de usuário e de uma senha. A BA é definida pelo protocolo HTTP e pode ser implementada ia HTTP e HTTPS. Ela mantém o estado de sessões armazenando em cache um registro do conteúdo do cabeçalho BA. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 55

Para configurar o plug-in de forma que ele mantenha o estado de sessões com o uso da Autenticação Básica, utilize a sub-rotina [common-modules] no arquio de configuração pdwebpi.conf. Insira o parâmetro session com o alor como BA, conforme mostrado a seguir: [common-modules] session = BA Se a BA for utilizada para manter o estado de sessões, também precisará ser utilizada para autenticação de usuários. A sub-rotina [common modules] do arquio de configuração também dee definir a BA para autenticação. [common-modules] session = BA authentication = BA Aiso de Segurança: O uso do cabeçalho de autorização por Autenticação Básica para identificar sessões pode expor os usuários do seridor Web a constantes ataques de detecção de senha. Essa é uma limitação do esquema de Autenticação Básica HTTP, que inclui a senha do usuário no cabeçalho de autorização. O Tioli Access Manager Plug-in para Web Serers não é atiado por padrão. A capacidade de identificação de sessões da Autenticação Básica é fornecida para os Administradores que estão conscientes de todos os riscos de segurança associados à Autenticação Básica, incluindo o risco mencionado acima. A identificação de sessões da Autenticação Básica pode ser utilizada com segurança quando um seridor Web protegido pelo plug-in opera atrás de um agente proxy de multiplexação (por exemplo, atrás de campos de junção do WebSEAL) utilizando a Autenticação Básica para se autenticar no plug-in. Nessa situação, o agente proxy de multiplexação não encaminha cabeçalhos de autorização por Autenticação Básica a partir de usuários para o plug-in, tornando o ataque impossíel. Mantendo o Estado de Sessões com Cookies de Sessão O uso de cookies de sessão para receber informações de sessões é um método de manter o estado de sessões do plug-in. O seridor compacta as informações de estado para um cliente específico em um cookie e enia esse cookie ao naegador do cliente. Para cada noo pedido, o naegador se auto-identifica noamente, eniando o cookie (com o identificador de sessão) de olta ao seridor. Cookies de sessão oferecem uma solução possíel para situações em que o cliente utiliza um naegador que renegocia sua sessão SSL após períodos de tempo muito curtos. Por exemplo, algumas ersões do naegador Microsoft Internet Explorer renegociam sessões SSL a cada dois ou três minutos. Um cookie de sessão possibilita a reautenticação de um cliente apenas ao seridor no qual esse cliente se autenticou dentro de um curto período de tempo (cerca de dez minutos). O mecanismo tem como base um cookie de sessão que não pode ser transmitido a nenhuma máquina diferente da que gerou esse cookie. Além disso, o cookie de sessão contém um identificador de números aleatórios que é utilizado para indexar o cookie no cache de sessão do seridor nenhuma outra informação é exposta no cookie de sessão. Esse cookie de sessão não pode prejudicar o critério de segurança. 56 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

O Tioli Access Manager Plug-in para Web Serers utiliza um cookie de sessão específico para cada seridor protegido As condições a seguir aplicam-se a esse mecanismo de cookies: O cookie contém apenas informações de sessões; não contém informações de identidade. O cookie está localizado apenas na memória do naegador (ele não é graado em disco, no arquio jar de cookies do naegador). O cookie apresenta uma duração limitada (configuráel). O cookie possui parâmetros de caminho e de domínio que proíbem seu uso por outros seridores. Para configurar o plug-in de forma que ele utilize cookies de sessão para manter o estado de sessões, utilize a sub-rotina [common-modules] no arquio de configuração pdwebpi.conf. Insira o parâmetro session com o alor como session-cookie, conforme mostrado a seguir: [common-modules] session = session-cookie O parâmetro resend-pdwebpi-cookies, localizado na sub-rotina [sessions] do arquio de configuração pdwebpi.conf, atia ou desatia o enio do cookie de sessão ao naegador com cada resposta. Essa ação ajuda a assegurar que o cookie de sessão permaneça na memória do naegador. O parâmetro resend-pdwebpi-cookies possui uma definição padrão igual a no: [sessions] resend-pdwebpi-cookies = no Altere essa definição padrão para yes de forma a eniar cookies de sessão do plug-in com cada resposta. Mantendo o Estado de Sessões com o Uso de Cabeçalhos HTTP O Tioli Access Manager Plug-in para Web Serers pode ser configurado para utilizar informações de cabeçalhos HTTP para identificar sessões e manter o estado de sessões. O plug-in pode utilizar cabeçalhos HTTP para rastrear sessões e também para autenticar usuários. Se o plug-in for configurado para utilizar cabeçalhos HTTP de forma a rastrear sessões, também deerá ser configurado para utilizar cabeçalhos HTTP de forma a autenticar usuários. Entretanto, fazer com que o plug-in seja configurado para autenticar pedidos de entrada com o uso de cabeçalhos HTTP não implica que ele precise estar configurado para rastrear sessões. Consulte Configurando a Autenticação com Base em Cabeçalhos HTTP na página 103 para obter detalhes sobre como configurar o plug-in para utilizar cabeçalhos HTTP para a autenticação de clientes. Ao utilizar cabeçalhos HTTP para manter o estado de sessões, a sub-rotina [common-modules] do arquio de configuração pdwebpi.conf dee ser configurada com os seguintes alores: [common-modules] authentication = http-hdr session = http-hdr Uma configuração padrão de cabeçalhos HTTP permite que apenas um cabeçalho seja especificado, por exemplo: Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 57

[modules] http-hdr = pdwpi-httphdr-module Para especificar ários cabeçalhos HTTP, diersas instâncias do módulo de cabeçalhos HTTP deem ser configuradas. Por exemplo: [modules] entrust-client-header = pdwpi-httphdr-module some-other-header = pdwpi-httphdr-module [entrust-client-header] header = entrust-client [some-other-header] header = some-other Mantendo o Estado de Sessões com o Uso de Endereços IP O Tioli Access Manager Plug-in para Web Serers pode utilizar endereços IP para identificar e rastrear sessões. Para configurar o plug-in de forma que ele utilize endereços IP para rastrear sessões, utilize a sub-rotina [common-modules] do arquio de configuração pdwebpi.conf. Insira o parâmetro session com o alor como ip-addr. Ou seja: [common-modules] session = ip-addr Assegure-se de que a biblioteca compartilhada para a autenticação com base em endereços IP esteja configurada na sub-rotina [modules] do arquio de configuração pdwebpi.conf. Ou seja: [modules] ip-addr = pdwpi-ipaddr-module Se endereços IP forem utilizados para manter o estado de sessões, também deerão ser utilizados para autenticar pedidos de entrada. Consulte Configurando a Autenticação com Base em Endereços IP na página 104 para obter detalhes sobre como configurar o Tioli Access Manager Plug-in para Web Serers de forma a utilizar o endereço IP como o método de autenticação de clientes. Entretanto, o uso de endereços IP para autenticar clientes não requer que esses endereços sejam utilizados como o método de identificar sessões. Mantendo o Estado de Sessões com o Uso de Cookies LTPA A autenticação LTPA pode ser utilizada para aceitar e autenticar com base em um cookie LTPA. A Autenticação LTPA pode manter o estado de sessões com o uso do cookie LTPA encontrado em cada pedido HTTP. Para configurar o plug-in de forma que ele mantenha o estado de sessões com o uso da Autenticação LTPA, utilize a sub-rotina [common-modules] no arquio de configuração pdwebpi.conf. Insira o parâmetro session com o alor como ltpa, conforme mostrado a seguir: [common-modules] session = ltpa Se o LTPA for utilizado para manter o estado de sessões, também precisará ser configurado para autenticação de usuários. A sub-rotina [common-modules] do arquio de configuração também dee definir o LTPA para autenticação. 58 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

[common-modules] authentication = ltpa session = ltpa Mantendo o Estado de Sessões com o Uso de Cabeçalhos IV O Tioli Access Manager Plug-in para Web Serers pode armazenar em cache informações de cabeçalhos i para aprimorar o desempenho do sistema. A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de sessão, autenticação e pós-autorização com o uso do formato module_type = module-name. Para armazenar em cache informações de cabeçalhos i, atribua o alor i-headers ao parâmetro session, conforme mostrado a seguir: [common-modules] session = i-headers Assegure-se de que a biblioteca compartilhada para cabeçalhos i esteja configurada na sub-rotina [modules] do arquio de configuração pdwebpi.conf. Ou seja: [modules] i-headers = pdwpi-i-headers-module Visão Geral da Configuração de Autenticação Conforme abordado na seção Configurando a Autenticação na página 43, os módulos de autenticação são responsáeis por executar o processo de extração de informações de autenticação a partir de pedidos. A autenticação real dos pedidos é executada por mecanismos de autenticação que alidam essas informações de autenticação. A separação de funções entre módulos de autenticação e mecanismos de autenticação permite que bibliotecas CDAS personalizadas graadas para o WebSEAL sejam utilizadas com o plug-in. Os mecanismos para todos os métodos de autenticação suportados pelo Tioli Access Manager Plug-in para Web Serers são configurados nas sub-rotinas [authentication-mechanisms] do arquio de configuração pdwebpi.conf. Os parâmetros de métodos de autenticação suportados incluem: Autenticadores locais (internos) Os parâmetros para autenticadores locais especificam a biblioteca interna compartilhada (UNIX) ou os arquios DLL (Windows) apropriados. Autenticadores externos personalizados O plug-in fornece um gabarito de código de seridor que pode ser utilizado para construir e especificar um seridor CDAS (Cross Domain Authentication Serice) externo personalizado. Um autenticador CDAS externo especifica a biblioteca compartilhada personalizada mais apropriada. Nota: Ao contrário da configuração para a sub-rotina [modules], adicione o nome do arquio completo ao configurar mecanismos na sub-rotina [authentication-mechanisms]. Ou seja, inclua o prefixo do arquio e a extensão específica do sistema operacional. Mecanismos de Autenticação Locais Os seguintes parâmetros de mecanismos de autenticação especificam autenticadores locais internos: Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 59

Tabela 10. Autenticadores Locais Internos. Parâmetro Formulários e Autenticação Básica passwd-ldap Descrição Acesso de clientes com um nome de usuário e uma senha LDAP. Autenticação com Base em Certificados no Lado do Cliente cert-ssl Acesso de clientes com o uso de um certificado no lado do cliente ia SSL. Cabeçalho HTTP, Autenticação com Base em Endereço IP, Cabeçalho IV com i-remote-address atiado. http-request Acesso de clientes pode meio de um cabeçalho HTTP especial, um endereço IP ou um Cabeçalho IV com i-remote-address atiado. Utilize a sub-rotina [authentication-mechanisms] para configurar o método de autenticação e a implementação no seguinte formato: authentication_method_parameter = shared_library Parâmetros de Autenticação do CDAS Externo Personalizado Os parâmetros a seguir estão disponíeis para especificar bibliotecas compartilhadas personalizadas para seridores CDAS externos: Tabela 11. Parâmetros de Seridores CDAS Externos. Parâmetro passwd-cdas token-cdas cert-cdas Descrição Acesso de clientes com um nome de usuário e uma senha para um registro de terceiros. Acesso de clientes com um nome de usuário LDAP e um código de acesso de token. Acesso de clientes com o uso de um certificado no lado do cliente ia SSL. Além das bibliotecas de autenticação, existem duas outras bibliotecas padrão do Tioli Access Manager que podem ser utilizadas no plug-in: passwd-strength Essa biblioteca erifica noas senhas inseridas no formulário de alteração de senha. cred-ext-attrs Essa biblioteca permite que atributos personalizados (pares de nome/alor) sejam especificados para inclusão na credencial. Consulte o documento IBM Tioli Access Manager for e-business Web Security: Referência para Desenoledores para obter detalhes sobre como construir e configurar uma biblioteca compartilhada personalizada que implemente um seridor CDAS. Configuração Padrão para Plug-ins Por padrão, o plug-in está definido para autenticar clientes utilizando nomes de usuários e senhas (registro LDAP) da BA (Autenticação Básica). 60 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

O plug-in é normalmente atiado para o acesso TCP e para o acesso SSL. Portanto, uma configuração típica da sub-rotina [authentication-mechanisms] inclui suporte para o nome de usuário e a senha (registro LDAP) e suporte para certificados no lado do cliente ia SSL. O exemplo a seguir representa a configuração típica da sub-rotina [authentication-mechanisms] no Solaris: [authentication-mechanisms] passwd-ldap = libldapauthn.so cert-ssl = pdwpi-sslauthn.so Para configurar outros métodos de autenticação, adicione o parâmetro apropriado com sua biblioteca compartilhada (ou módulo CDAS). Configurando Vários Métodos de Autenticação A sub-rotina [authentication-mechanisms] do arquio de configuração pdwebpi.conf é modificada para especificar a biblioteca compartilhada a ser utilizada para qualquer método de autenticação suportado. As condições a seguir aplicam-se durante a configuração de ários métodos de autenticação: 1. Todos os métodos de autenticação podem funcionar sem dependerem uns dos outros. É possíel configurar uma biblioteca compartilhada para cada método suportado. 2. O método cert-cdas substitui o método cert-ssl quando ambos são configurados. É necessário atiar um desses métodos para suportar certificados no lado do cliente. 3. Apenas um autenticador do tipo senha é realmente utilizado quando mais de um autenticador é configurado. O plug-in utiliza a seguinte ordem de prioridade para resoler ários autenticadores de senha configurados: a. passwd-cdas b. passwd-ldap 4. É possíel configurar a mesma biblioteca compartilhada para dois diferentes métodos de autenticação. Por exemplo, ocê pode graar uma biblioteca compartilhada personalizada para processar a autenticação com base em cabeçalho HTTP e com base em nome do usuário/senha. Para esse exemplo, seria possíel configurar ambos os parâmetros passwd-cdas e http-request com a mesma biblioteca compartilhada. O desenoledor é responsáel por manter o estado de sessões e por eitar conflitos entre os dois métodos. Comandos de Logout, Alteração de Senha e Ajuda O Tioli Access Manager oferece os seguintes comandos para suportar clientes que se autenticam ia HTTP ou HTTPS. pkmslogout Os clientes podem utilizar o comando pkmslogout para efetuar logout a partir da sessão atual quando utilizam um método de autenticação que não fornece dados de autenticação para cada pedido. Ao utilizar um método de autenticação que fornece dados de autenticação para cada pedido, o comando pkmslogout limpará o cache de sessão mesmo que as informações de credenciais ainda estejam contidas no cabeçalho do pedido. Nesse caso, o usuário dee fechar o naegador para efetuar logout totalmente a partir da sessão. O comando pkmslogout é apropriado para autenticação com o uso de códigos de acesso de token, autenticação com base em Formulários e determinadas implementações da autenticação com base em cabeçalho HTTP. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 61

Execute o comando desta maneira: https://www.tioli.com/pkmslogout O naegador exibe um formulário de logout definido no arquio de configuração pdwebpi.conf: [acctmgmt] logout-success = logout_success.html A entrada logout-success pode especificar um arquio HTML predefinido (contido no diretório base install_path/nls/html/c) ou um URI. O URI especificado pode ser um URI relatio ou um URI absoluto. O utilitário pkmslogout também suporta diersas páginas de resposta de logout quando a arquitetura da rede requer diferentes telas de saída para usuários que efetuam logout de hosts irtuais nitidamente distintos. pkmspasswd É possíel utilizar esse comando para alterar a senha de logon ao utilizar a BA (Autenticação Básica) ou a autenticação com base em Formulários. Esse comando é apropriado ia HTTP ou HTTPS. Por exemplo: https://www.tioli.com/pkmspasswd O naegador exibe um formulário de alteração de senha definido no arquio de configuração pdwebpi.conf: [acctmgmt] password-change-form-uri = /pkmspasswd.form password-change-uri = /pkmspasswd password-change-success = password_change_success.html password-change-failure = password_change_failure.html Você pode modificar os arquios password_change_success.html e password_change_failure.html para atender a suas exigências. pkmshelp É possíel utilizar esse comando para acessar páginas de ajuda. Esse comando é apropriado ia HTTP ou HTTPS. O nome e a localização das páginas de ajuda são definidos no arquio de configuração pdwebpi.conf: [acctmgmt] help-uri = /pkmshelp help-page = help.html Você pode modificar o arquio help.html para atender a suas exigências. Configurando a Autenticação Básica A BA (Autenticação Básica) é um método padrão de fornecer um nome de usuário e uma senha ao mecanismo de autenticação. A BA é definida pelo protocolo HTTP e é implementada ia HTTP e HTTPS. 62 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Atiando a Autenticação Básica Por padrão, o plug-in está configurado para um nome de usuário e uma senha BA. A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso da BA para a autenticação de pedidos. Ou seja: [common-modules] authentication = BA A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e o respectio nome da biblioteca compartilhada associada. Assegure-se de que a entrada para a autenticação básica esteja presente, ou seja: [modules] BA = pdwpi-ba-module Por padrão, o mecanismo de autenticação por BA recebe um níel 1 na sub-rotina [authentication leels] do arquio de configuração. Essa definição está relacionada à prioridade dos mecanismos de autenticação para pedidos de entrada. Configurando o Mecanismo de Autenticação Básica O parâmetro passwd-ldap especifica a biblioteca compartilhada utilizada para tratar a autenticação com base em nome de usuário e senha. No UNIX, o arquio que fornece a função de mapeamento interno é uma biblioteca compartilhada que se chama libldapauthn. No Windows, o arquio que fornece a função de mapeamento interno é uma DLL que se chama ldapauthn. É possíel configurar o mecanismo de autenticação com base em nome de usuário e senha inserindo o parâmetro passwd-ldap com o nome do arquio de biblioteca compartilhada específico para cada plataforma na sub-rotina [authenticationmechanisms] do arquio de configuração pdwebpi.conf conforme mostrado a seguir: Solaris: [authentication-mechanisms] passwd-ldap = libldapauthn.so Windows: [authentication-mechanisms] passwd-ldap = ldapauthn.dll Definindo o Nome da Região A região é exibida no diálogo apresentado por um naegador ao usuário de forma a solicitar um nome de usuário e uma senha. O nome dessa região é atribuído ao parâmetro basic-auth-realm na sub-rotina [BA] do arquio de configuração pdwebpi.conf. [BA] basic-auth-realm = realm_name Manipulando Cabeçalhos BA É possíel configurar o plug-in para fornecer informações sobre identidades de clientes originais ou modificadas a aplicatios protegidos, controlando o conteúdo dos cabeçalhos BA que são eniados ao seridor Web. O cabeçalho existente que é eniado ao cliente pode ser: Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 63

retirado de todos os pedidos, retirado de pedidos não autenticados, transmitido sem alterações para todos os pedidos. Para clientes que não fornecem um cabeçalho BA ou para informações de cabeçalhos de clientes existentes transmitidas ao seridor Web, as informações de cabeçalhos podem: ser definidas como um nome de usuário e uma senha fixos, ter uma senha fixa eniada (com o nome do usuário transmitido como o nome do usuário autenticado), ser definidas com o uso de informações de segurança GSO do Tioli Access Manager. Para manipular os cabeçalhos BA de pedidos de entrada, o plug-in dee ser configurado para permitir o processamento pós-autorização utilizando a Autenticação Básica. Para fazer isso, adicione o parâmetro post-authzn e defina-o como o alor BA na sub-rotina [common-modules] do arquio de configuração pdwebpi.conf. Ou seja: [common-modules] post-authzn = BA O parâmetro strip-hdr fornece instruções para que o plug-in utilize os seguintes alores: Valor ignore always Resultado Deixar o cabeçalho no estado em que se encontra. O plug-in transmite o cabeçalho BA do cliente original ao recurso sem nenhuma interferência. Isso constitui basicamente em um login direto no recurso, transparente ao plug-in para situações em que ocê deseja desiar-se da autenticação do plug-in. Notas: 1. Essa opção permite potencialmente que usuários não autenticados eniem cabeçalhos BA ao seridor Web. Somente a utilize se ocê tier certeza de que ela é necessária e de que compreende as implicações de segurança. 2. Quando a autenticação BA estier configurada no plug-in e o recurso protegido tentar autenticar o cliente com sua própria solicitação BA, as credenciais do usuário não serão aceitas por esse recurso protegido. Outros mecanismos de autenticação, como Formulários, configurados no plug-in transmitirão o cabeçalho BA do cliente original ao recurso sem nenhuma interferência. Sempre remoer as informações de cabeçalhos de Autenticação Básica de todos os pedidos de clientes antes de encaminhar esses pedidos ao seridor Web. Nesse caso, o plug-in torna-se o único proedor de segurança. Se ocê precisar fornecer ao seridor Web algumas informações de clientes, poderá combinar essa opção com a autenticação com base em cabeçalho IV de forma a colocar informações de identidade de clientes do Tioli Access Manager nos campos dos cabeçalhos HTTP. Nota: Se o seridor protegido eniar uma solicitação BA com essa opção atiada, o cliente isualizará uma janela pop-up de autenticação, mas não poderá efetuar login porque sua resposta sempre será remoida. 64 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Valor unauth Resultado O cabeçalho BA recebido do cliente é remoido de todos os pedidos, com exceção dos pedidos proenientes de usuários que foram autenticados pelo plug-in com o uso da Autenticação Básica. Isso permite que os usuários autenticados eniem cabeçalhos BA autenticados ao seridor Web, mas preine que o mesmo seja feito por um usuário não autenticado. O parâmetro add-hdr na sub-rotina [BA] do arquio de configuração permite que ocê forneça informações de identidade de clientes em cabeçalhos HTTP BA (Autenticação Básica). O fornecimento de informações de identidade de clientes em cabeçalhos HTTP BA com o uso do parâmetro add-hdr ocorre após qualquer processamento feito pela funcionalidade do parâmetro strip-hdr. O parâmetro add-hdr pode ser definido como: none, gso ou supply. Definido como none, um cabeçalho BA não é adicionado ao pedido. Definido como gso, um cabeçalho GSO BA é adicionado ao pedido consulte Utilizando a GSO (Conexão Única Global) na página 141 para obter informações detalhadas sobre como configurar a funcionalidade GSO do plug-in. Definido como supply, uma senha e um nome de usuário estáticos são adicionados ao cabeçalho BA. Essa senha e esse nome de usuário estáticos são definidos nos parâmetros supply-password e supply-username, na sub-rotina [BA] do arquio de configuração. O parâmetro supply-username pode ser definido como um alor de nome de usuário fixo. Se o parâmetro supply-username não for definido, o nome do usuário no cabeçalho BA será criado com o uso do nome do usuário autenticado do Tioli Access Manager. Nesse caso, o recurso protegido do plug-in requer uma autenticação a partir de uma identidade do Tioli Access Manager. Quando o parâmetro add-hdr for definido como supply e os parâmetros supply-password e supply-username estierem definidos, o nome do usuário e a senha especificados serão utilizados para todos os pedidos. O uso de um nome de usuário e de uma senha comuns não oferece uma base para que o seridor de aplicatios comproe a legitimidade do cliente que está efetuando login com esse nome de usuário. Se os clientes sempre passarem pelo plug-in para acessar recursos, essa solução não apresentará problemas de segurança. Entretanto, é importante proteger os recursos fisicamente contra outros possíeis meios de acesso. Como esse cenário não possui segurança em níel de senha, os recursos protegidos do plug-in deem confiar implicitamente no plug-in para comproar a legitimidade do cliente. O registro de usuários também dee reconhecer a identidade do Tioli Access Manager de forma a aceitá-la. Se supply-username não for definido e o usuário não estier autenticado, nenhum cabeçalho BA será adicionado ao pedido. Especifique a Codificação UTF-8 de Cabeçalhos BA Edite o arquio de configuração do plug-in. Especifique se o plug-in dee ou não utilizar a codificação UTF-8 para cabeçalhos BA. [BA] use-utf8 = true O alor padrão é true. Para obter informações adicionais sobre o suporte do plug-in para a codificação UTF-8, consulte Suporte a Idiomas e Conjuntos de Caracteres na página 37. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 65

Configurando a Autenticação com Base em Formulários O Tioli Access Manager fornece a autenticação com base em Formulários como uma alternatia para o mecanismo padrão de Autenticação Básica. Esse método gera um formulário de logon HTML personalizado a partir do Tioli Access Manager em ez do prompt de logon padrão resultante de uma solicitação de Autenticação Básica. Quando ocê utiliza a logon com base em Formulários, o naegador não armazena em cache as informações de nome de usuário e senha, o que ocorre com a Autenticação Básica. Atiando a Autenticação com Base em Formulários A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a autenticação utilizando formulários, atribua a expressão forms ao parâmetro authentication, ou seja: [common-modules] authentication = forms Ao utilizar formulários para autenticação, o plug-in também dee ser configurado para utilizar formulários para o processamento pós-autorização. O uso de formulários permite que o plug-in redirecione o usuário autenticado de olta ao URL do pedido original. Na sub-rotina [common-modules] do arquio de configuração pdwebpi.conf, adicione o parâmetro pre-authzn, conforme mostrado a seguir: [common-modules] authentication = forms pre-authzn = forms A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e o respectio nome da biblioteca compartilhada associada. Assegure-se de que a entrada para a autenticação com base em formulários esteja presente, ou seja: [modules] forms = pdwpi-forms-module Configurando o Mecanismo de Autenticação com Base em Formulários O parâmetro passwd-ldap especifica a biblioteca compartilhada utilizada para tratar a autenticação com base em nome de usuário e senha. No UNIX, o arquio que fornece a função de mapeamento interno é uma biblioteca compartilhada que se chama libldapauthn. No Windows, o arquio que fornece a função de mapeamento interno é uma DLL que se chama ldapauthn. É possíel configurar o mecanismo de autenticação com base em nome de usuário e senha inserindo o parâmetro passwd-ldap com o nome do arquio de biblioteca compartilhada específico para cada plataforma na sub-rotina [authenticationmechanisms] do arquio de configuração pdwebpi.conf, conforme mostrado a seguir: Solaris: [authentication-mechanisms] passwd-ldap = libldapauthn.so 66 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Windows: [authentication-mechanisms] passwd-ldap = ldapauthn.dll Personalizando Formulários de Resposta HTML A autenticação com base em formulários requer o uso de um formulário de logon personalizado. Por padrão, o formulário login.html de amostra está localizado no seguinte diretório: install_path/nls/html/lang/charset. Em que lang é obtido a partir da configuração do NLS. Em sistemas no idioma inglês (EUA), o diretório lang é chamado de C e charset corresponde a utf-8. O parâmetro login-form na sub-rotina [forms] do arquio de configuração define o nome do arquio do formulário apresentado ao usuário durante o logon. O caminho do arquio dee ser relatio ao diretório HTML pdwebpi traduzido (por exemplo, pdwebpi/nls/html/lang/charset). [forms] login-form = login.html Nota: A remoção do campo wpi_url do formulário login.html fará com que dados POST, submetidos com o formulário de login, fiquem disponíeis no pedido HTTP como ariáeis de dados POST. Isso inclui o nome do usuário e a senha utilizados para efetuar login no Tioli Access Manager. Além disso, a remoção do campo wpi_url de um formulário desatia toda a funcionalidade de armazenamento em cache de dados POST, e macros como %POST_URL% deixarão de ser suportadas. Personalizando o URI de Login com base em Formulários É possíel fazer com que árias instâncias do módulo de login com base em formulários sejam utilizadas em um único host irtual. Nesses casos, é necessário alterar o URI lançado quando o formulário de login é submetido para cada instância separada do módulo de login com base em formulários. O parâmetro login-uri na sub-rotina [forms] controla esse URI. Se for alterado a partir do padrão, o formulário especificado pelo parâmetro login-form (consulte Personalizando Formulários de Resposta HTML ) deerá ser atualizado para refletir essa alteração. Criando um Cabeçalho BA A autenticação com base em formulários oferece a capacidade de criar um cabeçalho BA com base no nome do usuário e na senha fornecidos no formulário de login. A criação do cabeçalho proporciona um mecanismo simples de conexão única que pode ser utilizado quando o aplicatio de backend requer uma autenticação básica e quando o nome de usuário e a senha correspondem aos utilizados pelo Tioli Access Manager. A criação do cabeçalho BA é tratada pelo módulo de pós-autorização com base em formulários. Adicione uma entrada para o processamento pós-autorização com base em formulários à sub-rotina [common-modules] do arquio de configuração do plug-in: [common-modules] post-authzn = forms O parâmetro create-ba-hdr na sub-rotina [forms] do arquio de configuração atia ou desatia a criação de cabeçalhos BA, por exemplo: Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 67

[forms] create-ba-hdr = yes Por padrão, a autenticação com base em formulários não cria o cabeçalho BA - create-ba-hdr é definido como no. Independentemente de como o parâmetro está definido, um cabeçalho BA não será criado quando o usuário não for autenticado com êxito e um cabeçalho não será criado quando a senha desse usuário tier expirado. Nota: Se outro módulo após o módulo de formulários na lista post-authzn sobrescreer o cabeçalho BA (ou remoê-lo), essa função não funcionará. Coném fazer com que o módulo de formulários seja especificado como o último módulo na lista post-authzn. Especifique a Codificação UTF-8 em Cabeçalhos BA Edite o arquio de configuração do plug-in. Especifique se o plug-in dee ou não utilizar a codificação UTF-8 para cabeçalhos BA. [forms] use-utf8 = true O alor padrão é true. Para obter informações adicionais sobre o suporte do plug-in para a codificação UTF-8, consulte Suporte a Idiomas e Conjuntos de Caracteres na página 37. Configurando a Autenticação com Base em Certificados O Tioli Access Manager Plug-in para Web Serers suporta a comunicação segura com clientes utilizando certificados digitais no lado do cliente ia SSL. Nesse método de autenticação, as informações de certificados (como o Nome Distinto, ou DN) são mapeadas para uma identidade do Tioli Access Manager. Autenticação Mútua Utilizando Certificados A autenticação com o uso de certificados digitais ocorre em dois estágios: O seridor Web no qual o plug-in está localizado se identifica aos clientes SSL com seu certificado no lado do seridor. O seridor Web utiliza seu banco de dados de certificados raiz CA (Autoridade de Certificação) para alidar os clientes que acessam o seridor com certificados no lado do cliente. Ocorre o seguinte processo: 1. Um cliente SSL solicita uma conexão com um seridor Web por meio do plug-in. 2. Como resposta, o seridor Web enia sua chae pública utilizando um certificado assinado no lado do seridor. Esse certificado já foi assinado por uma CA confiáel de terceiros. 3. O cliente erifica se o emissor do certificado corresponde ao emissor confiáel que ele pode aceitar. O naegador do cliente geralmente contém uma lista de certificados raiz a partir de CAs confiáeis. Se a assinatura no certificado do seridor Web corresponder a um desses certificados raiz, o seridor será confiáel. 4. Se não houer correspondência para a assinatura, o naegador informará ao usuário que esse certificado foi emitido por uma autoridade de certificação desconhecida. Dessa forma, o usuário será responsáel por aceitar ou rejeitar esse certificado. 68 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

5. Se a assinatura corresponder a uma entrada no banco de dados de certificados raiz do naegador, as chaes de sessão serão negociadas com segurança entre o cliente e o seridor Web. O resultado final desse processo é um canal protegido pelo qual o cliente pode se autenticar (por exemplo, utilizando um nome de usuário e uma senha). Após a autenticação bem-sucedida, o cliente e o seridor podem continuar a se comunicar com segurança por esse canal. 6. Nesse ponto, o cliente enia seu certificado de chae pública atraés do plug-in para o seridor Web. 7. O seridor Web tenta corresponder a assinatura no certificado do cliente com uma CA conhecida utilizando seu armazenamento de certificados. 8. Se não houer correspondência para a assinatura, um código de erro SSL será gerado e eniado ao cliente. 9. Se houer uma correspondência para a assinatura, o cliente será confiáel. A autenticação do cliente é realizada, resultando em uma identidade do Tioli Access Manager. 10. As chaes de sessão são negociadas com segurança entre o cliente e o seridor Web. O resultado final desse processo é um canal de comunicação protegido e confiáel entre o cliente e o seridor mutuamente autenticados. Atiando a Autenticação com Base em Certificados A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a autenticação utilizando certificados, atribua a expressão cert ao parâmetro authentication: [common-modules] authentication = cert A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e o respectio nome da biblioteca compartilhada associada. Assegure-se de que a entrada para a autenticação com base em certificados esteja presente: [modules] cert = pdwpi-certificate-module Nota: Para instalações no IHS, é necessário configurar o seridor Web para solicitar certificados dos clientes. Configurando o Mecanismo de Autenticação com Base em Certificados O parâmetro cert-ssl especifica a biblioteca compartilhada para o mapeamento de informações de autenticação com base em certificados. No UNIX, o arquio que fornece a função de mapeamento interno é uma biblioteca compartilhada que se chama libpdwpi-sslauthn. No Windows, o arquio que fornece a função de mapeamento interno é uma DLL que se chama sslauthn. É possíel configurar o mecanismo de autenticação com base em certificados inserindo o parâmetro cert-ssl com o nome do arquio de biblioteca compartilhada específico para cada plataforma na sub-rotina [authentication-mechanisms] do arquio de configuração pdwebpi.conf. Solaris: Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 69

[authentication-mechanisms] cert-ssl= libpdwpi-sslauthn.so Windows: [authentication-mechanisms] cert-ssl = pdwpi-sslauthn.dll Nota: O CDAS pdwpi-sslauthn requer que o DN de assunto no certificado do usuário corresponda exatamente ao DN LDAP desse usuário. Se ocê precisar utilizar um mapeamento mais complicado, será necessário desenoler um CDAS personalizado. Consulte o documento IBM Tioli Access Manager for e-business Web Security: Referência para Desenoledores para obter instruções sobre como construir módulos CDAS. Essas instruções também se aplicam ao Plug-in para Web Serers. Configurando a Autenticação com Base em Token O Tioli Access Manager Plug-in para Web Serers suporta a autenticação com o uso de um código de acesso de token fornecido pelo cliente. Autenticação com Base em Token SecurID O processo de autenticação com base em token do plug-in requer que o cliente RSA SecurID, instalado e configurado no seridor em que o plug-in está instalado, comunique-se com um seridor RSA remoto. A ersão suportada do cliente SecurID é a ersão 5.1. RSA ACE/Serers autenticam ários tokens diferentes, incluindo tokens de software e dispositios controlados por multiprocessadores portáteis. Tokens de Software SecurID são programas binários executados em uma estação de trabalho, instalados em um smart-card ou executados como um plug-in para um naegador da Web. Esses tokens podem ser executados como um aplicatio. O aplicatio exibe uma janela na qual um usuário insere um PIN (Número de Identificação Pessoal), e o Token de Software calcula o código de acesso. Em seguida, o usuário pode se autenticar no plug-in inserindo o código de acesso em um formulário de login. A forma mais comum do Token SecurID é o dispositio portátil. Esse dispositio é normalmente um fob-chae ou um slim card. O token pode conter um PIN pad, no qual um usuário insere um PIN, de forma a gerar um código de acesso. Quando o token não contém um PIN pad, o código de acesso é criado por meio da concatenação do código de token e do PIN do usuário. Um código de token é um número em constante alteração exibido no fob-chae. O código de token é um número gerado pelo token SecurID em interalos de um minuto. Em seguida, um usuário insere o PIN e o código de token para se autenticar no ACE/Serer. O plug-in suporta os dois modos de token RSA: Modo Próximo Código de Token Esse modo é utilizado quando o usuário insere o PIN correto, mas um código de token incorreto. Normalmente, o código de token dee ser incorretamente inserido três ezes consecutias de forma a eniar o código de token para o modo Próximo Código de Token. Quando o usuário insere o código de acesso correto, o código de token é automaticamente alterado. O usuário aguarda o noo código de token e, em seguida, insere noamente o código de acesso. Modo Noo PIN 70 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

O token pode estar no modo Noo PIN quando o PIN antigo ainda está atribuído. O token é colocado nesse modo quando o administrador deseja impor um critério de duração máxima de senhas. O token também está no modo Noo PIN quando o PIN é apagado ou não foi atribuído. Tokens recém-atribuídos ainda podem não ter um PIN. Um PIN poderá ser apagado por um administrador se o usuário tier esquecido esse PIN ou se suspeitar que ele foi comprometido. PINs SecurID podem ser criados de diferentes maneiras: Definidos pelo usuário Gerados pelo sistema Selecionáeis pelo usuário Os modos de PINs são definidos pelo método de criação e por regras que especificam parâmetros para a criação de senhas e para o tipo de dispositio. O plug-in suporta os seguintes tipos de PINs definidos pelo usuário: 4 a 8 caracteres alfanuméricos, token não-pinpad 4 a 8 caracteres alfanuméricos, senha 5 a 7 caracteres numéricos, token não PINPAD 5 a 7 caracteres numéricos, token PINPAD 5 a 7 caracteres numéricos, Negar PIN de 4 dígitos 5 a 7 caracteres numéricos, Negar alfanuméricos O plug-in não suporta os seguintes tipos de noos PINs: Gerados pelo sistema, token não-pinpad Gerados pelo sistema, token PINPAD Selecionáeis pelo usuário, token não-pinpad Selecionáeis pelo usuário, token PINPAD Os usuários de tokens não podem redefinir seus PINs sem que um administrador do ACE apague primeiramente o token ou coloque-o no modo Noo PIN. Isso significa que usuários com PINs álidos não podem fazer lançamentos no formulário pkmspassword.form. As tentatias de acessar esse formulário retornarão uma mensagem de erro. Workflow de Autenticação para Tokens no Modo Noo PIN O processo a seguir ocorre para a autenticação de tokens no modo Noo PIN: 1. Um cliente (naegador) solicita um objeto da Web protegido que requer a autenticação com base em token. 2. O plug-in retorna uma página de autenticação, solicitando o nome do usuário e o código de acesso. 3. O usuário preenche o nome do usuário e o código de token e submete o formulário à biblioteca de autenticação do plug-in. Quando o usuário não possui um PIN, porque o tokencard é noo ou porque o administrador redefiniu o PIN, o código de token é igual ao código de acesso. Quando o usuário possui um PIN, mas o tokencard está no modo Noo PIN, esse usuário insere o PIN e o código de token. 4. A biblioteca de autenticação com base em token do plug-in enia o pedido de autenticação ao ACE/Serer. 5. O ACE/Serer processa esse pedido da seguinte maneira: Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 71

a. Se a autenticação não for bem-sucedida, o resultado será retornado à biblioteca de autenticação com base em token do plug-in, que exibirá uma página de erro ao cliente (retornar à etapa 2). b. Se o token não estaa no modo Noo PIN, o usuário será autenticado. A biblioteca de autenticação com base em token do plug-in retornará uma mensagem de êxito ao plug-in, que atenderá ao objeto da Web protegido solicitado. (Fim do workflow de autenticação). c. Se o token estier no modo Noo PIN, o ACE/Serer retornará o código de erro NEW_PIN à biblioteca de autenticação com base em token do plug-in. 6. O plug-in apresenta ao usuário o formulário de senha expirada. 7. O usuário insere o código de token ou o código de acesso e o noo PIN. Em seguida, lança esses dados para o plug-in. 8. O plug-in erifica se um seridor de intensificação de senha está implementado. a. Se um seridor de intensificação de senha não estier implementado, o plug-in continuará até a etapa 9. b. Se um seridor de intensificação de senha estier implementado, o plug-in erificará o noo PIN. Se o PIN for álido, o plug-in continuará até a etapa 9. Se não for álido, o plug-in retornará à etapa 6. 9. A biblioteca de autenticação do plug-in enia o código de token e o noo PIN ao ACE/Serer. 10. O ACE/Serer retorna um código de resposta. 11. Se a chamada de definição do PIN para o ACE/Serer for bem-sucedida, o plug-in retornará ao cliente o objeto da Web protegido originalmente solicitado. Se a chamada de definição do PIN apresentar uma falha, o workflow de autenticação retornará à etapa 6. Utilizando a Autenticação com Base em Token com um Seridor de Intensificação de Senha O plug-in também suporta um seridor de intensificação de senha específico para um mecanismo de autenticação. Esse suporte permite que arquitetos de segurança desenolam diferentes critérios de intensificação de senha para métodos de autenticação distintos e, ao mesmo tempo, utilizem apenas os mecanismos de autenticação do plug-in. Um PIN numérico de quatro dígitos, por exemplo, pode estar qualificado para o ACE/Serer, mas não seria bem-sucedido em um seridor de intensificação de senha mais rigoroso. Atiando a Autenticação com Base em Token A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a autenticação utilizando tokens, atribua a expressão token ao parâmetro authentication. Quando a autenticação com o uso de tokens está atiada, também é necessário configurar tokens para o processamento pós-autorização. Na sub-rotina [common-modules] do arquio de configuração, construa um parâmetro post-authzn e atribua-o com o alor token. A sub-rotina [common-modules] dee incluir estas duas entradas: [common-modules] authentication = token post-authzn = token 72 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e o respectio nome da biblioteca compartilhada associada. Assegure-se de que a entrada para a autenticação com base em token esteja presente: [modules] token = pdwpi-token-module Configurando o Mecanismo de Autenticação com Base em Token O parâmetro token-cdas especifica a biblioteca compartilhada para o mapeamento de informações de autenticação com base em código de acesso de token. No UNIX, o arquio que fornece a função de mapeamento interno é uma biblioteca compartilhada que se chama libxtokenauthn. No Windows, o arquio que fornece a função de mapeamento interno é uma DLL que se chama xtokenauthn. A biblioteca compartilhada de tokens é instalada como parte do pacote PDWebRTE (Tioli Access Manager Web Security Runtime). A localização dessa biblioteca compartilhada é: UNIX /opt/pdwebrte/lib Windows c:\arquios de programas\tioli\pdwebrte\bin Por padrão, essa biblioteca interna compartilhada é codificada em código permanente de forma a mapear dados de código de acesso do token SecureID. Você pode personalizar esse arquio de forma a autenticar outros tipos de dados de token especiais e, como opção, mapear esses dados para uma identidade do Tioli Access Manager. Consulte o documento IBM Tioli Access Manager for e-business Web Security: Referência para Desenoledores para conhecer recursos de APIs. É possíel configurar o mecanismo de autenticação com base em token inserindo o parâmetro token-cdas com o nome do arquio de biblioteca compartilhada específico para cada plataforma na sub-rotina [authentication-mechanisms] do arquio de configuração pdwebpi.conf. Por exemplo: Solaris: [authentication-mechanisms] token-cdas = libxtokenauthn.so Windows: [authentication-mechanisms] token-cdas = xtokenauthn.dll Personalizando Páginas de Resposta de Tokens O parâmetro token-login-form na sub-rotina [token-card] do arquio de configuração define o nome do arquio do formulário apresentado ao cliente do usuário durante um logon com base em token. O caminho do arquio dee ser relatio ao diretório HTML traduzido do plug-in (por exemplo, Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 73

pdwebpi/nls/html/lang/charset). Em que lang é obtido a partir da configuração do NLS. Em sistemas no idioma inglês (EUA), o diretório lang é chamado de C e charset corresponde a utf-8. O parâmetro next-token-form na sub-rotina [token-card] define o formulário exibido ao cliente do usuário para solicitar o próximo token. O cliente é solicitado a inserir outro token quando o seridor não consegue autenticar o usuário com êxito a partir do primeiro token. A incapacidade de autenticar o usuário pode ser causada por ários motios. Entretanto, é mais comum que esse erro ocorra porque os clocks do cliente e do seridor não estão sincronizados. Quando a autenticação não é realizada com êxito utilizando o primeiro token, a página especificada no parâmetro next-token-form é exibida de forma a solicitar o próximo token. A sub-rotina token-card possui o seguinte formato: [token-card] token-login-form = tokenlogin.html next-token-form = nexttoken.html Configurando a Autenticação SPNEGO A autenticação SPNEGO fornece uma capacidade SSO (Conexão Única) para contas de usuários do Windows quando objetos protegidos são acessados com o uso do Internet Explorer. Com a autenticação SPNEGO, o plug-in executa o lado do seridor da negociação, enquanto o Internet Explorer executa o lado do cliente. Quando um usuário solicita acesso a um seridor Web protegido, o Internet Explorer utiliza as credenciais de login do Windows desse usuário para participar de uma negociação com o seridor Web de forma a proar a autenticidade do usuário. Depois que o seridor confirmar a identidade do usuário, o acesso será concedido se: o usuário for membro do domínio, o SPNEGO tier sido atiado no Authorization Serer, O Authorization Serer permitir o acesso. Os usuários que acessarem recursos protegidos pela autenticação SPNEGO do plug-in e que não forem membros do domínio ou que estierem utilizando naegadores diferentes do Internet Explorer deerão se autenticar utilizando outro método, por exemplo, a Autenticação Básica ou a autenticação com base em formulários. Nota: A funcionalidade do módulo de autenticação SPNEGO somente poderá operar corretamente se o seridor Web estier configurado para permitir acesso anônimo. No caso do IIS, a opção Integrated Login (Login Integrado) dee estar desmarcada e a opção Anonymous Access (Acesso Anônimo) dee estar marcada. No caso de outros seridores Web, a configuração padrão dee ser utilizada. Suporte para Plataformas e Registros de Usuários O mecanismo de autenticação SPNEGO está disponíel em todas as combinações suportadas de seridor Web/plataforma/registro de usuários. Quando o Actie Directory não é o registro de usuários do Tioli Access Manager, os usuários deem ser replicados entre o registro do Actie Directory e o registro de usuários do Access Manager. 74 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Fazendo o Upgrade da Configuração do SPNEGO a partir da Versão 4.1 para a Versão 5.1 O Tioli Access Manager Plug in para Web Serers ersão 4.1 fornecia o módulo spnego. Na ersão 5.1 do plug-in, a funcionalidade desse módulo foi incorporada em três módulos separados: spnego, ntlm e web-serer-authn. Não existe um processo automático para moer a configuração do SPNEGO a partir da ersão 4.1 para a ersão 5.1 será necessário fazer a reconfiguração manualmente. A tabela a seguir mostra as definições de configuração equialentes da ersão 5.1 com relação às definições de configuração da ersão 4.1. Existem duas situações: Com o parâmetro web-serer-does-authn na sub-rotina [spnego] do arquio de configuração da ersão 4.1 definido como true. Com o parâmetro web-serer-does-authn na sub-rotina [spnego] do arquio de configuração da ersão 4.1 definido como false. Tabela 12. Configuração do SPNEGO Equialente entre a Versão 4.1 e a Versão 5.1. Plug-in Versão 4.1 Plug-in Versão 5.1 [common-modules] authentication = spnego authentication = BA session = spnego session = session-cookie [spnego] web-serer-does-authn = true [common-modules] authentication = spnego authentication = BA session = spnego session = session-cookie [spnego] web-serer-does-authn = false [common-modules] authentication = web-serer-authn session = session-cookie Consulte Configurando a Autenticação com Base em Seridor Web (Somente para Plataformas IIS) na página 83 para obter opções de configuração adicionais. [common-modules] authentication = spnego authentication = ntlm authentication = BA session = session-cookie Consulte Configurando a Autenticação NTLM (Somente para Plataformas IIS) na página 82 para obter opções de configuração adicionais. Limitações Os seguintes recursos do plug-in não são suportados com a autenticação SPNEGO: Reautenticação com base em cronômetro de sessão ou POP de clientes SPNEGO autenticados. Alteração de senhas com o uso de pkmspasswd para registros de usuários que não sejam o Actie Directory. Mapeamento de um nome de usuário por meio de um CDAS. Os clientes SPNEGO não podem efetuar logout a partir do plug-in. Eles deem efetuar logout a partir da estação de trabalho. Os clientes que acessam páginas de comandos pkms do plug-in (com exceção da função Comutação de Usuários) recebem a página de ajuda PKMS. Reautenticação quando o cronômetro de sessão inatia expira para os clientes SPNEGO. A entrada do cache de usuários é excluída, mas o ID da sessão é mantido. As informações no cabeçalho recebido do cliente SPNEGO são Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 75

utilizadas para reautenticação. O cliente não precisa efetuar login noamente, mas recebe uma noa entrada de cache de sessão. Reautenticação quando um usuário acessa um objeto com um critério de reautenticação anexado. Nesse caso, o acesso é negado, e o usuário recebe uma mensagem informando que a reautenticação é necessária. Configuração da Conexão Única de Desktops Windows Esta seção contém as etapas de configuração que deem ser concluídas para implementar a conexão única de desktops Windows utilizando a autenticação SPNEGO com o plug-in. Nem todas as etapas são necessárias em cada plataforma. Para configurar a autenticação SPNEGO, conclua cada uma das etapas a seguir: Etapa 1: Configure o Seridor de Plug-in para o Domínio do Actie Directory Para participar de um intercâmbio do Kerberos com o Internet Explorer, o seridor de plug-in dee ter uma identidade no domínio Kerberos do Actie Directory. Isso exige que o plug-in esteja registrado no controlador de domínio do Actie Directory. Dessa forma, o naegador Internet Explorer pode utilizar a credencial de login do Windows do usuário para acessar o seridor aprimorado pelo plug-in. Consulte a documentação da Microsoft para obter instruções sobre como adicionar uma identidade para o host do seridor de plug-in a um domínio do Actie Directory. Notas: 1. No Windows, o seridor de plug-in padrão (a primeira instância do seridor) utiliza a identidade da Conta de Seriço Local ao entrar em contato com o controlador de domínio do Actie Directory. 2. No UNIX, assegure-se de que o nome do usuário corresponda ao nome do host do seridor de plug-in. Não utilize o nome de domínio completo. Por exemplo, para o sistema diamond.subnet2.ibm.com, crie um usuário diamond. Não exija que o usuário altere a senha no login seguinte. Não defina uma expiração para a senha. Etapa 2: Faça o Mapeamento do Proprietário do Kerberos para o Usuário do Actie Directory O pedido do cliente Internet Explorer para o controlador de domínio do Actie Directory solicita acesso a um proprietário do Kerberos com o nome: HTTP/DNS_name_of_plug-in_serer@Actie_Directory_domain_name Esse nome dee ser mapeado para o usuário do Actie Directory que representa a instância do seridor aprimorado pelo plug-in que foi criada na Etapa 1. Esse mapeamento requer o utilitário ktpass do Windows. Por padrão, o utilitário ktpass não pode ser carregado no sistema Windows. Ele pode ser obtido a partir do pacote de Ferramentas de Suporte do Windows, localizado nos CDs do Windows. Windows: Registre o nome principal do seriço para o seridor de plug-in. No controlador de domínio do Actie Directory, execute o comando ktpass. Por exemplo, quando o host do plug-in for diamond.subnet2.ibm.com e o domínio do Actie Directory for IBM.COM, o comando será: ktpass -princ HTTP/diamond.subnet2.ibm.com@IBM.COM -mapuser diamond UNIX: Conclua as seguintes etapas: 76 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

1. Em sistemas UNIX, além do mapeamento do usuário, é necessário criar um arquio de teclas para uso durante a conexão com o domínio do Kerberos. A sintaxe é (inserida como uma linha): ktpass -princ HTTP/DNS_name_of_WebPI_serer@Actie_Directory_domain_name -pass your_password -mapuser WebPI_serer_instance -out full_path_to_keytab_file -mapop set A identidade do usuário especificada pela opção -mapuser no comando acima corresponde ao usuário do Actie Directory. A senha especificada aqui redefine a senha para esse usuário do Actie Directory. Coném utilizar uma senha altamente segura, como uma senha gerada aleatoriamente. A localização do arquio de teclas é arbitrária. Mantenha essa senha de forma a utilizá-la em uma etapa posterior para testar a configuração do Kerberos (ao testar a autenticação a partir de uma máquina UNIX no Centro de Distribuição de Chaes do Actie Directory). 2. Transfira o arquio de teclas para o sistema UNIX. Assegure-se de que um método de transferência seguro seja utilizado. A localização recomendada é: /opt/pdwebpi/etc/key_tab_filename 3. Para a melhor prática de segurança, exclua o arquio de teclas do sistema Windows. 4. No sistema UNIX, atribua a propriedade do arquio a pdwebpi e restrinja as permissões sobre o arquio de teclas de forma que apenas o proprietário possa acessá-lo. Por exemplo: # chown pdwebpi keytab_file # chgrp pdwebpi keytab_file # chmod 600 keytab_file 5. Para seridores UNIX, repita as etapas anteriores para cada instância do plug-in. Etapa 3: Instale o Kerberos Runtime Client (Somente para UNIX) O seridor no qual o plug-in está instalado também dee ter o Kerberos Runtime instalado. Em sistemas Windows, o Kerberos Runtime Client faz parte do sistema operacional. Nenhum pacote adicional é necessário. Em sistemas UNIX, instale o pacote apropriado: AIX IBM Network Authentication Serice Client. Esse cliente pode ser encontrado no pacote de expansão do AIX. Solaris IBM Network Authentication Serice Client. Esse cliente está incluído no CD do Tioli Access Manager Web Security. Utilize pkgadd para fazer a instalação. SUN Kerberos Client SUNWkr5cl. Necessário para o IBM Network Authentication Serice Client. Esse pacote faz parte do pacote SEAM e pode ser transferido por download a partir do site da Sun na Web. Linux MIT Kerberos 1.2.5 Etapa 4: Configure o Kerberos Client (Somente para UNIX) O Kerberos Client instalado na etapa anterior dee ser configurado. Isso requer a criação ou a modificação de um arquio de configuração do Kerberos. No Solaris e Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 77

no AIX, esse arquio é /etc/krb5/krb5.conf e, no Linux, /etc/krb5.conf. Siga as instruções que se aplicam ao seu sistema operacional: AIX Use o utilitário mkkrb5clnt. Esse utilitário cria e preenche o arquio /etc/krb5/krb5.conf. 1. Execute mkkrb5clnt. A sintaxe é: mkkrb5clnt -r Actie_Directory_domain -c Actie_Directory_controller_DNS -s Actie_Directory_controller_DNS -d local_dns_domain Por exemplo: mkkrb5clnt -r IBM.COM -c dc1.ibm.com -s dc1.ibm.com -d dns.com 2. Edite krb5.conf manualmente para remoer qualquer definição criptográfica não suportada pelo Actie Directory. [libdefaults] default_tkt_enctypes = des-cbc-md5 des-cbc-crc default_tgs_enctypes = des-cbc-md5 des-cbc-crc Essa etapa remoe des3-cbc-sha1. Solaris e Linux Edite krb5.conf manualmente. Personalize as seguintes informações para o seu domínio: Região. Por exemplo: IBM.COM Nome do seridor do controlador do Actie Directory. Por exemplo, dc1. Nome de domínio. Por exemplo, ibm.com. Nome DNS. Por exemplo, ibm.com. Com o uso dos alores de exemplo acima, o conteúdo do arquio de configuração do Kerberos incluiria as seguintes entradas: Uma lista parcial de krb5.conf: [libdefaults] default_realm = IBM.COM default_tkt_enctypes = des-cbc-md5 des-cbc-crc default_tgs_enctypes = des-cbc-md5 des-cbc-crc [realms] IBM.COM = { kdc = dc1.ibm.com:88 admin_serer = dc1.ibm.com:749 default_domain = ibm.com } [domain_realm] dc1.ibm.com = IBM.COM.ibm.com = IBM.COM A última linha no arquio de exemplo acima (.ibm.com = IBM.COM) representa o domínio DNS no qual opera o seridor aprimorado pelo plug-in e com o qual o usuário estabelece uma conexão. Obsere o ponto (.) na frente do domínio IBM, na última linha. Ele age como um caractere coringa para todos os subdomínios e hosts no domínio ibm.com. 78 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Nota: No United Linux, que utiliza uma ersão do Kerberos chamada Heimdal, talez seja necessário adicionar as seguintes linhas à sub-rotina [libdefaults] para facilitar os testes. [libdefaults] default_etypes = des-cbc-md5 des-cbc-crc default_etypes_des = des-cbc-md5 des-cbc-crc Etapa 5: Verifique a Autenticação do Proprietário do Seridor Web (Somente para UNIX) Utilize o programa kinit para erificar se o proprietário do Kerberos para o seridor aprimorado pelo plug-in pode fazer a autenticação. Utilize a senha especificada quando o comando ktpass foi executado na Etapa 2: # /usr/krb5/bin/kinit diamond@ibm.com Password for diamond@ibm.com: serer_password # klist Alguma saída a partir de klist dee ser isualizada, mostrando as credenciais para diamond@ibm.com Nota: A localização do utilitário kinit poderá ariar dependendo da plataforma do sistema operacional. Etapa 6: Verifique a Autenticação do Plug-in Utilizando o Arquio de Teclas (Somente para UNIX) Verifique se o plug-in pode se autenticar utilizando o arquio de teclas criado na Etapa 2. Insira o comando kinit a seguir como uma linha contínua: # kinit -k -t /ar/pdweb/keytab-diamond/diamond_http.keytab HTTP/diamond.subnet2.ibm.com@IBM.COM # klist Alguma saída a partir de klist dee ser isualizada, mostrando as credenciais para HTTP/diamond.subnet2.ibm.com@IBM.COM Etapa 7: Atiando a Autenticação SPENGO no Plug-in Para atiar a autenticação SPNEGO no plug-in: 1. Atribua o alor spnego aos parâmetros de autenticação na sub-rotina [common-modules] do arquio de configuração do plug-in, pdwebpi.conf. [common-modules] authentication = spnego 2. Na sub-rotina [authentication-mechanisms], defina o parâmetro kerberos5 como o caminho absoluto da biblioteca compartilhada stli (Security Translation Layer Interface). Por exemplo: AIX: kerberos5 = /opt/policydirector/lib/libstliauthn.a Outro UNIX: kerberos5 = /opt/policydirector/lib/libstliauthn.so Windows: kerberos5 = C:\PROGRA~1\Tioli\POLICY~1\bin\stliauthn.dll 3. Na sub-rotina [spnego], defina: spnego-krb-serice-name como HTTP ou HTTP@fully_qualified_host_domain_name. spnego-krb5-keytab-file como o nome completo do caminho do arquio de teclas que dee ser utilizado pelo plug-in. Esse alor é apenas necessário em plataformas UNIX. Em plataformas Windows, essa opção é ignorada. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 79

Etapa 8: Atiando a Autenticação SPENGO no Seridor Web Para atiar o SPNEGO para o IIS, assegure-se de que o critério de acesso do seridor Web definido na guia Directory Security (Segurança de Diretórios) esteja definido como anonymous. Para outros seridores Web, a configuração padrão é aceitáel. Para atiar o SPNEGO no cliente Internet Explorer: 1. Se o plug-in estier instalado no UNIX, configure a zona Intranet Local de forma a incluir o nome do seridor UNIX: a. Selecione Ferramentas Opções da Internet. b. Na guia Segurança, selecione Intranet Local Sites Aançado ou Sites Confiáeis Sites. c. Informe o seridor UNIX no qual o plug-in está em execução. 2. Configure o comportamento de login integrado: a. Selecione Ferramentas Opções da Internet. b. Na guia Segurança, clique em Níel Personalizado. c. Role para baixo até a seção Logon do diálogo Configurações de Segurança e selecione Automático... ou Aisar..., dependendo da funcionalidade exigida. Nota: Se a opção Sites Confiáeis tier sido selecionada na etapa 1 acima, o usuário nunca será solicitado a inserir informações sobre nome de usuário e senha. 3. Se o cliente corresponder à ersão 6 do Internet Explorer, será necessário configurar o login integrado do Windows. Para fazer isso: a. Selecione Ferramentas Opções da Internet. b. Na guia Aançado, marque a opção Atiar Login Integrado do Windows. c. Inicie noamente o naegador para que a alteração seja efetiada. Dicas de Resolução de Problemas Configuração do Kerberos Problema: Ao testar o arquio de teclas criado para um seridor UNIX utilizando o kinit, o erro Clock skew too great while getting initial credentials é retornado. Solução: É necessário manter os clocks sincronizados ao utilizar o Kerberos. Para uma solução permanente, implemente o mesmo tipo de seriço de sincronização de horário em todas as máquinas. Para uma solução temporária, acerte os clocks nas máquinas de forma que o interalo entre cada clock seja de um minuto. Problema: Ao testar o arquio de teclas criado para um seridor UNIX utilizando kinit, o erro Preauthentication failed while getting initial credentials ou Password incorrect while getting initial credentials é retornado. Solução: A chae no arquio de teclas está incorreta. Certifique-se de ter gerado o arquio de teclas corretamente, com o nome principal, o nome do usuário do Actie Directory e o caminho corretos. Problema: O kinit apresenta uma falha ao executar o kinit -k -t Solução: Algumas ersões do kinit não lidam corretamente com problemas quando uma entrada não é encontrada em um arquio de teclas. Verifique se o arquio de teclas possui exatamente a mesma entrada que ocê está transmitindo ao kinit. Configuração do Tioli Access Manager Plug-in para Web Serers 80 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Quando ocorrer um problema, considere a atiação do rastreio para o SPNEGO. Adicione uma entrada ao arquio de roteamento. Esse arquio de roteamento está localizado no diretório de instalação, em etc/routing. Exemplo de entrada: bst:*.9:textfile:install_path/log/spnegotrace.log No UNIX, o diretório de instalação padrão do plug-in é /opt/pdwebpi. Substitua o caminho para esse diretório de instalação. Pare e inicie noamente o plug-in. Procure mensagens de erro no arquio de rastreio. Problema: O seridor de plug-in não é iniciado. O arquio de log contém um erro que afirma Authentication method (kerberos5) is not configured. Solução: Atie o método de autenticação kerberos5 na sub-rotina [authentication-mechanisms] do arquio de configuração do plug-in. Problema: O plug-in não é iniciado. A mensagem de erro é The security serice function gss_import_name returned major error code 131072 and minor error code -1765328168. Solução: O nome principal especificado no arquio de configuração era inálido. Seu formato dee ser HTTP@host_name, em que host_name corresponde ao nome DNS completo de um computador configurado na região do Kerberos. Problema: O seridor de plug-in não é iniciado. A mensagem de erro é: The security serice function gss_acquire_cred returned major error code 851968 and minor error code 39756033. Solução: O nome principal no arquio de configuração não corresponde a nenhuma das chaes no arquio de teclas especificado. As chaes no arquio de teclas possuem nomes como HTTP/host_name@REALM. O nome principal dee ter o formato HTTP@host_name Problema: Quando um usuário tenta acessar o plug-in, é retornado um erro que afirma HPDIA0100E An internal error has occurred. O arquio de log de rastreio do plug-in contém uma mensagem que afirma The security serice function gss_accept_sec_context returned major error code 851968 and minor error code -1765328347. Solução: O clock do sistema na máquina do cliente está fora de sincronização com o clock do sistema no seridor de plug-in. É necessário manter os clocks sincronizados ao utilizar o Kerberos. Para uma solução permanente, implemente um seriço de sincronização de horário nas máquinas. Para uma solução temporária, acerte os clocks nas máquinas de forma que o interalo entre cada clock seja de um minuto. Outros itens de configuração a serem erificados quando ocorrerem problemas Verifique se as permissões de arquio e a propriedade do arquio de teclas permitem o acesso pelo Authorization Serer do plug-in, conforme mencionado na Etapa 2: Faça o Mapeamento do Proprietário do Kerberos para o Usuário do Actie Directory na página 76. Verifique se o arquio de teclas contém chaes e dados álidos para o nome principal correto usando o utilitário ktutil para exibir as informações contidas nesse arquio de teclas. Verifique se a configuração do DNS para o domínio inteiro (controlador de domínio e clientes) está correta e se os nomes estão corretamente resolidos e correspondentes aos alores nos itens de configuração do nome principal do seriço em árias localizações (arquio de teclas, arquio de configuração do plug-in, etc.). Verifique se os clocks do sistema estão sincronizados e se um seriço de horário distribuído está mantendo a sincronização de clocks em todos os sistemas do domínio. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 81

Verifique se a configuração da rede está correta e se existem problemas como tráfego, roteamento incorreto, colisão de nomes e assim por diante. Assegure-se de que a latência esteja dentro de limites toleráeis. Certifique-se de que os firewalls, o NAT e outros seriços de segurança de rede não interfiram na operação do domínio. Configurando a Autenticação NTLM (Somente para Plataformas IIS) As ersões existentes da plataforma Windows forneciam um mecanismo básico de SSO (Conexão Única) conhecido como autenticação NTLM (NT Lan Manager). Esse método de autenticação tem como base algoritmos de sinais numéricos que fornecem um níel semelhante de segurança e de operação em comparação ao níel da Autenticação Básica. O plug-in suporta a autenticação NTLM para facilitar a compatibilidade de ersões anteriores entre plataformas Windows modernas (XP, 2000) e sistemas mais antigos, como o Windows NT. O plug-in suporta o NTLM apenas na plataforma Windows IIS. Não existe suporte para plataformas UNIX. Para atiar a autenticação NTLM, atribua o alor ntlm ao parâmetro authentication na sub-rotina [common-modules] do arquio de configuração do plug-in, pdwebpi.conf. [common-modules] authentication = ntlm Para atiar a autenticação NTLM, assegure-se de que o critério de acesso do IIS Web Serer esteja definido como anonymous. Para configurar o Internet Explorer para participação em intercâmbios do NTLM (e do SPNEGO): 1. Configure o comportamento de login integrado: a. Selecione Ferramentas Opções da Internet. b. Na guia Segurança, clique em Níel Personalizado. c. Role para baixo até a seção Logon do diálogo Configurações de Segurança e selecione Automático... ou Aisar..., dependendo da funcionalidade exigida. Nota: Se a opção Sites Confiáeis tier sido selecionada na etapa 1 acima, o usuário nunca será solicitado a inserir informações sobre nome de usuário e senha. 2. Se o cliente corresponder à ersão 6 do Internet Explorer, será necessário configurar o login integrado do Windows. Para fazer isso: a. Selecione Ferramentas Opções da Internet. b. Na guia Aançado, marque a opção Atiar Login Integrado do Windows. c. Inicie noamente o naegador para que a alteração seja efetiada. O parâmetro use-pre-windows-2000-logon-name na sub-rotina [ntlm] do arquio de configuração do plug-in pode ser utilizado para configurar formatos de nome de usuário Windows 2000 ou pré-windows 2000. Por padrão, o módulo ntlm utiliza o nome de logon do Windows 2000 para representar o usuário autenticado no Tioli Access Manager. Isso corresponde à parte username do nome de logon username@domain.com. O parâmetro use-pre-windows-2000-logon-name permite que o nome de logon pré-windows represente o usuário autenticado no Tioli Access Manager. Isso corresponde à parte username do nome de logon DOMAIN\USERNAME. Esse parâmetro será ignorado se o Tioli Access Manager utilizar o Actie Directory como o registro de usuários. Com o Actie Directory, o 82 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

nome do usuário do Tioli Access Manager sempre corresponderá à parte username do nome de logon username@domain.com. Configurando a Autenticação com Base em Seridor Web (Somente para Plataformas IIS) Alguns seridores Web oferecem a capacidade de realizar a autenticação natiamente. Um exemplo disso é a capacidade do IIS de executar o Login Integrado do Windows (SPNEGO, NTLM ou BA). O plug-in pode ser configurado para utilizar essa autenticação natia com base em seridor Web, confiando que esse seridor Web executou adequadamente as erificações de autenticação segura. No momento, a autenticação atual com base em seridor Web para o plug-in apenas é suportada no IIS. Para atiar a autenticação com base em seridor Web no plug-in, atribua o alor web_sr_authn ao parâmetro authentication na sub-rotina [common-modules] do arquio de configuração do plug-in, pdwebpi.conf. [common-modules] authentication = web_sr_authn Para configurar o Internet Explorer para participação em intercâmbios do NTLM (e do SPNEGO): 1. Configure o comportamento de login integrado: a. Selecione Ferramentas Opções da Internet. b. Na guia Segurança, clique em Níel Personalizado. c. Role para baixo até a seção Logon do diálogo Configurações de Segurança e selecione Automático... ou Aisar..., dependendo da funcionalidade exigida. Nota: Se a opção Sites Confiáeis tier sido selecionada na etapa 1 acima, o usuário nunca será solicitado a inserir informações sobre nome de usuário e senha. 2. Se o cliente corresponder à ersão 6 do Internet Explorer, será necessário configurar o login integrado do Windows. Para fazer isso: a. Selecione Ferramentas Opções da Internet. b. Na guia Aançado, marque a opção Atiar Login Integrado do Windows. c. Inicie noamente o computador para que a alteração seja efetiada. O módulo de autenticação web-serer-authn pode ser configurado para utilizar formatos de nome de usuário Windows 2000 ou pré-windows 2000 por meio da definição do parâmetro use-pre-windows-2000-logon-name no arquio de configuração do plug-in, na sub-rotina [web-serer-authn]. Por padrão, o módulo web-serer-authn utiliza o nome de logon do Windows 2000 para representar o usuário autenticado no Tioli Access Manager. Isso corresponde à parte username do nome de logon username@domain.com. O parâmetro use-pre-windows-2000-logon-name permite que o nome de logon pré-windows represente o usuário autenticado no Tioli Access Manager. Isso corresponde à parte username do nome de logon DOMAIN\USERNAME. Esse parâmetro será ignorado se o Tioli Access Manager utilizar o Actie Directory como o registro de usuários. Com o Actie Directory, o nome do usuário do Tioli Access Manager sempre corresponderá à parte username do nome de logon username@domain.com. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 83

Configurando a Autenticação com Base em Failoer Esta seção contém os seguintes tópicos: Conceitos da Autenticação com Base em Failoer Configuração da Autenticação com Base em Failoer na página 91 Conceitos da Autenticação com Base em Failoer O plug-in fornece um método de autenticação que permite a preseração de uma sessão autenticada entre um cliente e um seridor Web aprimorado pelo plug-in quando este último se torna indisponíel. Esse método é chamado de autenticação com base em failoer. A autenticação com base em failoer permite que o cliente se conecte a outro seridor Web aprimorado pelo plug-in e crie uma sessão de autenticação contendo os mesmos dados de sessão e as mesmas credenciais do usuário. O recurso de cookies de failoer é normalmente utilizado para clientes que se conectam a um seridor Web front-end replicado por meio de um mecanismo de equilíbrio de carga. Um cookie de failoer preine a reautenticação forçada quando a sessão original entre o seridor e o cliente se torna indisponíel. Com cookies de failoer configurados para o processamento pós-autorização, o plug-in criptografa os dados de credenciais em um cookie específico para o seridor ou para o domínio inteiro. Esse cookie é colocado no naegador no momento em que o cliente se conecta pela primeira ez. Se a sessão inicial do seridor Web for perdida, o cookie será apresentado ao próximo seridor para o qual o cliente for redirecionado. Esse cookie será utilizado para reautenticação automático de forma que o cliente não precise executar manualmente a tarefa de reautenticação. Os plug-ins em seridores replicados compartilham uma chae comum que decriptografa as informações de credenciais contidas no cookie e estabelece uma noa sessão. Figura 5. Arquitetura de Seridor Comum para Cookies de Failoer. 84 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

O diagrama acima mostra uma arquitetura comum que poderia se beneficiar do uso de cookies de failoer. Três instâncias idênticas do mesmo seridor Web estão localizadas atrás de um seridor de equilíbrio de carga que direciona pedidos a um desses três seridores, dependendo da carga e da disponibilidade. Por exemplo, suponha que cada instância de www.ibm.com esteja configurada para autenticar acessos de clientes com o uso de cookies de failoer e também para utilizar cookies de failoer no processamento pós-autorização. Um cliente acessa www.ibm.com e é direcionado à instância 1 do seridor, sendo autenticado com êxito. A credencial desse cliente é criptografada e armazenada em um cookie para o domínio inteiro que, por sua ez, é armazenado no naegador do cliente. Se, durante a sessão, o cliente precisar acessar a instância 2 ou 3 de www.ibm.com (por exemplo, se ocorrer uma falha na instância 1 ou se a demanda ficar muito grande), o cookie de failoer armazenado no naegador do cliente será utilizado para reautenticação automática sem a necessidade de interenção do usuário. A hora de início da sessão original é mantida com o cookie de forma que a integridade da duração dessa sessão permaneça álida quando ocorrer o redirecionamento automático para um seridor de failoer. Cenário da Autenticação com Base em Failoer Como parte da capacidade de failoer, o plug-in suporta a autenticação de usuários com o uso do cookie de failoer. Esse cookie de failoer é um cookie específico para um seridor ou para um domínio. O cookie de failoer contém dados específicos do cliente, como o nome do usuário, a data e a hora de criação do cookie, o método de autenticação original e uma lista de atributos. A lista de atributos contém, por padrão, o níel de autenticação do usuário. O plug-in pode ser configurado para adicionar atributos estendidos específicos à lista de atributos. O plug-in criptografa esses dados específicos do cliente. Os seridores Web replicados aprimorados pelo plug-in compartilham uma chae comum que decriptografa as informações do cookie. Ao receber esse cookie, o seridor de plug-in replicado o decriptografa e utiliza o nome do usuário e o método de autenticação para regenerar a credencial do cliente. O plug-in também pode ser configurado para copiar qualquer atributo estendido do cookie para a credencial do usuário. Nesse ponto, o cliente pode estabelecer uma noa sessão com um seridor réplica aprimorado pelo plug-in sem ser solicitado a efetuar login. Nota: Cookies de failoer podem ser utilizados ia HTTP ou HTTPS. A seqüência de eentos para um eento de autenticação com base em failoer é: 1. O cliente (naegador) tenta acessar um recurso protegido. O pedido do cliente chega a um recurso de equilíbrio de carga que controla o acesso aos seridores replicados. 2. O recurso de equilíbrio de carga seleciona um seridor de destino e encaminha o pedido do usuário. 3. O cliente é autenticado com êxito no seridor por meio do plug-in utilizando um dos métodos de autenticação suportados. 4. O plug-in cria um cookie de autenticação com base em failoer que contém informações de autenticação do cliente e enia o cookie para esse cliente. 5. O cliente enia o cookie por meio do recurso de equilíbrio de para o plug-in com cada pedido subseqüente. O plug-in processa cada pedido. 6. Se o recurso de equilíbrio de carga detectar que o seridor aprimorado pelo plug-in não está acessíel, o pedido do cliente será direcionado a outro seridor replicado aprimorado pelo plug-in. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 85

7. O plug-in no seridor replicado é configurado para erificar a existência de um cookie de autenticação com base em failoer sempre que ele tenta autenticar um usuário. 8. O plug-in utiliza as informações no cookie para estabelecer uma sessão com o cliente, sem exigir que esse cliente efetue um noo login manualmente. Os dados da sessão do cliente e a credencial do usuário são construídos, e o pedido para o recurso protegido é processado. 9. A alteração de sessão entre dois seridores aprimorados pelo plug-in é transparente para o cliente. Como os seridores aprimorados pelo plug-in contêm recursos idênticos, a sessão do cliente continua sem interrupções. Biblioteca de Autenticação com Base em Failoer O plug-in fornece uma biblioteca interna compartilhada de autenticação com base em failoer para cada um dos métodos de autenticação suportados. Cada biblioteca compartilhada de failoer é semelhante à biblioteca compartilhada do método de autenticação correspondente e, além disso, recupera todos os atributos estendidos que foram originalmente colocados na credencial do usuário. Quando ocorre um eento de autenticação com base em failoer, o plug-in chama a biblioteca de autenticação com base em failoer que corresponde ao último método de autenticação utilizado pelo usuário antes da falha no seridor original. O plug-in fornece a função de autenticação com base em failoer para os seguintes métodos de autenticação: Autenticação Básica ou com base em formulários (também conhecida como autenticação com base em senha), Autenticação com base em tokencard, Autenticação com base em certificados, Autenticação com base em pedidos HTTP, CDSSO (conexão única entre domínios), Autenticação Kerberos (SPNEGO). O plug-in fornece uma biblioteca compartilhada de failoer padrão que funciona para todos os métodos de autenticação acima. Essa biblioteca é chamada de libfailoerauthn em sistemas UNIX e de failoerauthn em sistemas Windows. Nota: Como alternatia, é possíel fornecer uma biblioteca CDAS personalizada que proporcione as capacidades de autenticação específicas necessárias para o ambiente. Por exemplo, o plug-in pode ser configurado para suportar a autenticação com base em formulários e a autenticação com base em failoer. Quando o plug-in é iniciado, tanto a biblioteca compartilhada de autenticação com base em formulários quanto a biblioteca de autenticação com base em failoer-formulários são carregadas. O usuário se autentica utilizando a autenticação com base em formulários. O seridor de plug-in enia um cookie de autenticação com base em failoer para cada cliente (naegador). Os dados do cookie especificam que ele foi criado em um ambiente de autenticação com base em formulários. Quando o seridor aprimorado pelo plug-in se torna indisponíel, o cookie de failoer é eniado para um segundo seridor aprimorado pelo plug-in. Esse segundo seridor, que é normalmente um seridor replicado, também possui a biblioteca compartilhada de autenticação com base em formulários e a biblioteca de failoer-formulários carregadas no plug-in. A instância do plug-in no segundo seridor recebe o cookie de failoer e o examina para determinar o método de 86 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

autenticação anterior do usuário. O plug-in no segundo seridor enia uma chamada para a biblioteca compartilhada de autenticação com base em failoer formulários de forma a extrair os dados necessários do cookie. Em seguida, utiliza esses dados para autenticar o usuário e obter uma credencial de usuário. Por exemplo, quando a autenticação com base em formulários e a autenticação com base em failoer estão atiadas em um ambiente de plug-in replicado, duas bibliotecas separadas deem ser configuradas no arquio de configuração do plug-in. Uma biblioteca especifica a biblioteca do método de autenticação com base em formulários. A outra biblioteca especifica a biblioteca do método de autenticação com base em failoer. Exemplos de entradas do arquio de configuração podem ser: [authentication-mechanisms] passwd-ldap = /opt/pdweb/lib/libldapauthn.so failoer-password = /opt/pdweb/lib/libfailoerauthn.so Nesse exemplo, a entrada da sub-rotina passwd-ldap especifica a biblioteca interna de autenticação com base em formulários do plug-in. A entrada da sub-rotina failoer-password especifica a biblioteca interna de autenticação com base em failoer. Adição de Dados a um Cookie de Failoer O plug-in adiciona dados específicos automaticamente a partir da sessão do usuário a cada cookie de autenticação com base em failoer. O plug-in pode ser configurado para adicionar outras informações a partir dos dados do cliente mantidos no cache de credenciais. Ele também pode ser configurado para adicionar dados definidos pelo usuário específicos para a sua implementação. Por exemplo, os atributos de usuário obtidos por um CDAS personalizado podem ser adicionados ao cookie. Por padrão, o plug-in adiciona os seguintes dados a cada cookie: Nome do usuário Esse nome corresponde ao nome utilizado para identificar o usuário no registro de usuários. Nota: Quando um usuário autenticado tier utilizado a função Comutação de Usuários do plug-in para obter a identidade efetia de outro usuário, essa identidade não será adicionada ao cookie. Somente a identidade do usuário autenticado original é adicionada ao cookie. Método de autenticação O método de autenticação utilizado para autenticar o usuário no plug-in. Hora de criação do cookie A hora do sistema no momento em que o cookie foi criado. O plug-in também cria uma lista de atributos que contém dados adicionais. Por padrão, essa lista de atributos contém um alor: Níel de autenticação Um alor inteiro que corresponde ao níel de intensificação da autenticação do plug-in (que também é um alor inteiro) atribuído ao método de autenticação no seridor aprimorado pelo plug-in local. A intensificação da autenticação, também conhecida como autenticação progressia, permite que um usuário se autentique em um método de autenticação diferente sem precisar efetuar logout. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 87

O plug-in define outros dados de usuário que podem ser adicionados à lista de atributos do cookie: Data e hora de duração da sessão Quando um usuário se autentica, o plug-in monitora a idade, ou a duração, da entrada desse usuário no cache de sessão. A data e a hora de duração da sessão consistem na hora atual, adiantada de acordo com o número de segundos configurado para o tempo máximo durante o qual os dados de sessão de um usuário podem permanecer no cache de sessão. Quando a hora do sistema atual excede o alor de data e hora, o plug-in inalida a entrada do usuário no cache de sessão (incluindo as credenciais desse usuário). O plug-in pode ser configurado para adicionar ao cookie a data e a hora de duração da sessão. Quando essa data e hora são adicionadas ao cookie, o cronômetro de duração da sessão pode ser preserado entre eentos de failoer. Dessa maneira, os administradores de plug-in podem optar por zerar ou não o cronômetro da sessão do cliente quando essa sessão for estabelecida em um seridor replicado. Obsere que o êxito do uso desse recurso depende da sincronização de clocks entre os seridores replicados aprimorados pelo plug-in. Se a inclinação do clock ficar muito grande, as sessões expirarão em momentos inoluntários. Data e hora de inatiidade da sessão O plug-in também monitora o tempo durante o qual a entrada de um usuário no cache de sessão do plug-in permaneceu inatia. Quando uma sessão de usuário permanece inatia durante um tempo maior que o alor definido para a inatiidade da sessão, o plug-in inalida essa sessão do usuário. A data e a hora de inatiidade da sessão também podem ser adicionadas ao cookie de autenticação com base em failoer. Essa data e hora são um pouco diferentes da data e hora de inatiidade da sessão mantidas para o cache de sessão do plug-in. O tempo limite de inatiidade do sistema mantido para o cache é calculado pela combinação de dois alores: Hora do sistema atual Número máximo de segundos durante os quais a sessão de um usuário pode permanecer inatia. Quando esse alor é adicionado ao cookie de autenticação com base em failoer, ele é combinado a um outro alor: Número máximo de segundos (interalo) entre atualizações no cookie de autenticação com base em failoer A definição para o interalo entre a atualização de cookies de failoer afeta o desempenho. Os administradores deem determinar um equilíbrio entre o desempenho ideal e a precisão absoluta do temporizador de inatiidade no cookie. Para manter o temporizador de inatiidade mais preciso, ele deerá ser atualizado sempre que o usuário fizer um pedido. Entretanto, a atualização freqüente do conteúdo de cookies geara uma sobrecarga e diminui o desempenho. Cada administrador dee escolher um interalo que seja mais adequado para a implementação do plug-in. Em alguns casos, uma atualização do cookie de failoer com cada pedido de usuário é mais apropriada. Em outros casos, o administrador pode optar por nunca atualizar o temporizador de inatiidade no cookie de failoer. Atributos estendidos adicionais Os administradores podem configurar o plug-in de forma que ele insira um conjunto personalizado de atributos em um cookie de failoer. Os atributos podem ser especificados indiidualmente ou em um grupo. Para especificar um 88 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

grupo de atributos, utilize a correspondência de padrões de caracteres coringa nas entradas do arquio de configuração. Esse recurso é útil em implementações que também utilizam bibliotecas de autenticação personalizadas, como seridores de autenticação entre domínios, para inserir atributos especiais em uma credencial de usuário. Por meio da especificação desses atributos no arquio de configuração do plug-in, o administrador pode se assegurar de que eles estarão disponíeis para inclusão na credencial de usuário recriada durante a autenticação com base em failoer. Nota: O tamanho máximo de um cookie de autenticação com base em failoer é de 4 KB (4096 bytes). Extração de Dados a partir de um Cookie de Failoer Quando ocorre um eento de autenticação com base em failoer, o plug-in recebe um cookie de autenticação com base em failoer e, por padrão, extrai os seguintes dados de cada cookie: Nome do usuário, Método de autenticação, Hora de criação do cookie. Em primeiro lugar, o plug-in determina se o cookie é álido subtraindo a hora de criação desse cookie da hora do sistema e comparando esse alor com base na entrada do arquio de configuração do plug-in para a duração do cookie de failoer. Se a duração do cookie tier sido excedida, o cookie não será álido e não haerá uma tentatia de fazer a autenticação com base em failoer. Se a duração do cookie não tier sido excedida, o plug-in utilizará o nome do usuário e o método de autenticação para autenticar o usuário e construir uma credencial de usuário. Em seguida, o plug-in erifica as definições de configuração para determinar se dados de cookie adicionais deem ser extraídos e aaliados. Obsere que, por padrão, o plug-in não extrai nenhum outro atributo do cookie de autenticação com base em failoer. Cada atributo adicional a ser extraído dee ser especificado no arquio de configuração do plug-in. A correspondência de padrões de caracteres coringa pode ser utilizada para obter grupos de atributos. O plug-in pode ser configurado para extrair os seguintes atributos definidos: Níel de autenticação Quando esse alor é extraído, o plug-in o utiliza de forma a assegurar que o usuário seja autenticado com o método de autenticação necessário para manter o níel de autenticação especificado. Obsere que o plug-in pode obter níeis de autenticação a partir de ários locais diferentes: Cookie de failoer Biblioteca de autenticação com base em failoer Cross-domain authentication serice Seriço de autorização O níel de autenticação extraído do cookie de failoer tem precedência sobre os níeis obtidos a partir de outros locais. Data e hora de duração da sessão O plug-in pode utilizar essa data e hora para determinar se a entrada do usuário no cache de sessão do seridor original pode estar expirada. Em caso positio, o Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 89

plug-in descartará o cookie e todos os seus atributos potenciais de credencial. A duração da sessão não será preserada, e o usuário será solicitado a efetuar login. Data e hora de inatiidade da sessão O plug-in pode utilizar essa data e hora para determinar se a entrada do usuário no cache de sessão do seridor original pode estar inatia por muito tempo. Em caso positio, o plug-in descartará o cookie e todos os seus atributos potenciais de credencial. A duração da sessão não será preserada, e o usuário será solicitado a efetuar login. Nota: O êxito do uso dessas datas e horas requer a sincronização de clocks entre seridores de plug-in replicados. Se a inclinação do clock ficar muito grande, as sessões expirarão ou ficarão inatias em momentos inoluntários. Atributos estendidos adicionais Incluem atributos personalizados definidos pelo usuário, como os atributos gerados pelo CDAS. O plug-in adiciona os atributos à credencial do usuário. Os atributos que não estierem especificados no arquio de configuração do plug-in serão ignorados e não serão extraídos. Além disso, os administradores podem especificar que determinados atributos deem ser ignorados durante a extração de cookies de failoer. Embora o comportamento padrão seja ignorar, essa especificação pode ser útil, por exemplo, para assegurar que os atributos do usuário sejam obtidos a partir do registro de usuários e não a partir do cookie de failoer. Autenticação com Base em Failoer para o Domínio Inteiro O plug-in suporta uma configuração opcional que possibilita a marcação de cookies de autenticação com base em failoer como disponíeis para uso durante a autenticação com base em failoer em qualquer um dos seridores aprimorados pelo plug-in no domínio do Tioli Access Manager. Essa opção de configuração permite que os cookies de autenticação com base em failoer sejam utilizados em implementações que não possuam necessariamente um recurso de equilíbrio de carga e seridores replicados aprimorados pelo plug-in. Quando uma sessão de cliente passa por um eento de autenticação com base em failoer para um seridor replicado aprimorado pelo plug-in, o cliente continua a acessar o mesmo conjunto de recursos protegidos. Quando uma sessão de cliente passa por um eento de autenticação com base em failoer para um seridor aprimorado pelo plug-in não replicado, é possíel que um conjunto diferente de recursos esteja disponíel ao cliente. Em grandes implementações, esse particionamento de recursos no domínio do Tioli Access Manager é comum. Esse particionamento pode ser feito por motios de desempenho e para finalidades administratias. A autenticação com base em failoer para o domínio inteiro pode ser utilizada de forma a redirecionar um cliente para outro seridor no momento em que os pedidos desse cliente resultarem na solicitação de um recurso que não está disponíel por meio do seridor local. Nesse caso, o cliente (naegador) é redirecionado para outro seridor aprimorado pelo plug-in. O plug-in receptor pode ser configurado para procurar cookies de autenticação com base em failoer. O plug-in tenta autenticar o cliente e reconhece o cookie de autenticação com base em failoer. Com o uso do cookie, o plug-in não precisa solicitar que o cliente especifique informações de login. Em ez disso, pode estabelecer uma sessão com esse cliente e construir um conjunto álido de credenciais de usuário. 90 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Compatibilidade com Versões Anteriores Os cookies de failoer gerados pela Versão 5.1 do plug-in podem ser compreendidos e lidos (consumidos) por plug-ins de ersões anteriores. Da mesma forma, os cookies de failoer gerados por plug-ins mais antigos (anteriores à Versão 5.1) podem ser compreendidos e lidos (consumidos) por essa Versão 5.1 do plug-in. Os módulos CDAS graados de forma a personalizar cookies de failoer para plug-ins mais antigos (anteriores à Versão 5.1) funcionarão com essa Versão 5.1 do plug-in. Para assegurar uma compatibilidade completa com ersões anteriores, os seguintes recursos são fornecidos: O plug-in pode ser configurado para autenticar um usuário com base no conteúdo do cookie de failoer quando a data e a hora de duração da sessão não estão presentes. A data e a hora de duração da sessão não estão presentes em cookies de autenticação com base em failoer anteriores à Versão 5.1. O plug-in pode ser configurado para autenticar um usuário com base no conteúdo do cookie de failoer quando a data e a hora de inatiidade da sessão não estão presentes. A data e a hora de inatiidade da sessão não estão presentes em cookies de autenticação com base em failoer anteriores à Versão 5.1. O algoritmo utilizado para criptografar dados de clientes em cookies de autenticação com base em failoer foi atualizado para a Versão 4.1 do plug-in. Ao utilizar o plug-in com ersões anteriores à Versão 4.1, uma definição de arquio de configuração pode ser especificada para permitir o acesso aos cookies de estilos mais antigos. O plug-in pode ser configurado para não utilizar a codificação UTF-8 em cadeias no cookie de failoer. Quando a codificação UTF-8 não é utilizada para cookies criados na Versão 5.1 do plug-in, esses cookies podem ser compreendidos e lidos (consumidos) por plug-ins mais antigos (anteriores à Versão 5.1). Fazendo o Upgrade da Autenticação com Base em Failoer No arquio de configuração do plug-in, as sub-rotinas [failoer-add-attributes] e [failoer-restore-attributes] substituem a sub-rotina [failoer-attributes] anterior à Versão 5.1. Durante um upgrade a partir do Tioli Access Manager Versão 4.1 para a ersão atual do Tioli Access Manager, a sub-rotina [failoer-attributes] e seu conteúdo são migrados para a sub-rotina [failoer-add-attributes]. O upgrade é automatizado e ocorre quando o plug-in é instalado. Não é necessário fazer a atualização manual dessas entradas. Configuração da Autenticação com Base em Failoer Esta seção descree como configurar a autenticação com base em failoer. Se ocê não estier familiarizado com os conceitos de autenticação com base em failoer, reise a seção Conceitos da Autenticação com Base em Failoer na página 84. Para configurar a autenticação com base em failoer, conclua as tarefas a seguir: 1. Pare o seridor de plug-in. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 91

2. Para atiar a autenticação com base em failoer, conclua cada uma das tarefas a seguir: a. Atiando a Autenticação com o Uso de Cookies de Failoer b. Especifique a Biblioteca de Autenticação com Base em Failoer na página 93 c. Crie uma Chae de Criptografia para os Dados do Cookie na página 94 d. Especifique a Duração do Cookie na página 94 e. Especifique a Codificação UTF-8 em Cabeçalhos BA na página 68 3. Como opção, é possíel configurar o plug-in para manter o estado entre sessões de autenticação com base em failoer. Se isso for apropriado para a sua implementação, conclua as instruções a seguir: a. Adicione a Data e a Hora de Duração da Sessão na página 96 b. Adicione a Data e a Hora de Atiidade da Sessão na página 96 c. Adicione um Interalo para Atualizar a Data e a Hora de Atiidade na página 97 4. Como opção, é possíel configurar o plug-in para adicionar atributos estendidos ao cookie de failoer: Adicione Atributos Estendidos na página 97 5. Quando ocê tier configurado o plug-in para adicionar atributos ao cookie de failoer, também será necessário configurá-lo para extrair atributos durante a leitura desse cookie: Especifique Atributos para Extração na página 98 6. Como opção, é possíel atiar cookies de autenticação com base em failoer para uso em qualquer seridor aprimorado pelo plug-in do domínio. Se isso for apropriado para a sua implementação, consulte a seção: Atie Cookies de Failoer para o Domínio Inteiro na página 98 7. Se ocê precisar manter a compatibilidade com cookies de autenticação com base em failoer gerados por seridores aprimorados pelo plug-in a partir de ersões anteriores à Versão 5.1, conclua as instruções a seguir: a. Especifique a Codificação UTF-8 em Cabeçalhos BA na página 68 b. Exija a Validação de uma Data e Hora de Duração na página 99 c. Exija a Validação de uma Data e Hora de Atiidade na página 99 d. Atie a Compatibilidade com Versões Anteriores para Criptografia na página 100 8. Depois de concluir todas as instruções aplicáeis à sua implementação, inicie noamente o seridor. Atiando a Autenticação com o Uso de Cookies de Failoer A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Os cookies de failoer podem ser configurados para executar tarefas de autenticação e de pós-autorização. Os plug-ins configurados para o processamento pós-autorização com o uso de cookies de failoer criptografam e armazenam uma credencial como um cookie de failoer na resposta de transação. Os plug-ins, configurados para utilizar cookies de failoer para a execução da autenticação, reautenticam clientes com o uso da credencial criptografada a partir de um cookie de failoer encontrado no pedido de transação. 92 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Para atiar a autenticação e a pós-autorização utilizando cookies de failoer, atribua a referência failoer aos parâmetros authentication e post-authzn: [common-modules] authentication = failoer post-authzn = failoer A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e o respectio nome da biblioteca compartilhada associada. Assegure-se de que a entrada para a autenticação com base em failoer esteja presente: [modules] failoer = pdwpi-failoercookie-module Especifique a Biblioteca de Autenticação com Base em Failoer Edite o arquio de configuração do plug-in. Na sub-rotina [authenticationmechanisms], desfaça o comentário da entrada para o(s) tipo(s) de autenticação que dee(m) suportar cookies de failoer. Adicione o nome da biblioteca de cookies de failoer do plug-in apropriada para o tipo de sistema operacional. A entrada do arquio de configuração padrão é: [authentication-mechanisms] #failoer-password = failoer_password_library_filename #failoer-token-card = failoer_token_card_filename #failoer-certificate = failoer_certificate_filename #failoer-http-request = failoer_http_request_filename #failoer-cdsso = failoer_cdsso_filename #failoer-kerberos5 = failoer_kerberos_library O plug-in fornece uma biblioteca compartilhada de failoer padrão que funciona para todos os métodos de autenticação acima. Consulte a tabela a seguir para conhecer os nomes das bibliotecas: Tabela 13. Nomes de Arquios de Bibliotecas de Autenticação com Base em Failoer Solaris Linux AIX Windows libfailoerauthn.so libfailoerauthn.so libfailoerauthn.a failoerauthn.dll Por exemplo, para atiar a autenticação com base em failoer para clientes que foram originalmente autenticados com a autenticação com base em formulários no Solaris, desfaça o comentário da entrada failoer-password e adicione o nome da biblioteca: [authentication-mechanisms] failoer-password = libfailoerauthn.so Como alternatia, quando ocê tier desenolido uma biblioteca CDAS que implemente uma ersão personalizada da autenticação com base em failoer para um ou mais métodos de autenticação, insira o nome do CDAS personalizado como o alor para a palara-chae do arquio de configuração. Por exemplo, se ocê tier desenolido um CDAS personalizado para autenticação com base em formulários, insira o nome do caminho absoluto: [authentication-mechanisms] failoer-password = /dir_name/custom_cdas_failoer_library.so Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 93

Crie uma Chae de Criptografia para os Dados do Cookie Use o utilitário cdsso_key_gen para proteger os dados do cookie. Esse utilitário gera uma chae simétrica que criptografa e decriptografa os dados no cookie. Atenção: Se ocê não configurar o plug-in para criptografar cookies de autenticação com base em failoer e tier atiado a autenticação com base em failoer, o plug-in gerará um erro e recusará a inicialização. Os cookies de autenticação com base em failoer deem ser criptografados. 1. Execute o utilitário em um dos seridores replicados. A partir de uma linha de comandos, especifique a localização do arquio de chaes que ocê deseja criar. É necessário especificar um nome de caminho absoluto. Por exemplo: UNIX: # /opt/pdwebrte/bin/cdsso_key_gen absolute_pathname_for_keyfile Windows: MSDOS> C:\Arquios de programas\tioli\pdwebrte\bin\cdsso_key_gen absolute_pathname_for_keyfile É possíel fornecer qualquer nome apropriado ao arquio de chaes, como /opt/pdwebrte/lib/wpi.key. 2. Edite o arquio de configuração do plug-in. Na sub-rotina [failoer], especifique a localização do arquio de chaes. [failoer] failoer-cookies-keyfile = absolute_pathname_for_keyfile 3. Copie manualmente o arquio de chaes para cada um dos seridores replicados restantes. 4. Em cada seridor replicado, edite o arquio de configuração do plug-in para fornecer o nome do caminho correto a failoer-cookies-keyfile na sub-rotina [failoer]. Especifique a Duração do Cookie Edite o arquio de configuração do plug-in. Especifique a duração álida para o cookie de failoer. [failoer] failoer-cookie-lifetime = 30 A duração padrão é de 30 minutos. Especifique a Codificação UTF-8 em Cadeias de Cookies Edite o arquio de configuração do plug-in. Especifique se o plug-in dee ou não utilizar a codificação UTF-8 em cadeias nos cookies de failoer. [failoer] use-utf8 = true O alor padrão é true. O UTF-8 dee ser utilizado quando nomes de usuários ou atributos de credencial no cookie não estão codificados na mesma página de código que está sendo utilizada pelo seridor aprimorado pelo plug-in. Por padrão, o plug-in suporta a codificação UTF-8. Quando todos os seridores na implementação do plug-in utilizam a codificação UTF-8, deixe esse alor na definição padrão de true. Compatibilidade com ersões anteriores 94 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

As instalações de plug-ins anteriores à Versão 5.1 não utilizaam a codificação UTF-8. Portanto, os cookies criados por esses seridores não apresentam a codificação UTF-8 em suas cadeias. Quando uma instância de plug-in está em operação com um plug-in de ersões anteriores à Versão 5.1, esse plug-in não dee utilizar a codificação UTF-8. Para obter a compatibilidade com ersões anteriores, defina use-utf8 como false. [failoer] use-utf8 = false Para obter informações adicionais sobre o suporte do plug-in para a codificação UTF-8, consulte Suporte a Idiomas e Conjuntos de Caracteres na página 37. Especifique o Níel de Autenticação O plug-in fornece diersas maneiras diferentes de especificar um níel de autenticação. Para cookies de failoer, dois métodos podem ser utilizados. Um deles define o níel de autenticação no cookie de failoer. O outro define o níel ao chamar a biblioteca de autenticação com base em failoer. Quando esses dois métodos são utilizados, o níel de autenticação no cookie de failoer tem precedência sobre o níel definido ao chamar a biblioteca. Se nenhum dos métodos estier configurado, o níel de autenticação será definido como o níel de autenticação associado ao método de failoer pela sub-rotina [authentication-leels]. Os dois métodos são: Especifique o níel de autenticação no cookie de autenticação com base em failoer. Adicione o níel de autenticação ao arquio de configuração do plug-in. É necessário utilizar a palara-chae de entrada de sub-rotina AUTHENTICATON_LEVEL: [failoer-add-attributes] ou [failoer-add-attributes:irtual-host] AUTHENTICATION_LEVEL = add O alor real para AUTHENTICATION_LEVEL é um inteiro que o plug-in monitora internamente. Não é necessário especificar o inteiro nessa sub-rotina. Para manter o níel de autenticação opcionalmente carregado no cookie pelo originador, o alor também dee ser configurado de forma a ser preserado no final do recebimento com o uso da entrada de following: [failoer-restore-attributes] ou [failoer-restore-attributes:irtual-host] AUTHENTICATION_LEVEL = presere Especifique o níel de autenticação ao chamar a biblioteca de autenticação com base em failoer. Ao configurar a biblioteca interna de autenticação com base em failoer do plug-in ou uma biblioteca CDAS, ocê pode opcionalmente especificar um níel de autenticação a ser atribuído ao usuário autenticado. O níel de autenticação é um inteiro que é mapeado para um método de autenticação específico, como parte do recurso de intensificação da autenticação do plug-in. Adicione um argumento de linha de comandos à entrada do arquio de configuração para a biblioteca de autenticação com base em failoer apropriada. A sintaxe é: [authentication-mechanisms] failoer_authentication_method = failoer_authentication_libary& -l leel_number Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 95

O alor leel_number dee corresponder a um inteiro álido, conforme especificado na sub-rotina [authentication-leels] do arquio de configuração do plug-in. Por exemplo, para atiar a autenticação com base em failoer para a autenticação com base em formulários em um sistema Solaris e para atribuir ao usuário um níel de autenticação igual a 3, crie a seguinte entrada do arquio de configuração: [authentication-mechanisms] failoer-password = libfailoerauthn.so& -l 3 Adicione a Data e a Hora de Duração da Sessão O plug-in calcula a data e a hora de duração da sessão combinando os seguintes alores: Hora do sistema atual. Duração máxima, em segundos, na qual uma entrada pode existir no cache de credenciais do plug-in. Essa duração máxima em segundos é especificada na sub-rotina [session] do arquio de configuração do plug-in: [sessions] timeout = 3600 Para adicionar esse alor ao cookie de autenticação com base em failoer, adicione a seguinte entrada ao arquio de configuração do plug-in: [failoer-add-attributes] session-lifetime-timestamp = add Obsere que esse atributo não pode ser definido pela correspondência de caracteres coringa. A entrada exata, session-lifetime-timestamp, dee ser inserida. Adicione a Data e a Hora de Atiidade da Sessão O plug-in calcula a data e a hora de atiidade da sessão somando estes alores: Hora do sistema. Duração máxima de entradas inatias no cache de credenciais. A duração máxima para entradas inatias é definida na sub-rotina [sessions] do arquio de configuração: [session] inactie-timeout = 600 O alor padrão é 600 segundos. O interalo para atualização do cookie de autenticação com base em failoer. Esse alor é definido na sub-rotina [failoer] do arquio de configuração do plug-in: [failoer] failoer-update-cookie = -1 O alor padrão é -1 segundos. Um inteiro negatio significa que o cookie de failoer apenas será atualizado quando ocorrer a autenticação ou quando a credencial for atualizada. Para obter informações adicionais, consulte Adicione um Interalo para Atualizar a Data e a Hora de Atiidade na página 97. Para adicionar esse alor ao cookie de autenticação com base em failoer, adicione a seguinte entrada ao arquio de configuração do plug-in: [failoer-add-attributes] session-actiity-timestamp = add 96 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Obsere que esse atributo não pode ser definido pela correspondência de caracteres coringa. A entrada exata, session-actiity-timestamp, dee ser inserida. Adicione um Interalo para Atualizar a Data e a Hora de Atiidade Como opção, a data e a hora de atiidade da sessão no cookie de failoer podem ser atualizadas durante a sessão do usuário. Essa entrada contém um alor inteiro para o interalo (em segundos) entre a atualização da data e hora de atiidade do cookie de failoer. A entrada padrão é: [failoer] failoer-update-cookie = -1 Quando failoer-update-cookie é definido como 0, as últimas data e hora de atiidade são atualizadas com cada pedido. Quando failoer-update-cookie é definido como um inteiro menor que 0 (qualquer número negatio), as últimas data e hora de atiidade nunca são atualizadas. Quando failoer-update-cookie é definido como um inteiro maior que 0, a data e a hora de atiidade da sessão no cookie são atualizados em interalos correspondentes a esse número de segundos. O alor escolhido para essa entrada de sub-rotina pode afetar o desempenho. Consulte a Adição de Dados a um Cookie de Failoer na página 87. Adicione Atributos Estendidos O plug-in pode opcionalmente ser configurado para colocar uma cópia de atributos estendidos especificados a partir de uma credencial de usuário em um cookie de autenticação com base em failoer. Por padrão, nenhum atributo estendido é configurado. Para adicionar atributos estendidos, adicione entradas à sub-rotina [failoer-add-attributes] do arquio de configuração do plug-in. A sintaxe é: [failoer-add-attributes] attribute_pattern = add O alor attribute_pattern pode ser um nome de atributo específico ou uma expressão usem distinção entre maiúsculas e minúsculas que corresponde a mais de um nome de atributo. Por exemplo, para especificar todos os atributos com o prefixo tagalue_, adicione a seguinte entrada: [failoer-add-attributes] tagalue_* = add A ordem das entradas da sub-rotina é importante. As regras que aparecem antes em [failoer-add-attributes] têm prioridade sobre as regras colocadas depois nessa sub-rotina. Os atributos que não corresponderem a nenhum desses padrões de caracteres coringa ou que não forem explicitamente especificados não serão adicionados ao cookie de failoer. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 97

Especifique Atributos para Extração O plug-in pode opcionalmente ser configurado para extrair atributos de um cookie de autenticação com base em failoer e para colocá-los em uma credencial de usuário. Por padrão, não existem atributos configurados para extração. Os atributos a serem extraídos são declarados na sub-rotina [failoer-restoreattributes] do arquio de configuração do plug-in. A sintaxe é: [failoer-restore-attributes] attribute_pattern = {presere refresh} O alor presere instrui o plug-in a extrair o atributo e adicioná-lo à credencial. Os alores definidos por esse método sobrepõem os atributos com o mesmo nome que possam ter sido definidos quando o CDAS de autenticação criou a noa credencial. O alor refresh instrui o plug-in a extrair condicionalmente o atributo e adicioná-lo à credencial apenas se um atributo com o mesmo nome não tier sido adicionado quando o CDAS de autenticação criou a noa credencial. O alor attribute_pattern pode ser um nome de atributo específico ou uma expressão usem distinção entre maiúsculas e minúsculas que corresponde a mais de um nome de atributo. Por exemplo, para extrair todos os atributos com o prefixo tagalue_, adicione a seguinte entrada: [failoer-restore-attributes] tagalue_* = presere Os atributos que não corresponderem a nenhum dos padrões especificados com o alor presere não serão extraídos do cookie de autenticação com base em failoer. A ordem das entradas da sub-rotina é importante. As regras que aparecem antes em [failoer-restore-attributes] têm prioridade sobre as regras colocadas depois nessa sub-rotina. Os atributos a seguir não podem ser correspondidos por um padrão de caracteres coringa, mas deem estar explicitamente definidos para extração: Níel de autenticação [failoer-restore-attributes] AUTHENTICATION_LEVEL = presere Data e hora de duração da sessão [failoer-restore-attributes] session-lifetime-timestamp = presere Data e hora de inatiidade da sessão [failoer-restore-attributes] session-inactiity-timestamp = presere Atie Cookies de Failoer para o Domínio Inteiro É possíel permitir que um cookie de autenticação com base em failoer seja utilizado por qualquer plug-in no mesmo domínio que o plug-in que criou esse cookie. Esse recurso é controlado por uma entrada de sub-rotina na sub-rotina [failoer]. Por padrão, a funcionalidade de cookies de failoer para o domínio inteiro está desatiada: 98 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

[failoer] enable-failoer-cookie-for-domain = false Para atiar esse recurso, defina enable-failoer-cookie-for-domain como true: [failoer] enable-failoer-cookie-for-domain = true Para obter informações sobre os efeitos de atiar essa entrada de sub-rotina, consulte Autenticação com Base em Failoer para o Domínio Inteiro na página 90. Exija a Validação de uma Data e Hora de Duração O plug-in pode opcionalmente ser configurado para exigir que cada cookie de autenticação com base em failoer contenha uma data e uma hora de duração da sessão. Por padrão, a data e a hora de duração da sessão não são necessárias. A entrada do arquio de configuração padrão é: [failoer] failoer-require-lifetime-timestamp-alidation = false Essa entrada de sub-rotina é principalmente utilizada para compatibilidade com ersões anteriores. Atenção: Para obter compatibilidade com cookies de failoer criados por plug-ins anteriores à Versão 5.1, defina essa entrada como false. Os cookies de autenticação com base em failoer criados por plug-ins anteriores à Versão 5.1 não contêm essa data e hora. Quando esse alor for false e a data e a hora de duração da sessão estierem ausentes no cookie de failoer, o seridor receptor exibirá o cookie como álido. Quando esse alor for true e a data e a hora de duração da sessão estierem ausentes no cookie de failoer, o seridor receptor exibirá o cookie como não álido. Quando esse alor for false ou true e a data e a hora de duração da sessão estierem presentes no cookie de failoer, o seridor receptor aaliará a data e a hora. Se a data e a hora não forem álidas, a autenticação falhará. Se a data e a hora forem álidas, o processo de autenticação continuará. Nota: A data e a hora de duração da sessão são configuradas separadamente da data e hora de atiidade da sessão. Exija a Validação de uma Data e Hora de Atiidade O plug-in pode opcionalmente ser configurado para exigir que cada cookie de autenticação com base em failoer contenha uma data e hora de atiidade da sessão. Por padrão, a data e a hora de atiidade da sessão não são necessárias. A entrada do arquio de configuração padrão é: [failoer] failoer-require-actiity-timestamp-alidation = false Essa entrada de sub-rotina é principalmente utilizada para compatibilidade com ersões anteriores. Atenção: Para obter compatibilidade com cookies de failoer criados por plug-ins anteriores à Versão 5.1, defina essa entrada como false. Os cookies de autenticação com base em failoer criados por plug-ins anteriores à Versão 5.1 não contêm essa data e hora. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 99

Quando esse alor for false e a data e a hora de atiidade da sessão estierem ausentes no cookie de failoer, o seridor receptor exibirá o cookie como álido. Quando esse alor for true e a data e a hora de atiidade da sessão estierem ausentes no cookie de failoer, o seridor receptor exibirá o cookie como não álido. Quando esse alor for false ou true e a data e a hora de atiidade da sessão estierem presentes no cookie de failoer, o seridor receptor aaliará a data e a hora. Se a data e a hora não forem álidas, a autenticação falhará. Se a data e a hora forem álidas, o processo de autenticação continuará. Nota: A data e a hora de atiidade da sessão são configuradas separadamente da data e hora de duração da sessão. Atie a Compatibilidade com Versões Anteriores para Criptografia Para o Tioli Access Manager Versão 4.1, o níel de segurança para a criptografia do cookie de autenticação com base em failoer foi aumentado. Esse algoritmo de criptografia não é compatíel com ersões anteriores. Se ocê estier integrando cookies de autenticação com base em failoer a seridores aprimorados pelo plug-in utilizando ersões do Tioli Access Manager anteriores à Versão 4.1, será necessário especificar uma definição de arquio de configuração no arquio de configuração do plug-in de forma a atiar a compatibilidade com ersões anteriores. Por padrão, a compatibilidade com ersões anteriores do algoritmo de criptografia mais antigo não é atiada: [pdweb-plugins] pre-410-compatible-tokens = false Para atiar a compatibilidade com ersões anteriores, defina pre-410-compatibletokens como true: [pdweb-plugins] pre-410-compatible-tokens = true Configurando a Autenticação com Base em Cabeçalhos IV O Tioli Access Manager suporta a autenticação com o uso de informações de cabeçalho geradas internamente fornecidas por um cliente compatíel ou por um agente proxy. Por motios históricos, essas informações são chamadas de cabeçalhos IV (IntraVerse). Quando o seridor Web aprimorado pelo plug-in recebe pedidos de um aplicatio confiáel, como o WebSEAL ou um agente proxy de multiplexação, cabeçalhos IV podem ser inseridos nos pedidos transmitidos ao seridor proxy de plug-in. Cabeçalhos IV contêm informações que identificam o cliente originador em ez do seridor de transmissão. As informações nos cabeçalhos são utilizadas para construir uma credencial do cliente originador para finalidades de autorização. De forma semelhante, se o seridor Web aprimorado pelo plug-in transmitir pedidos a outro seridor Tioli Access Manager que reconheça cabeçalhos IV, o proxy do plug-in poderá inserir esses cabeçalhos IV para identificar o cliente originador. O plug-in pode ser configurado para utilizar cabeçalhos IV para o processamento pós-autorização ou para pedidos de autenticação. Configurado para o processamento pós-autorização, o plug-in, após uma autenticação bem-sucedida, 100 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

modifica um pedido de transação inserindo a identidade real do cliente como cabeçalhos IV. Em seguida, esses cabeçalhos podem ser encaminhados para outro seridor pelo seridor Web originador. Se o plug-in estier configurado para utilizar Cabeçalhos IV de forma a executar a autenticação do cliente, ele criará uma credencial de cliente utilizando a identidade extraída de um cabeçalho IV encontrado em um pedido de transação. Como é fácil para os clientes falsificar cabeçalhos IV, essa credencial apenas será criada se o pedido for recebido por meio de um MPA (agente proxy de multiplexação) confiáel. Consulte Oferecendo Suporte para MPAs (Agentes Proxy de Multiplexação) na página 112. Para autenticação, os cabeçalhos IV podem ser configurados para aceitar um, alguns ou todos os cabeçalhos i-user, i-user-l, i-creds ou i-remote-address no pedido como proa de autenticação quando recebidos por meio de um proxy. O cabeçalho i-remote-address é utilizado para registrar a endereço remoto real do usuário. Configurados para o processamento pós-autorização, os cabeçalhos IV são inseridos com um, alguns ou todos os cabeçalhos HTTP i-user, i-user-l, i-creds, i-groups e/ou i-remote-address no pedido. Tabela 14. Descrições de Campos de Cabeçalhos IV Campo de Cabeçalho IV i-user i-user-l i-groups i-creds i-remote-address Descrição O nome abreiado do usuário do Access Manger. Assumirá unauthenticated como padrão se o cliente não estier autenticado (desconhecido). O nome de domínio completo do usuário (formato longo). Por exemplo, o nome distinto LDAP. Uma lista dos grupos aos quais o usuário pertence. Estrutura de dados opacos codificados que representa a credencial do Tioli Access Manager do usuário. O endereço IP do cliente. Esse alor poderia representar o endereço IP de um seridor proxy ou de um NAT (conersor de endereços de rede). Nota: O Access Manager apenas confia em cabeçalhos recebidos de front-ends confiáeis. Um front-end será considerado confiáel se estier organizado como um MPA (Agente Proxy de Multiplexação). Para obter detalhes sobre como configurar o plug-in para suporte a MPAs, consulte Oferecendo Suporte para MPAs (Agentes Proxy de Multiplexação) na página 112. Atiando a Autenticação com o Uso de Cabeçalhos IV A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a autenticação utilizando cabeçalhos IV, atribua a referência i-headers ao parâmetro authentication: [common-modules] authentication = i-headers Para atiar cabeçalhos IV para o processamento pós-autorização, atribua o alor i-headers ao parâmetro post-authzn na sub-rotina [common-modules] do arquio de configuração pdwebpi.conf: Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 101

[common-modules] post-authzn = i-headers A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e o respectio nome da biblioteca compartilhada associada. Assegure-se de que a entrada para a autenticação com base em cabeçalhos IV esteja presente: [modules] i-headers = pdwpi-i-headers-module Configurando Parâmetros de Cabeçalhos IV Os parâmetros de autenticação com base em cabeçalhos IV são configurados na sub-rotina [i-headers] do arquio de configuração pdwebpi.conf. O parâmetro accept especifica os tipos de cabeçalhos IV que são aceitos para a execução da autenticação com base em cabeçalhos IV. Por padrão, o plug-in aceita todos os tipos de cabeçalhos IV. As opções álidas são all, i-creds, i-user, i-user-l, i-remote-address. Para inserir mais de um tipo de cabeçalho, separe os alores com uma írgula. Por exemplo: [i-headers] accept = i-creds,i-user O parâmetro generate especifica o tipo de cabeçalho IV a ser gerado ao encaminhar pedidos em proxy. Por padrão, o plug-in gera todos os tipos de cabeçalhos IV ao encaminhar pedidos em proxy. As opções álidas são: all, i-creds, i-user, i-user-l, i-remote-address. Para inserir mais de um tipo de cabeçalho, separe os alores com uma írgula. Especifique a Codificação UTF-8 de Cabeçalhos IV Edite o arquio de configuração do plug-in. Especifique se o plug-in dee ou não utilizar a codificação UTF-8 para cabeçalhos IV. [i-headers] use-utf8 = true O alor padrão é true. Para obter informações adicionais sobre o suporte do plug-in para a codificação UTF-8, consulte Suporte a Idiomas e Conjuntos de Caracteres na página 37. Configurando o Mecanismo de Autenticação com Base em Cabeçalhos IV para i-remote-address Ao utilizar i-remote-address no Cabeçalho IV, ocê precisará especificar a biblioteca compartilhada para o mapeamento de informações de cabeçalho de autenticação HTTP. O mecanismo de autenticação http-request especifica a biblioteca compartilhada para o mapeamento dessas informações de cabeçalho de autenticação HTTP. No UNIX, o arquio que fornece a função de mapeamento interno é uma biblioteca compartilhada que se chama libhttpauth. No Windows, o arquio que fornece a função de mapeamento interno é uma DLL que se chama httpauthn.dll. 102 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

É possíel configurar o mecanismo de autenticação com base em cabeçalhos HTTP inserindo o parâmetro http-request com o nome do arquio de biblioteca compartilhada específico para cada plataforma na sub-rotina [authenticationmechanisms] do arquio de configuração pdwebpi.conf, ou seja: Solaris: [authentication-mechanisms] http-request = libhttpauth.so Windows: [authentication-mechanisms] http-request = httpauthn.dll Configurando a Autenticação com Base em Cabeçalhos HTTP O Tioli Access Manager suporte a autenticação por meio de informações de cabeçalho HTTP personalizadas fornecidas pelo cliente ou por um agente proxy. Esse mecanismo requer uma função de mapeamento (uma biblioteca compartilhada) que faça o mapeamento dos dados de cabeçalhos confiáeis (pré-autenticados) para uma identidade do Tioli Access Manager. O plug-in pode obter essa identidade e criar uma credencial para o usuário. O plug-in assume que os dados de cabeçalhos HTTP personalizados foram anteriormente autenticados por um agente proxy. Por esse motio, o módulo apenas funcionará se o plug-in estier localizado atrás de um agente proxy da Web autenticado e se o parâmetro mpa-enabled na sub-rotina [pdweb-plugins] estier definido como true. Por padrão, essa biblioteca compartilhada é construída para mapear dados a partir de cabeçalhos Entrust Proxy. Atiando a Autenticação com o Uso de Cabeçalhos HTTP A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a autenticação utilizando cabeçalhos HTTP, atribua a referência http-hdr ao parâmetro authentication, ou seja: [common-modules] authentication = http-hdr A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e o respectio nome da biblioteca compartilhada associada. Assegure-se de que a entrada para a autenticação com base em cabeçalhos HTTP esteja presente: [modules] http-hdr = pdwpi-httphdr-module Especificando Tipos de Cabeçalhos É necessário especificar todos os tipos de cabeçalhos HTTP suportados na sub-rotina [http-hdr] do arquio de configuração pdwebpi.conf. [http-hdr] header = header_type Uma configuração padrão de cabeçalhos HTTP permite que apenas um cabeçalho seja especificado, por exemplo: Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 103

[modules] http-hdr = pdwpi-httphdr-module Para especificar ários cabeçalhos HTTP, diersas instâncias do módulo de cabeçalhos HTTP deem ser configuradas. Por exemplo: [modules] entrust-client-header = pdwpi-httphdr-module some-other-header = pdwpi-httphdr-module [entrust-client-header] header = entrust-client [some-other-header] header = some-other Configurando o Mecanismo de Autenticação com Base em Cabeçalhos HTTP O parâmetro http-request especifica a biblioteca compartilhada para o mapeamento de informações de cabeçalho de autenticação HTTP. No UNIX, o arquio que fornece a função de mapeamento interno é uma biblioteca compartilhada que se chama libpdwpi-http-cdas. No Windows, o arquio que fornece a função de mapeamento interno é uma DLL que se chama pdwpi-http-cdas. Por padrão, essa biblioteca interna compartilhada é codificada em código permanente de forma a mapear dados de cabeçalhos Entrust Proxy para uma identidade álida do Tioli Access Manager. É necessário personalizar esse arquio de forma a autenticar outros tipos de dados de cabeçalho especiais e, como opção, mapear esses dados para uma identidade do Tioli Access Manager. Consulte o documento IBM Tioli Access Manager for e-business Web Security: Referência para Desenoledores para conhecer recursos de APIs. É possíel configurar o mecanismo de autenticação com base em cabeçalhos HTTP inserindo o parâmetro http-request com o nome do arquio de biblioteca compartilhada específico para cada plataforma na sub-rotina [authenticationmechanisms] do arquio de configuração pdwebpi.conf. Por exemplo: Solaris: [authentication-mechanisms] http-request = libpdwpi-http-cdas.so Windows: [authentication-mechanisms] http-request = pdwpi-http-cdas.dll Configurando a Autenticação com Base em Endereços IP O Endereço IP de pedidos de entrada podem ser utilizados para manter o estado de sessões e para autenticar pedidos de clientes utilizando alores nos cabeçalhos de endereço desses clientes. 104 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

A configuração do plug-in para utilizar o endereço IP de forma a manter o estado de sessões será inálida se ele também não for configurado para utilizar esse endereço IP de forma a autenticar o pedido do cliente. Entretanto, o uso do endereço IP para autenticar usuários será álido se o plug-in não utilizar esse endereço IP para monitorar sessões de usuários. Atiando a Autenticação com o Uso do Endereço IP A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a autenticação utilizando o Endereço IP do iniciador do pedido, atribua a referência ip-addr ao parâmetro authentication, conforme mostrado a seguir: [common-modules] authentication = ip-addr Para atiar o uso do Endereço IP de forma a monitorar sessões de usuários, atribua a referência ip-addr ao parâmetro session, conforme mostrado a seguir: [common-modules] session = ip-addr A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e os respectios nomes das bibliotecas compartilhadas associadas. Assegure-se de que a entrada para a autenticação com base em Endereço IP esteja presente, conforme mostrado a seguir: [modules] ip-addr = pdwpi-ipaddr-module Configurando o Mecanismo de Autenticação com Base em Endereço IP O Mecanismo de Autenticação com base em Endereço IP é igual ao Mecanismo de Autenticação com base em Cabeçalhos HTTP. O parâmetro http-request especifica a biblioteca compartilhada para o mecanismo de autenticação com base em Endereço IP. No UNIX, o arquio que fornece a função de mapeamento interno é uma biblioteca compartilhada que se chama libpdwpi-http-cdas. No Windows, o arquio que fornece a função de mapeamento interno é uma DLL que se chama pdwpi-http-cdas. É possíel configurar o mecanismo de autenticação com base em endereço IP inserindo o parâmetro http-request com o nome do arquio de biblioteca compartilhada específico para cada plataforma na sub-rotina [authenticationmechanisms] do arquio de configuração pdwebpi.conf. Por exemplo: Solaris: [authentication-mechanisms] http-request = libpdwpi-http-cdas.so Windows: [authentication-mechanisms] http-request = pdwpi-http-cdas.dll Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 105

Configurando a Autenticação LTPA O plug-in pode utilizar cookies LTPA para autenticar usuários. Esses cookies LTPA podem ser fornecidos pelo Tioli Access Manager WebSEAL ou pelo IBM WebSphere Serer. Atiando a Autenticação LTPA A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso do LTPA para pedidos de autenticação. [common-modules] authentication = ltpa A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e o respectio nome da biblioteca compartilhada associada. Assegure-se de que a entrada para a autenticação LTPA esteja presente, ou seja: [modules] ltpa = pdwpi-ltpa-module Definindo os Detalhes de Chaes O cookie LTPA real, que é recebido, é criptografado pelo emissor. Esse cookie dee ser decriptografado para que a autenticação possa ocorrer. A sub-rotina [ltpa] no arquio de configuração pdwebpi.conf contém os detalhes de chaes necessários para o processo de decriptografia: [ltpa] ltpa-keyfile = full path of keyfile ltpa-stash-file = password stash file location ltpa-password = password in lieu of the stash file em que: A entrada ltpa-keyfile especifica o nome do arquio de chaes fornecido a partir da máquina de origem. A entrada do arquio de chaes é necessária. A entrada ltpa-stash-file especifica o nome do arquio que contém a senha para o arquio de chaes. Essa entrada é opcional. Entretanto, se não existir, a entrada ltpa-password deerá existir. Essa entrada tem precedência sobre qualquer ltpa-password especificada. A entrada ltpa-password apenas será necessária se a entrada ltpa-stash-file não existir. Ela dee conter a senha em texto não criptografado para o arquio de chaes especificado. Configurando o Processamento Pós-Autenticação LTPA O módulo LTPA é configurado para processamento pós-autorização como parte de uma solução de conexão única com um WebSphere Application Serer. Consulte Conexão Única com o WebSphere Application Serer Utilizando Cookies LTPA na página 137 para conhecer detalhes de configuração. Configurando o Redirecionamento de Usuários Após o Logon Com o uso do módulo login-redirect, será possíel configurar o plug-in para redirecionar os usuários a um URL específico depois que eles forem autenticados com êxito. Isso pode ser útil em casos nos quais ocê deseja que todos os usuários sejam direcionados a um portal em ez de uma página da Web solicitada ou para apresentar ao usuário uma página de boas-indas ou uma página inicial de um aplicatio on-line. 106 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

A funcionalidade de redirecionamento de logon do plug-in opera independentemente do método utilizado para autenticar usuários. O redirecionamento não ocorre para uma autenticação progressia nem para uma reautenticação. Atiando o Redirecionamento de Usuários A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para redirecionar o usuário a um URI específico após o logon e a autenticação iniciais, atribua a referência login-redirect ao parâmetro pre-authzn, conforme mostrado a seguir: [common-modules] pre-authzn = login-redirect Nota: Quando o parâmetro login-redirect é utilizado, coném colocá-lo primeiramente na lista de módulos de pré-autorização. Caso contrário, o redirecionamento de outro módulo de autenticação poderá ter precedência. A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e os respectios nomes das bibliotecas compartilhadas associadas. Assegure-se de que a entrada para login-redirect esteja presente, conforme mostrado a seguir: [modules] login-redirect = pdwpi-loginredirect-module Configurando Parâmetros de Redirecionamento de Usuários Os parâmetros de parâmetros de usuários são configurados na sub-rotina [login-redirect] do arquio de configuração pdwebpi.conf. [login-redirect] redirect-uri = redirect uri Utilize o parâmetro redirect-uri para especificar o URI ao qual ocê deseja redirecionar os usuários após um logon bem-sucedido. O URI especificado pode ser um URI relatio ou um URI absoluto. Adicionando Atributos Estendidos para Credenciais Esta seção contém os seguintes tópicos: Mecanismos para Adicionar Atributos Estendidos a uma Credencial Configuração do Seriço de Autorização na página 108 Mecanismos para Adicionar Atributos Estendidos a uma Credencial O processo de autenticação do Tioli Access Manager Plug-in para Web Serers acessa o registro de usuários do Tioli Access Manager e constrói uma credencial para o usuário. Essa credencial contém informações sobre o usuário que são necessárias para tomar decisões de acesso. Isso inclui informações como o nome do usuário e uma lista dos grupos aos quais esse usuário pertence. O plug-in suporta ários mecanismos (seriços) diferentes que possibilitam a extensão do processo de autenticação por parte de administradores e desenoledores de aplicatios. Quando o plug-in realiza o processo de autenticação, ele erifica se seriços externos foram implementados e configurados. Em caso positio, o plug-in chamará esses seriços. Os seriços podem executar Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 107

seus próprios processamentos de forma a construir uma lista de atributos estendidos sobre a identidade do usuário. Esses atributos estendidos são adicionados à credencial do usuário. Os seguintes tipos de seriços são suportados: Seriço de autorização sobre atributos de credencial Esse seriço de autorização está incorporado por padrão no Tioli Access Manager. Ele obtém informações sobre o usuário especificado a partir de um registro de usuários (como um registro de usuários LDAP) e insere os dados em uma lista de atributos na credencial do usuário. Esse seriço interno de autorização sobre atributos de credencial é um seriço de autorização genérico que pode ser utilizado por diersos gerenciadores de recursos. Ele assume o lugar de um método anterior que exigia que os administradores adicionassem entradas tag/alue à sub-rotina [ldap-ext-creds-tag] no arquio de configuração pdwebpi.conf. Na Versão 5.1, é necessário utilizar o seriço interno de autorização para obter dados do registro de usuários LDAP. Para obter informações de configuração, consulte Configuração do Seriço de Autorização Seriço personalizado de autorização sobre atributos de credencial Quando o seriço interno de autorização sobre atributos de credencial não consegue fornecer todas as informações necessárias para a sua implementação, ocê pode graar o seu próprio seriço de autorização sobre atributos de credencial. O Tioli Access Manager suporta esse recurso como parte da API de autorização. Para obter informações adicionais, consulte o documento IBM Tioli Access Manager for e-business Authorization C API Deeloper Reference. Seriço de autenticação externa com base em atributos estendidos (CDAS) O plug-in fornece uma interface API de autenticação externa que pode ser utilizada para desenoler seriços de autenticação externa. Esses seriços são comumente chamados de CDASs (cross-domain authentication serices). Você pode utilizar a API de autenticação externa do plug-in para desenoler o seu próprio seriço de autenticação externa. Ele pode ser utilizado quando a necessidade de obter informações sobre autenticação de usuários estende-se além das informações sobre autorizações. O uso de um CDAS de atributos estendidos de credencial é recomendado quando um aplicatio precisa acessar informações que estão disponíeis apenas no momento da autenticação ou quando o aplicatio precisa mapear um ID de usuário utilizado na autenticação para o ID de usuário do Tioli Access Manager. Para obter informações adicionais, consulte o documento IBM Tioli Access Manager for e-business Web Security: Referência para Desenoledores. Configuração do Seriço de Autorização Para configurar o seriços de autorização, conclua as instruções nas seções a seguir: Etapa 1 Determine os Atributos a serem Adicionados à Credencial na página 109 Etapa 2 Defina o Uso do Seriço de Autorização na página 109 Etapa 3 Especifique os Atributos a serem Adicionados à Credencial na página 109 108 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Etapa 1 Determine os Atributos a serem Adicionados à Credencial Cada atributo de usuário que ocê deseja adicionar à credencial de usuário dee ser definido em um arquio de configuração do Tioli Access Manager. Normalmente, isso é feito no arquio de configuração do plug-in. Vá para o registro de usuários do Tioli Access Manager (por exemplo, um registro de usuários LDAP). Crie uma lista dos nomes de cada entrada do registro de usuários que ocê deseja extrair com o uso do seriço de autorização sobre atributos de credencial e colocar na credencial de usuário. O DN do usuário e o DN do grupo também serão necessários. Etapa 2 Defina o Uso do Seriço de Autorização 1. Verifique se o seriço de autorização sobre atributos de credencial está configurado. A seguinte entrada padrão dee estar presente no arquio de configuração do plug-in: [aznapi-entitlement-serices] AZN_ENT_EXT_ATTR = azn_ent_ext_attr Obsere que o plug-in obtém automaticamente o alor azn_ent_ext_attr e localiza a biblioteca compartilhada correspondente. Por exemplo, no Solaris, libazn_ent_ext_attr.so 2. Adicione uma entrada de definição de seriço da API de autorização para especificar o uso do seriço de autorização. Adicione a entrada na sub-rotina [aznapi-configuration]. Essa entrada dee utilizar o parâmetro cred-attributes-entitlement-serices. É possíel escolher um alor, como TAM_CRED_ATTRS_SVC. Por exemplo: [aznapi-configuration ] cred-attributes-entitlement-serices = TAM_CRED_ATTRS_SVC Etapa 3 Especifique os Atributos a serem Adicionados à Credencial Os atributos a serem adicionados à credencial são configurados em diersas sub-rotinas. Adicione essas informações ao arquio de configuração do plug-in. Nota: Como alternatia, é possíel definir os atributos em um arquio separado, que será chamado pelo seriço de autorização. Para obter informações adicionais, consulte o documento IBM Tioli Access Manager for e-business Authorization C API Deeloper Reference. Reise o seguinte exemplo de entrada. [TAM_CRED_ATTRS_SVC] eperson = azn_cred_registry_id group = cn=enterprise, o=tioli [TAM_CRED_ATTRS_SVC:eperson] tagalue_credattrs_lastname = sn tagalue_credattrs_employeetype = employeetype tagalue_credattrs_address = homepostaladdress tagalue_credattrs_email = email [TAM_CRED_ATTRS_SVC:group] tagalue_credattrs_businesscategory = businesscategory O nome da sub-rotina [TAM_CRED_ATTRS_SVC] corresponde ao ID do Seriço. Dentro dessa sub-rotina, encontram-se as origens de atributos a serem recuperadas. Os nomes de origem, como o usuário e o grupo, são utilizados para identificar a Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 109

localização de origem no registro. Esses nomes deem ser definidos. Os alores para essas origens são identificadores de registro existentes no registro. Esses alores podem ser nomes de atributos de credencial existentes. Se esse for o caso, o seriço localizará e utilizará automaticamente os respectios alores. Em uma sub-rotina separada, configure os atributos de registro para cada uma das origens na sub-rotina de seriço. A sintaxe da sub-rotina separada corresponde ao nome da biblioteca de IDs de seriço acompanhado por dois pontos (:) e, em seguida, pelo nome da origem. Essa conexão é necessária porque é possíel configurar mais de um seriço no mesmo arquio. As entradas do arquio de configuração contêm mapeamentos de atributos do registro de usuários para atributos de credencial definidos pelo usuário. Por exemplo, em um registro de usuários LDAP, o DN de um usuário poderia ser cn=joeuser, o=tioli Para esse usuário, as entradas do registro de usuários LDAP poderiam ser: sn=smith employeetype=bankteller homepostaladdress="3004 Mission St Santa Cruz CA 95060" email=joeuser@bigco.com businesscategory=finance Com o uso dos exemplos de entradas de configuração acima, a lista de atributos retornada apresentaria as seguintes entradas: Nome do Atributo credattrs_lastname credattrs_employeetype Valor do Atributo Smith bankteller credattrs_address 3004 Mission St Santa Cruz CA 95060 credattrs_email credattrs_businesscategory joeuser@bigco.com finance Obsere que o seriço, a origem e os atributos podem ter ários alores. Se ocê especificar o mesmo nome de atributo como uma palara-chae de entrada de sub-rotina, os atributos recuperados serão adicionados como um atributo de ários alores, mesmo quando forem proenientes de diferentes origens. Por exemplo, é possíel incular em cadeia mais de um seriço de autorização. Isso permite que os alores recuperados de um seriço sejam utilizados como alores de entrada para outro seriço. Da mesma maneira, os atributos podem ser recuperados a partir de mais de um DN no registro de usuários. Dessa forma, com o uso do exemplo acima, seria possíel adicionar alores de ários usuários (DNs) a um atributo credattrs_businesscategory, se ocê desejasse uma lista de todas as entradas businesscategory para um grupo de usuários. Por exemplo, se ocê quiser construir um atributo denominado myemployeeinfo para adicioná-lo à credencial e se quiser que esse atributo contenha o sobrenome e o tipo de funcionário de todos os usuários que se autenticarem, será possíel definir o seguinte: 110 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

[myid] source = azn_cred_authzn_id [myid:source] myemployeeinfo = lastname myemployeeinfo = employeetype Adicionando Atributos Estendidos LDAP ao Cabeçalho HTTP (Valor de Marcação) Muitas ezes, é útil anexar informações específicas de usuários a partir do LDAP (por exemplo, telefone, endereço de e-mail) aos cabeçalhos de pedidos autenticados HTTP. Isso permite que ários aplicatios acessem as informações anexadas sem precisarem consultar constantemente o seridor LDAP. Essas informações são relatiamente estáticas e nunca são atualizadas por nenhum dos aplicatios que as utilizam. Esses dados são colocados na credencial do usuário como parte do processo de autenticação iauthn. Essas informações também podem ser anexadas à credencial do usuário por meio de um módulo de autenticação CDAS implementado pelo usuário. O fluxo de processo a seguir descree a seqüência de eentos: Os dados complementares definidos pelo usuário de qualquer campo da conta do registro LDAP de um usuário são adicionados como dados de atributos estendidos à credencial do Tioli Access Manager desse usuário. Quando configurado para processamento pós-autorização com base em alor de marcação, o plug-in extrai os dados de atributos estendidos LDAP e os coloca no cabeçalho HTTP do pedido. O aplicatio backend pode extrair esses dados do cabeçalho sem exigir um código especial ou a API de autorização. A configuração do plug-in para a inserção de informações de atributos estendidos LDAP em um cabeçalho HTTP enole as seguintes etapas: 1. Configure a pós-autorização com base em alor de marcação no Plug-in da Web. Consulte Atiando o Processamento com Base em Valor de Marcação na página 112 para obter detalhes sobre como fazer isso. 2. Adicione os atributos estendidos ao objeto /PDWebPI/host no Access Manager. Por exemplo (inserido como uma linha): pdadmin> object modify /PDWebPI/host set attribute HTTP-Tag-Value ldap-home-phone=homephone Também é possíel criar um noo CDAS de credencias estendidas do Tioli Access Manager e especificá-lo como um mecanismo de autenticação no plug-in. Por exemplo: 1. Defina o parâmetro cred-ext-attrs na sub-rotina [authentication-mechanisms] como o noo CDAS. Por exemplo (inserido como uma linha): [authentication-mechanisms] cred-ext-attrs = /opt/policydirector/lib/libextcredtags.so & /opt/pdwebpi/etc/pdwebpi.conf (o arquio de configuração padrão é pd.conf) 2. Edite pdwebpi.conf, adicione uma noa sub-rotina:[ldap-ext-attr-cdas-tags] e os atributos estendidos LDAP necessários. Por exemplo: [ldap-ext-attr-cdas-tags] ldap-home-phone = homephone 3. Inicie noamente o plug-in. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 111

4. Adicione os atributos estendidos ao objeto /PDWebPI/host no Tioli Access Manager. Por exemplo (inserido como uma linha): pdadmin> object modify /PDWebPI/host set attribute HTTP-Tag-Value ldap-home-phone=homephone Atiando o Processamento com Base em Valor de Marcação A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar o processamento utilizando alores de marcação, atribua a referência tag-alue ao parâmetro post-authzn: [common-modules] post-authzn = tag-alue A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e os respectios nomes das bibliotecas compartilhadas associadas. Assegure-se de que a entrada para o alor de marcação esteja presente, conforme mostrado a seguir: [modules] tag-alue = pdwpi-tag-alue-module Configurando Parâmetros de Valores de Marcação Os parâmetros de alores de marcação são configurados na sub-rotina [tag-alue] do arquio de configuração pdwebpi.conf. [tag-alue] cache-definitions = yes cache-refresh-interal = 60 O parâmetro cache-definitions atia ou desatia o armazenamento em cache das definições de alor de marcação anexadas ao espaço de objetos. O parâmetro cache-refresh-interal define o interalo de atualização, em segundos, para o cache de definições. Se necessário, é possíel configurar um prefixo a ser adicionado a nomes de atributos de credencial utilizados para cabeçalhos HTTP tag-alue. Esse prefixo: É utilizado como uma cadeia de pesquisa pelo módulo tag-alue ao pesquisar atributos de credencial. É adicionado ao atributo de credencial de ID de sessão. É adicionado pelo módulo switch-user ao atributo de credencial que ele utiliza para armazenar o nome de usuário do administrador. Especifique o prefixo utilizando o parâmetro tag-alue-prefix na sub-rotina [pdweb-plugins] do arquio de configuração do plug-in. Esse parâmetro pode ser substituído por um host irtual específico com o uso de uma sub-rotina [irtual_host] para esse host irtual. O comportamento padrão é não ter nenhum prefixo. Oferecendo Suporte para MPAs (Agentes Proxy de Multiplexação) O Tioli Access Manager fornece soluções para proteger redes que utilizam um MPA (Agente Proxy de Multiplexação). MPAs são gateways que acomodam o acesso de ários clientes. Os gateways estabelecem um único canal autenticado para o serido Web protegido e criam um túnel para todos os pedidos e respostas de clientes atraés desse canal. Para o plug-in, as informações nesse canal aparecem inicialmente como ários pedidos a partir de um cliente. O plug-in dee distinguir entre a autenticação do seridor MPA e a autenticação adicional de cada 112 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

cliente indiidual. Um exemplo comum desses gateways são gateways WAP (Wireless Access Protocol). O Tioli Access Manager WebSEAL também age como um MPA quando configurado com campos de junção para o seridor Web host de forma a possibilitar a conexão única entre o WebSEAL e o plug-in. Para configurar essa solução, é possíel o módulo de autenticação i-header. Consulte o Capítulo 5, Soluções de Conexão Única para a Web, na página 135 para obter detalhes adicionais sobre a configuração para a SSO. Métodos de Autenticação e Tipos de Dados de Sessão Válidos Como o Tioli Access Manager Plug-in para Web Serers mantém uma sessão autenticada para o MPA, ele dee manter simultaneamente sessões separadas para cada cliente. Portanto, os dados de sessão e o método de autenticação utilizados para o MPA deem ser diferentes dos dados de sessão e do método de autenticação utilizados pelo cliente. A tabela a seguir lista os tipos de sessão álidos para o MPA e o cliente: Tabela 15. Tipos de Dados de Sessão Válidos para o MPA Tipos de Sessão Válidos MPA para o plug-in ID da Sessão SSL Cabeçalho HTTP Cabeçalho BA Endereço IP Cookie Cliente para o plug-in Cabeçalho HTTP Cabeçalho BA Cookie O cliente não pode utilizar um ID de sessão SSL como o tipo de dados de sessão. Por exemplo, se o MPA utilizar um cabeçalho BA para o tipo de dados de sessão, as opções do cliente para o tipo de dados de sessão incluirão apenas Cabeçalho HTTP e Cookie. Se o MPA utilizar um cabeçalho HTTP para os dados de sessão, o cliente poderá utilizar um tipo diferente de cabeçalho HTTP. O cookie específico do seridor contém apenas informações de sessão; ele não contém informações de identidade. Se o suporte para o MPA estier atiado, o uso de IDs de sessão SSL para manter o estado de sessões será alterado. Normalmente, possuindo IDs de sessão SSL configurados para manter o estado de sessões, apenas o ID da sessão SSL é utilizado para manter sessões para clientes HTTPS. Para permitir que o MPA mantenha uma sessão com um ID de sessão SSL e para fazer com que os clientes mantenham sessões utilizando outro método, essa restrição é remoida. O método de autenticação utilizado pelo MPA para o plug-in dee ser diferente do método de autenticação utilizado pelo cliente para o plug-in. A tabela a seguir lista os métodos de autenticação álidos para o MPA e o cliente: Tabela 16. Tipos de Autenticação MPA Válidos Tipos de Autenticação Válidos MPA para o plug-in Autenticação Básica Formulários Token Cliente para o plug-in Autenticação Básica Formulários Token Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 113

Tabela 16. Tipos de Autenticação MPA Válidos (continuação) Tipos de Autenticação Válidos MPA para o plug-in Cabeçalho HTTP Certificado Endereço IP Cabeçalho HTTP Cliente para o plug-in Por exemplo, se o MPA utilizar a Autenticação Básica, as opções do cliente para métodos de autenticação incluirão Formulários, Token e Cabeçalho HTTP. Os métodos de autenticação com base em certificados e em endereço IP não são álidos para uso por parte do cliente. Normalmente, se a autenticação com base em Formulários (ou token) estier atiada para um transporte específico, a Autenticação Básica será automaticamente desatiada para esse transporte. Se o suporte para o MPA estier atiado, essa restrição será remoida. Isso permite que o MPA efetue logon, por exemplo, com Formulários (ou token) e que os clientes efetuem logon com a Autenticação Básica por meio do mesmo transporte. Fluxo do Processo de Autenticação para o MPA e Vários Clientes O fluxo de processo a seguir ocorre para a autenticação do MPA e de ários clientes. 1. Faça as seguintes alterações de configuração: Atie o suporte para Agentes Proxy de Multiplexação no arquio de configuração. Crie uma conta do Tioli Access Manager para o gateway MPA específico. Conceda o acesso Proxy ([PDWebPI]p) para essa conta ao Objeto Protegido MPA do host irtual para o qual os pedidos em proxy serão direcionados. Na configuração padrão, isso pode ser feito transformando o usuário em um membro do grupo pdwebpi-mpa-serers. 2. Os clientes conectam-se ao gateway MPA. 3. O gateway conerte o pedido em um pedido HTTP. 4. O gateway autentica o cliente. 5. O gateway estabelece uma conexão com o plug-in utilizando o pedido do cliente. 6. O MPA se autentica no plug-in (utilizando um método diferente do cliente) e uma identidade é deriada para esse MPA (que já possui uma conta do plug-in). 7. O plug-in erifica a associação do MPA no grupo pdwebpi-mpa-serers. 8. Uma credencial é construída para o MPA e sinalizada como um tipo de MPA especial no cache. Embora essa credencial do MPA acompanhe cada pedido posterior dos clientes, ela não é utilizada para erificações de autorização nesses pedidos. 9. Nesse ponto, o plug-in precisa identificar mais detalhadamente o proprietário do pedido. O MPA é capaz de diferenciar os ários clientes para o roteamento correto de prompts de logon. 10. O cliente efetua login e se autentica utilizando um método diferente do tipo de autenticação utilizado para o MPA. 114 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

11. O plug-in constrói uma credencial a partir dos dados de autenticação do cliente. 12. O tipo de dados de sessão utilizado por cada cliente dee ser diferente do tipo de dados de sessão utilizado pelo MPA. 13. O Authorization Serer permite ou nega acesso aos objetos protegidos com base na credencial do usuário e nas permissões de ACL do objeto. Atiando a Autenticação MPA O parâmetro mpa-enabled na sub-rotina [pdweb-plugins] do arquio de configuração pdwebpi.conf atia ou desatia a autenticação MPA. As definições álidas são true e false para atiar e desatiar a autenticação MPA, respectiamente. A autenticação MPA é desatiada por padrão. Ela pode ser definida para hosts irtuais indiiduais por meio da especificação do parâmetro mpa-enabled na sub-rotina [irtual_host] do arquio de configuração. Para identificar uma noa sessão como sendo a sessão principal estabelecida por um MPA, é feita uma decisão de autorização testando a permissão Proxy ([PDWebPI]p) sobre o objeto protegido MPA. Por padrão, o objeto protegido MPA é definido para ser /PDWebPI. Para substituir essa definição padrão, por exemplo, de forma a definir diferentes conjuntos de responsáeis como representantes de MPAs para cada host irtual, um alor pode ser especificado para o parâmetro de configuração mpa-protected-object. Esse parâmetro pode ser substituído para cada host irtual por meio da especificação de um alor na sub-rotina [irtual_host] do arquio de configuração. Por exemplo, para atiar o acesso do MPA ao host irtual ibm.com, mas não ao host irtual lotus.com, utilize as definições a seguir no arquio de configuração pdwebpi.conf: [pdmweb-plugins] irtual-host = ibm.com irtual-host = lotus.com [ibm.com] mpa-enabled = yes Para definir membros do grupo ibm-mpa-serers como sendo MPAs para pedidos ao host irtual ibm.com e do grupo lotus-mpa-serers como sendo MPAs para pedidos ao host irtual lotus.com, utilize a seguinte configuração: [pdweb-plugins] irtual-host = ibm.com irtual-host = lotus.com [ibm.com] mpa-enabled = yes mpa-protected-object = /PDWebPI/ibm.com [lotus.com] mpa-enabled = yes mpa-protected-object = /PDWebPI/lotus.com e defina o seguinte critério do Tioli Access Manager: pdadmin> acl create ibm-mpa pdadmin> acl modify ibm-mpa set group ibm-mpa-serers T[PDWebPI]p pdadmin> acl create lotus-mpa pdadmin> acl modify lotus-mpa set group lotus-mpa-serers T[PDWebPI]p pdadmin> acl attach /PDWebPI/ibm.com ibm-mpa pdadmin> acl attach /PDWebPI/lotus.com lotus-mpa O parâmetro de configuração mpa-protected-object especifica o objeto com base no qual a decisão de autorização será tomada. Capítulo 3. Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers 115

Crie uma Conta de Usuário para o MPA Consulte os documentos IBM Tioli Access Manager Base: Guia de Administração e IBM Tioli Access Manager Web Portal Manager: Guia de Administração para obter informações sobre como criar contas de usuário. Adicione a Conta do MPA ao Grupo pdwebpi-mpa-serers O Tioli Access Manager Plug-in para Web Serers cria um grupo para facilitar a administração de seridores MPA. Esse grupo é denominado pdwebpi-mpaserers. A ACL default-pdwebpi anexada a /PDWebPI concede a permissão Proxy ([PDWebPI]p) aos membros do grupo pdwebpi-mpa-serers. Quando instalada em um domínio protegido do Tioli Access Manager que possua pelo menos um WebSEAL configurado, a ACL default-pdwebpi é configurada de forma a também conceder a permissão Proxy aos membros dos grupos webseal-serers e webseal-mpa-serers. Você pode escolher seus próprios grupos e suas próprias ACLs utilizados para controlar a identificação de responsáeis como MPAs. Consulte os documentos IBM Tioli Access Manager Base: Guia de Administração e IBM Tioli Access Manager Web Portal Manager: Guia de Administração para obter informações sobre como gerenciar grupos. 116 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Capítulo 4. Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers Este capítulo contém informações que descreem como é possíel configurar e personalizar o critério de segurança do IBM Tioli Access Manager (Tioli Access Manager) Plug-in para Web Serers. Este capítulo inclui os seguintes tópicos: Critérios ACL (Lista de Controle de Acesso) Específicos do Plug-in Três Critérios de Logon de Orientação na página 120 Critério de Intensificação de Senha na página 122 Critério de Objetos Protegidos de Intensificação da Autenticação (Progressão) na página 125 Autenticação com Base em Multifatores na página 128 Critério de Objetos Protegidos de Reautenticação na página 129 Critério de Objetos Protegidos de Autenticação com Base em Rede na página 130 Critério de Objetos Protegidos de Qualidade de Proteção na página 132 Tratando Usuários Não Autenticados (HTTP/HTTPS) na página 132 Critérios ACL (Lista de Controle de Acesso) Específicos do Plug-in As seguintes considerações sobre segurança aplicam-se para o contêiner /PDWebPI no espaço de objetos protegidos: O objeto Tioli Access Manager Plug-in para Web Serers inicia a cadeia de herança para a região de plug-in do espaço de objetos. Se ocê não aplicar nenhuma outra ACL explícita, esse objeto definirá (por meio da herança) o critério de segurança para todo o espaço da Web. A permissão Atraessar é necessária para o acesso a esse objeto e a qualquer objeto abaixo desse ponto. Consulte o documento IBM Tioli Access Manager Base: Guia do Administrador para obter informações completas sobre critérios ACL do Tioli Access Manager. Nota: O Microsoft IIS Web Serer oferece a capacidade de especificar uma página da Web padrão em um diretório que é exibida quando um pedido de usuário contém um URL que inclui apenas o caminho do diretório. A erificação de ACL executada pelo Plug-in para Web Serers somente se aplica ao diretório especificado no URL do pedido e não à página da Web padrão atendida pelo IIS Serer em resposta a esse pedido. É necessário incorporar essa limitação da erificação de ACL ao implementar o critério de segurança em plataformas IIS. De forma semelhante, deido à natureza da arquitetura do Plug-in para Web Serers, não há nada que impeça ocê de instalar outros módulos que sejam conflitantes com a segurança fornecida pelo plug-in. O administrador do Copyright IBM Corp. 2000, 2003 117

seridor Web é responsáel por assegurar que nenhum módulo conflitante com o plug-in seja instalado nesse seridor. Por exemplo, a funcionalidade MultiViews no Apache Web Serer e no IHS Web Serer tenta determinar dinamicamente a extensão do URL solicitado. Por exemplo, quando um pedido for feito a www.tioli.com/index, o seridor Web poderia mapear dinamicamente esse pedido a www.tioli.com/index.html se esse arquio existisse. Infelizmente, esse mapeamento apenas ocorre após a conclusão da autorização, ou seja, a erificação de autorização é realizada em index e não em index.html. Nessas situações, coném desatiar a opção MultiViews ou que o critério seja configurado para capturar esse mapeamento. Por exemplo, uma ACL poderia ser anexada a /PDWebPI/www.tioli.com, ou, se uma granularidade maior fosse necessária, a ACL poderia ser anexada a /PDWebPI/www.tioli.com/index e a /PDWebPI/www.tioli.com/index.html. /PDWebPI/host ou irtual_host A subárore /PDWebPI/host ou irtual_host contém o espaço de objetos de uma instância de plug-in específica. As seguintes considerações de segurança aplicam-se para esse objeto: A permissão Atraessar é necessária para o acesso a qualquer objeto abaixo desse ponto. Se ocê não aplicar nenhuma outra ACL explícita, esse objeto definirá (por meio da herança) o critério de segurança para todo o espaço de objetos dessa máquina. 118 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Permissões de ACL do Plug-in A tabela a seguir descree as permissões de ACL aplicáeis para a região do espaço de objetos do Tioli Access Manager Plug-in para Web Serers: Tabela 17. Permissões de ACL do Plug-in Permissão Operação Descrição [PDWebPI]r ler Exibir qualquer elemento que não seja um diretório. Qualquer pedido HTTP GET ou POST requer essa permissão. Não existe uma permissão de lista específica para solicitar uma lista de diretórios (um GET de URL terminando com /). [PDWebPI]d excluir Remoer o objeto da Web do espaço da Web. Comandos HTTP DELETE requerem essa permissão. [PDWebPI]m modificar Colocar/publicar um objeto HTTP no espaço de objetos do plug-in. Um pedido HTTP PUT requer essa permissão. [PDWebPI]p proxy Determina se um usuário pode ou não agir como um agente proxy de multiplexação. Consulte Adicione a Conta do MPA ao Grupo pdwebpi-mpa-serers na página 116 para obter mais detalhes. T atraessar Necessário para o acesso a qualquer objeto abaixo desse ponto. O plug-in também suporta operações WebDAV, conforme mostrado a seguir. Tabela 18. Permissões WebDAV do Plug-in Tarefa PROPFIND PROPPATCH MKCOL [PDWebPI]R [PDWebPI]M [PDWebPI]N Permissão Necessária As operações WebDAV são autorizadas com base no URI do pedido e não em membros indiiduais de uma coleta. Além disso, algumas outras operações WebDAV são parcialmente suportadas: COPY - Requer [PDWebPI]R na coleta de forma que copy from possa ser lido. As permissões para o destino não são erificadas. MOVE - Essa operação é considerada uma cópia e, em seguida, uma exclusão. Requer [PDWebPI]Rd na coleta a partir da qual ocê está se moendo. As permissões para o destino não são erificadas. Critério ACL /PDWebPI Padrão As principais entradas para a ACL do Tioli Access Manager Plug-in para Web Serers, default-pdwebpi, incluem: Group i-admin User sec_master Any-other TcmdbsaBR[PDWebPI]rR cmdbsabr[pdwebpi]rr T[PDWebPI]rR Capítulo 4. Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers 119

Unauthenticated Group pdwebpi-mpa-serers Group webseal-serers Group webseal-mpa-serers T TBR[PDWebPI]p TBR[PDWebPI]p TBR[PDWebPI]p No momento da instalação, essa ACL padrão é anexada ao objeto Contêiner /PDWebPI no espaço de objetos. A permissão Atraessar permite a expansão do espaço da Web conforme é representado no Web Portal Manager. A permissão Listar permite que o Web Portal Manager exiba o conteúdo do espaço da Web. Três Critérios de Logon de Orientação Os três critérios de logon de orientação, disponíeis para instalações do Tioli Access Manager baseadas em LDAP, permitem impedir ataques a senhas de computadores especificando um número máximo de tentatias falhas de logon e um tempo de bloqueio de punição. O critério cria uma condição na qual um usuário dee esperar um período de tempo antes de fazer mais tentatias de logon que falham. Por exemplo, um critério pode ditar 3 tentatias falhas seguidas por uma punição de 180 segundos. Esse tipo de critério de logon pode eitar tentatias aleatórias de logon geradas por computador que ocorrem muitas ezes por segundo. Os três critérios de logon de orientação requerem a contribuição de conjunção de duas definições de comandos de critérios pdadmin: Número máximo de tentatias falhas de logon policy set max-login-failures Punição por exceder a definição de tentatia falha de logon policy set disable-time-interal A definição da punição pode incluir um interalo de tempo de bloqueio da conta ou uma desatiação completa da conta. Se um critério de logon for definido (por exemplo) para três tentatias falhas seguidas por uma punição de tempo de bloqueio específica, uma quarta tentatia (correta ou incorreta) resultará em uma página de erros que declara que a conta está temporariamente não disponíel deido ao critério de senha. O interalo de tempo é especificado em segundos - o interalo de tempo mínimo recomendado é de 60 segundos. Se o critério disable-time-interal for definido como disable, o usuário terá a conta bloqueada e o atributo account alid de LDAP para este usuário será definido como no. Um administrador reatia a conta atraés do Web Portal Manager. Nota: Definir o disable-time-interal como disable resulta em um oerhead adicional de administração. Podem ocorrer atrasos ao replicar informações de account alid para o plug-in. Essa situação depende do ambiente de LDAP. Além disso, algumas implementações de LDAP podem ter uma diminuição de desempenho como resultado da operação de atualização de account alid. Por essas razões, é recomendado utilizar um interalo de 120 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

tempo limite. Capítulo 4. Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers 121

Os comandos pdadmin a seguir são apropriados apenas para uso com um registro LDAP. Tabela 19. Comandos de Critério de Logon LDAP pdadmin Comando policy set max-login-failures {number unset} [-user username] policy get max-login-failures [-user username] Descrição Gerencia o critério controlando o número máximo de tentatias falhas de logon permitidas antes que uma punição seja imposta. Esse comando depende de uma punição definida no comando disable-time-interal do conjunto de critérios. Como administrador, ocê pode aplicar este critério a um usuário específico ou aplicar o critério globalmente a todos os usuários listados no registro LDAP. A definição padrão é de 10 tentatias. policy set disable-time-interal {number unset disable} [-user username] policy get disable-time-interal [-user username] Gerencia o critério de punições controlando o período de tempo que uma conta deerá ficar desatiada se o número máximo de tentatias falhas de logon for atingido. Como administrador, ocê pode aplicar este critério de punição a um usuário específico ou aplicar o critério globalmente a todos os usuários listados no registro LDAP. A definição padrão é de 180 segundos. Critério de Intensificação de Senha Uma instalação com base em LDAP do Tioli Access Manager oferece duas maneiras de controlar a construção de senhas: Cinco comandos de critério de senha pdadmin Um PAM (Plugable Authentication Module) que permite personalizar um critério de senha Consulte o documento Tioli Access Manager Authorization C API Deeloper s Reference Critério de Intensificação de Senha Definido pelo Utilitário pdadmin Os cinco atributos de intensificação de senha implementados pelo utilitário pdadmin incluem: Comprimento mínimo da senha Mínimo de caracteres alfabéticos Mínimo de caracteres não alfabéticos Máximo de caracteres repetidos Espaços permitidos 122 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Esses critérios são impostos quando ocê cria um usuário com o pdadmin ou o Web Portal Manager e quando uma senha é alterada com o pdadmin, o Web Portal Manager ou o utilitário pkmspasswd. Os seguintes comandos pdadmin são apropriados para uso apenas com um registro LDAP. A opção unset desatia esse atributo de critério ou seja, o critério não é imposto. Tabela 20. Comandos de Intensificação de Senha LDAP pdadmin Comando policy set min-password-length {number unset} [-user username] policy get min-password-length [-user username] Descrição Gerencia o critério que controla o comprimento mínimo de uma senha. Como administrador, ocê pode aplicar esse critério a um usuário específico ou aplicá-lo globalmente a todos os usuários listados no registro padrão. A definição padrão é 8. policy set min-password-alphas {number unset} [-user username] policy get min-password-alphas [-user username] Gerencia o critério que controla o número mínimo de caracteres alfabéticos permitidos em uma senha. Como administrador, ocê pode aplicar esse critério de punição a um usuário específico ou aplicá-lo globalmente a todos os usuários listados no registro padrão. A definição padrão é 4. policy set min-password-non-alphas {number unset} [-user username] policy get min-password-non-alphas [-user username] Gerencia o critério que controla o número mínimo de caracteres não alfabéticos (numéricos) permitidos em uma senha. Como administrador, ocê pode aplicar esse critério a um usuário específico ou aplicá-lo globalmente a todos os usuários listados no registro padrão. A definição padrão é 1. policy set max-password-repeated-chars {number unset} [-user username] policy get max-password-repeated-chars [-user username] Gerencia o critério que controla o número máximo de caracteres repetidos permitidos em uma senha. Como administrador, ocê pode aplicar esse critério a um usuário específico ou aplicá-lo globalmente a todos os usuários listados no registro padrão. A definição padrão é 2. policy set password-spaces {yes no unset} [-user username] policy get password-spaces [-user username] Capítulo 4. Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers 123

Tabela 20. Comandos de Intensificação de Senha LDAP pdadmin (continuação) Comando Descrição Gerencia o critério que controla se uma senha pode ou não conter espaços. Como administrador, ocê pode aplicar esse critério a um usuário específico ou aplicá-lo globalmente a todos os usuários listados no registro padrão. A definição padrão é unset. A tabela a seguir ilustra ários exemplos de senha e os resultados de critérios com base nos alores padrão dos cinco parâmetros pdadmin: Tabela 21. Exemplos de Senhas password pass passs1234 Exemplo Resultado Não álida: dee conter pelo menos um caractere não alfabético. Não álida: dee conter pelo menos 8 caracteres. Não álida: contém mais de dois caracteres repetidos. 12345678 Não álida: dee conter pelo menos quatro caracteres alfabéticos. password3 Válida. Definições Globais e Específicas do Usuário Os comandos de critério pdadmin podem ser definidos para um usuário específico (com a opção - user) ou globalmente (sem o uso da opção - user). Qualquer definição específica do usuário substitui uma definição global para o critério. Também é possíel desatiar (desfazer a definição) de um parâmetro de critério, significando que esse parâmetro não contém nenhum alor. Nenhum critério com a opção unset é erificado ou imposto. Por exemplo: pdadmin> policy set min-password-length 8 pdadmin> policy set min-password-length 4 -user matt pdadmin> policy get min-password-length Minimum password length: 8 pdadmin> policy get min-password-length -user matt Minimum password length: 4 O usuário matt possui um critério de comprimento mínimo de senha de 4 caracteres; todos os outros usuários possuem um critério de comprimento mínimo de senha de 8 caracteres. pdadmin> policy set min-password-length unset -user matt O usuário matt agora é controlado pelo critério global de comprimento mínimo de senha de 8 caracteres. pdadmin> policy set min-password-length unset Agora, todos os usuários, incluindo o usuário matt, não possuem um critério de comprimento mínimo de senha. 124 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Critério de Objetos Protegidos de Intensificação da Autenticação (Progressão) O POP (Critério de Objetos Protegidos) de intensificação da autenticação possibilita controlar o acesso a objetos com base no método de autenticação que eles utilizam. Você pode utilizar essa funcionalidade às ezes conhecida como autenticação progressia para assegurar que os usuários que acessam recursos mais sensíeis utilizem um mecanismo de autenticação mais eficiente. Coném utilizar essa condição deido à maior ameaça de acesso impróprio. Por exemplo, é possíel oferecer mais segurança a uma região do espaço da Web aplicando um critério POP progressio que exija um níel de autenticação mais forte em comparação ao utilizado pelo cliente ao entrar inicialmente no domínio do plug-in. A autenticação progressia também pode ser definida para cada host irtual específico em um seridor Web, possibilitando que hosts irtuais indiiduais transmitam seus próprios níeis de autenticação progressia sem estarem sujeitos a implementações de critérios para o seridor inteiro. O critério de intensificação da autenticação é definido no atributo IP Endpoint Authentication Method de um critério POP. Configurando Níeis para a Autenticação Progressia A primeira etapa da configuração de um acesso específico para uma autenticação é configurar os métodos de autenticação suportados e determinar a ordem na qual esses métodos de autenticação deem ser considerados mas fortes. Consulte o Capítulo 3, Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers, na página 41 para obter detalhes sobre como configurar mecanismos de autenticação. Qualquer cliente que acesse um seridor Web por meio do plug-in possui um níel de autenticação, como não autenticado ou senha, que indica o método pelo qual esse cliente se autenticou pela última ez por meio do plug-in. Em alguma situações, pode ser necessário impor níeis de autenticação de segurança mínima necessários para acessar determinados objetos do espaço da Web. Por exemplo, em um ambiente, a autenticação com base em código de acesso de token pode ser considerada mais segura que a autenticação com base em nome de usuário e senha. Outro ambiente pode ter padrões diferentes. Em ez de forçar os clientes a iniciarem noamente suas sessões quando eles não atenderem ao níel de autenticação necessário, o mecanismo de autenticação progressia oferece a esses clientes uma segunda chance de reautenticação com o uso do método (níel) necessário. A autenticação progressia implica que os usuários não isualizam imediatamente uma mensagem de acesso negado ( denied ) quando tentam acessar um recurso que exige um níel de autenticação mais alto em comparação ao que foi utilizado para efetuar logon. Em ez disso, eles recebem um prompt de noa autenticação que solicita informações para suportar o níel de autenticação mais alto. Se foram capazes de fornecer esse níel de autenticação, o seus pedidos originais serão permitidos. Capítulo 4. Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers 125

Os níeis de autenticação são configurados na sub-rotina [authentication-leels] ou [authentication-leels:irtual_host_label] do arquio de configuração pdwebpi.conf. Por exemplo: [authentication-leels] 1 = BA 2 = i-headers 3 = cert Com base na ordem dos métodos na lista, cada método é atribuído com um índice de níel. Não autenticado é considerado como portador de um níel 0. Os métodos subseqüentes podem ser colocados em qualquer ordem. Consulte a seção Notas e Limitações da Autenticação Progressia na página 127 Dee haer pelo menos duas entradas para atiar para autenticação progressia. Os níeis para mecanismos de autenticação podem ser definidos para hosts irtuais específicos por meio da especificação desses níeis com o uso de uma sub-rotina com o formato: [authentication-leels:irtual_host_name]. Nota: Consulte o Capítulo 3, Processamento de Pedidos e de Autenticações do IBM Tioli Access Manager Plug-in para Web Serers, na página 41 para obter informações detalhadas sobre como configurar os mecanismos de autenticação necessários. Atiando a Autenticação Progressia A autenticação progressia é implementada com o uso de um critério POP colocado nos objetos que requerem uma autorização sensíel à autenticação. É utilizado o atributo IP Endpoint Authentication Method de um critério POP. O comando pdadmin pop modify set ipauth especifica as redes permitidas e o níel de autenticação necessário no atributo IP Endpoint Authentication Method. Os níeis de autenticação configurados podem ser inculados a faixas de endereços IP. Esse método foi planejado para fornecer flexibilidade de gerenciamento. Se a filtragem de usuários por endereço IP não for importante, ocê poderá definir uma única entrada para anyothernw (qualquer outra rede). Essa definição afetará todos os usuários de acesso, independentemente do endereço IP, e exigirá que eles sejam autenticados no níel especificado. Esse é o método mais comum para implementar a autenticação progressia. Sintaxe: pdadmin> pop modify pop_name set ipauth anyothernw leel_index A entrada anyothernw é utilizada como uma faixa de redes que corresponderá a qualquer rede não especificada no POP. Esse método é utilizado para criar uma entrada padrão que poderia negar todos os endereços IP não correspondidos ou permitir o acesso para todos que atenderem ao requisito de níel de autenticação. Por padrão, anyothernw aparece em um POP com um índice 0 de níel de autenticação. A entrada aparece como Any Other Network (Qualquer Outra Rede) no comando pop show: pdadmin> pop show test Protected object policy: test Description: Test POP Warning: no Audit leel: none 126 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Quality of protection: none Time of day access: sun, mon, tue, wed, thu, fri, sat: anytime:local IP Endpoint Authentication Method Policy Any Other Network 0 Durante a autenticação progressia, a alidação do ID do usuário fornecido pode ser atiada definindo o parâmetro erify-step-up-user na sub-rotina [module-mgr] como true. [module-mgr] erify-step-up-user = true A atiação do parâmetro erify-step-up-user assegura que, quando solicitada a se reautenticar utilizando um mecanismo de níel mais alto, a identidade inserida corresponda à identidade originalmente inserida. Se as identidades não corresponderem, uma página 403 Forbidden (403 Proibido) será retornada. Exemplo de Autenticação Progressia 1. Configure níeis de autenticação no arquio de configuração pdwebpi.conf: [authentication-leels] or [authentication-leels:irtual_host_label] 1 = BA 2 = token 2. Configure o atributo POP IP Endpoint Authentication Method: pdadmin> pop modify test set ipauth anyothernw 2 pdadmin> pop show test Protected object policy: test Description: Test POP Warning: no Audit leel: none Quality of protection: none Time of day access: mon, wed, fri:anytime:local IP Endpoint Authentication Method Policy Any Other Network 2 Portanto, os usuários que acessarem objetos protegidos pelo POP de teste necessitarão de uma autenticação níel 2 ou serão forçados a se autenticarem com o método de token. Consulte também Critério de Objetos Protegidos de Autenticação com Base em Rede na página 130. Notas e Limitações da Autenticação Progressia A autenticação progressia é suportada ia HTTP e HTTPS. Não é possíel fazer a progressão a partir do protocolo HTTP para o HTTPS. Os métodos de autenticação não especificados na sub-rotina [authentication-leels] assumirão como padrão o níel 1. Os métodos de autenticação podem ser especificados apenas uma ez na lista de níeis. O SPNEGO não faz a progressão para nenhum método de autenticação que utiliza formulários POST. A configuração do comportamento de progressão com o uso do módulo de autenticação SPNEGO resulta em uma página de erro exibida ao cliente. A configuração incorreta de níeis de autenticação progressia resulta na desatiação da funcionalidade de progressão do plug-in. Essa situação pode gerar um comportamento de autenticação inesperado, como a emissão da página de logon por senha para objetos protegidos por um POP que requer o método de autenticação com base em código de acesso de token. Capítulo 4. Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers 127

Após a configuração de mecanismos de autenticação progressia, erifique se existem relatórios de qualquer erro de configuração no arquio pdwebpi.log. Autenticação com Base em Multifatores A funcionalidade da autenticação com base em multifatores é uma extensão da funcionalidade da autenticação progressia que permite especificar um POP que força o usuário a se autenticar utilizando todos os mecanismos de autenticação com um níel mais baixo que o níel de autenticação POP configurado. Ou seja, o usuário precisa estar autenticado em todos os níeis até, e incluindo, o níel necessário de forma que o acesso seja concedido. A autenticação com base em multifatores também pode ser utilizada em conjunto com a reautenticação para forçar uma reautenticação com base em multifatores. A autenticação com base em níeis de autenticação padrão permite que um critério seja associado a um objeto que define um níel mínimo de autenticação necessário que dee ser alcançado de forma que o acesso seja concedido. Os mecanismos de autenticação suportados recebem uma ordem na configuração que especifica quais mecanismos são considerados mais fortes que os outros. Quando um usuário se autentica pela primeira ez para acessar um objeto, ele tem a oportunidade de escolher todos os métodos de autenticação que atendam ao níel necessário para esse objeto. Cabe a esse usuário escolher o método que será utilizado. Para realizar a autenticação com base em multifatores, a autenticação progressia precisa estar configurada, conforme discutido em Critério de Objetos Protegidos de Intensificação da Autenticação (Progressão) na página 125. Após a configuração da autenticação progressia, será necessário adicionar o atributo estendido MULTI-FACTOR-AUTH a um POP para um ou mais objetos do Tioli Access Manager Plug-in para Web Serers. Quando o atributo MULTI-FACTOR-AUTH é definido, todos os níeis de autenticação, até o níel de autenticação POP especificado, são necessários de forma que o acesso ao recurso seja concedido. Por exemplo, suponha que a seguinte configuração esteja definida no arquio de configuração: [authentication-leels] 1 = cert 2 = forms Com a configuração acima, quando um POP anexado a um recurso que requer um níel 2 de autenticação e quando o noo atributo MULTI-FACTOR-AUTH está definido como true, o usuário dee primeiramente fornecer um certificado de cliente álido antes de inserir um logon com base em formulários. Se o POP anexado ao recurso não tier o atributo MULTI-FACTOR-AUTH atiado, apenas a autenticação com base em formulários será utilizada. Atiando a Autenticação com Base em Multifatores A autenticação com base em multifatores é implementada com o uso de um critério POP colocado nos objetos que requerem uma autenticação com base em multifatores. Sintaxe: pdadmin> pop modify pop_name set attribute MULT-FACTOR_AUTH true 128 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Critério de Objetos Protegidos de Reautenticação O Tioli Access Manager Plug-in para Web Serers pode forçar um usuário a efetuar um logon adicional (reautenticação) de forma a assegurar que um usuário que está acessando um recurso protegido seja a mesma pessoa que se autenticou inicialmente no começo da sessão. A reautenticação pode ser atiada por um POP (Critério de Objetos Protegidos) no objeto protegido ou pela expiração do alor de tempo limite de inatiidade do cache de sessão. Esta seção discute a reautenticação com base em um critério de segurança, conforme determinado por um atributo estendido POP. Consulte Configurando o Cache de Sessão/Credenciais do Plug-in na página 53 para obter detalhes sobre como configurar o Cache de Sessão/Credenciais. Condições que Afetam a Reautenticação POP A reautenticação forçada oferece proteção adicional para recursos sensíeis no domínio protegido. A reautenticação com base em um critério de segurança é atiada por um atributo estendido específico em um POP que protege o objeto do recurso solicitado. O POP pode ser diretamente anexado ao objeto ou o objeto pode herdar as condições POP de um objeto pai. A reautenticação é suportada pelos seguintes métodos de autenticação do plug-in: Autenticação com base em formulários (nome do usuário e senha) Autenticação com base em token Além disso, um CDAS personalizado com base em nome de usuário/senha pode ser graado para suportar a reautenticação. A reautenticação assume que o usuário tenha inicialmente efetuado login no domínio seguro e que uma credencial álida exista para esse usuário. Durante a reautenticação, o usuário dee efetuar logon utilizando a mesma identidade que gerou a credencial existente. O Tioli Access Manager presera as informações da sessão original do usuário, incluindo a credencial, durante a reautenticação. Essa credencial não é substituída durante a reautenticação. Durante a reautenticação, o plug-in também armazena em cache o pedido que solicitou essa reautenticação. Após a reautenticação bem-sucedida, os dados armazenados em cache são utilizados para reconstruir o pedido. Se a reautenticação falhar, o plug-in retornará o prompt de logon. Se a reautenticação for bem-sucedida, mas a erificação de ACL falhar para esse recurso, uma mensagem 403 Forbidden (403 Proibido) será retornada, e o usuário terá o acesso negado ao recurso solicitado. Em qualquer um dos casos, o usuário nunca efetua logoff. Com o uso de uma credencial ainda álida, esse usuário pode finalizar o processo de reautenticação (solicitando outro URL) e ainda participar do domínio protegido acessando outros recursos que não requerem reautenticação. Criando e Aplicando o POP de Reautenticação A reautenticação forçada com base em um critério de segurança é configurado por meio da criação de um POP com um atributo estendido especial denominado reauth. É possíel anexar esse POP a qualquer objeto que exija a proteção extra fornecida pela reautenticação forçada. Lembre-se de que todos os filhos do objeto com o POP também herdarão as condições desse POP. Cada objeto filho solicitado requer uma reautenticação separada. Capítulo 4. Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers 129

Utilize os comandos pdadmin pop create, pdadmin pop modify e pdadmin pop attach. O exemplo a seguir ilustra a criação de um POP denominado secure com o atributo estendido reauth e a anexação desse POP a um objeto: pdadmin>pop create secure pdadmin>pop modify secure set attribute REAUTH true pdadmin>pop attach /PDWebPI/hostA/budget.html secure Qualquer usuário que tentar acessar budget.html será forçado a se reautenticar utilizando a mesma identidade e o mesmo método de autenticação que gerou a credencial existente. Se o usuário que está solicitando o recurso não estier autenticado, o POP forçará esse usuário a se autenticar. A reautenticação é necessária para qualquer acesso a objetos protegidos por um critério de reautenticação. Em situações nas quais a maioria dos objetos, mas nem todos, em um diretório requer reautenticação, coném anexar um POP ao diretório inteiro, incluindo o atributo estendido reauth. Para os objetos que não requerem autenticação, anexe um POP que seja idêntico ao POP para o diretório, mas exclua o atributo estendido reauth. Detalhes sobre o utilitário de linha de comandos pdadmin podem ser encontrados no documento IBM Tioli Access Manager Base: Guia do Administrador. Critério de Objetos Protegidos de Autenticação com Base em Rede O POP (Critério de Objetos Protegidos) de autenticação com base em rede possibilita controlar o acesso a objetos com base no endereço IP do usuário. É possíel utilizar essa funcionalidade para preenir que endereços IP específicos (ou faixas de endereços IP) acessem qualquer recurso no domínio protegido. Também é possíel aplicar a configuração de autenticação progressia a esse critério e exigir um método de autenticação específico para cada faixa de endereços IP determinada. O critério de autenticação com base em rede é definido no atributo IP Endpoint Authentication Method de um critério POP. Você dee especificar dois requisitos nesse atributo: Níeis de autenticação Redes permitidas Para obter detalhes sobre como especificar níeis de configuração, consulte Configurando Níeis para a Autenticação Progressia na página 125. Especificando Faixas e Endereços IP Depois de configurar os níeis de autenticação, é necessário especificar os endereços IP e as faixas de endereços IP permitidos por esse critério POP. O comando pdadmin pop modify set ipauth add especifica a rede (ou a faixa de redes) e o níel de autenticação necessário no atributo IP Endpoint Authentication Method. Sintaxe: pdadmin> pop modify pop_name set ipauth add network netmask leel_index 130 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Os níeis de autenticação configurados podem são inculados a faixas de endereços IP. Esse método foi planejado para fornecer flexibilidade. Se a filtragem de usuários por endereço IP não for importante, ocê poderá definir uma única entrada para anyothernw (qualquer outra rede). Essa definição afeta todos os usuários de acesso, independentemente do endereço IP, e exige que eles sejam autenticados no níel especificado. Sintaxe: pdadmin> pop modify pop_name set ipauth anyothernw leel_index De maneira oposta, se ocê quiser ignorar o níel de autenticação e quiser permitir ou negar o acesso com base apenas no endereço IP, poderá utilizar o níel 0 para as faixas que deseja permitir e forbidden (proibido) para as faixas que deseja negar. A entrada anyothernw é utilizada como uma faixa de redes que corresponde a qualquer rede não especificada no POP. Esse método pode ser utilizado para criar uma entrada padrão que poderia negar todos os endereços IP não correspondidos ou permitir o acesso para todos que atenderem ao requisito de níel de autenticação. Por padrão, anyothernw aparece em um POP com um índice 0 de níel de autenticação. A entrada aparece como Any Other Network (Qualquer Outra Rede) no comando pop show: pdadmin> pop show test Protected object policy: test Description: Test POP Warning: no Audit leel: none Quality of protection: none Time of day access: sun, mon, tue, wed, thu, fri, sat: anytime:local IP Endpoint Authentication Method Policy Any Other Network 0 Consulte Configurando Níeis para a Autenticação Progressia na página 125 para obter uma discussão mais detalhada sobre como definir níeis de autenticação. Exemplo Exigir que os usuários da faixa de endereços IP 9.0.0.0 e da máscara de rede 255.0.0.0 utilizem o níel 1 de autenticação ( senha, por padrão): pdadmin> pop modify test set ipauth add 9.0.0.0 255.0.0.0 1 Exigir que um usuário específico utilize o níel 0 de autenticação: pdadmin> pop modify test set ipauth add 9.1.2.3 255.255.255.255 0 Preenir que todos os usuários (que não sejam os especificados como nos exemplos anteriores) acessem o objeto: pdadmin> pop modify test set ipauth anyothernw forbidden Desatiando a Autenticação Progressia por Endereço IP Para desatiar a autenticação progressia por endereço IP, insira o seguinte comando: pdadmin> pop modify pop_name set ipauth remoe network netmask Capítulo 4. Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers 131

Por exemplo: pdadmin> pop modify test set ipauth remoe 9.0.0.0 255.0.0.0 Algoritmo de Autenticação com Base em Rede O Tioli Access Manager Plug-in para Web Serers utiliza o seguinte algoritmo para processar as condições em um POP: 1. Verificar o critério IP endpoint authentication method no POP. 2. Verificar as permissões de ACL. 3. Verificar o critério time-of-day no POP. 4. Verificar o critério audit leel no POP. Critério de Objetos Protegidos de Qualidade de Proteção O atributo do POP (Critério de Objetos Protegidos) de qualidade de proteção permite especificar o níel de proteção de dados necessário ao executar uma operação em um objeto. pdadmin> pop modify pop_name set qop {none integrity priacy} Tabela 22. Descrições de Níeis de QOP Níel de QOP priacidade integridade nenhum Descrição A criptografia de dados é necessária (SSL). Utilizar o mesmo mecanismo para assegurar que os dados não tenham sido alterados. Nenhum método de proteção de dados é utilizado. Por exemplo: pdadmin> pop modify test set qop priacy O atributo do POP de qualidade de proteção permite uma única transação quando a resposta positia ( yes ) à decisão da ACL também inclui o níel de qualidade de proteção necessário. Se o plug-in não conseguir garantir o níel de proteção necessário, o pedido será negado. Tratando Usuários Não Autenticados (HTTP/HTTPS) O Tioli Access Manager Plug-in para Web Serers aceita pedidos de usuários autenticados e não autenticados ia HTTP e HTTPS. Em seguida, o plug-in baseia-se no Authorization Serer para impor o critério de segurança permitindo ou negando acesso a recursos protegidos. As condições a seguir aplicam-se a usuários não autenticados que realizam o acesso ia SSL: O intercâmbio de informações entre o usuário não autenticado e o plug-in é criptografado como ocorre com um usuário autenticado. Uma conexão SSL entre um usuário não autenticado e o plug-in requer apenas a autenticação no lado do seridor. Processando um Pedido a partir de um Cliente Anônimo 1. Um cliente anônimo faz um pedido ao seridor Web por meio do plug-in (utilizando o HTTP ou o HTTPS). 2. O plug-in cria uma credencial não autenticada para esse cliente. 3. O pedido prossegue, com sua credencial, até o objeto da Web protegido. 132 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

4. O Authorization Serer erifica as permissões na entrada unauthenticated da ACL para esse objeto e permite ou nega a operação solicitada. 5. O acesso bem-sucedido a esse objeto depende da entrada unauthenticated da ACL contendo pelo menos a permissão Ler (r). 6. Se o pedido for reproado na decisão de autorização, o cliente receberá um formulário de logon (BA com base em Formulários). Forçando o Logon de Usuários É possíel forçar um usuário não autenticado a efetuar logon definindo corretamente as permissões apropriadas na entrada unauthenticated do critério ACL que protege o objeto solicitado. A permissão Ler [PDWebPI]r permite o acesso não autenticado a um objeto. Para forçar um usuário não autenticado a efetuar logon, remoa a permissão Ler [PDWebPI]r da entrada unauthenticated do critério ACL que protege o objeto. Aplicando o HTTPS Não Autenticado Existem muitos motios práticos de negócios para suportar o acesso não autenticado ao seridor Web aprimorado pelo plug-in ia HTTPS. Estas propriedades incluem: Alguns aplicatios não requerem um logon pessoal, mas exigem informações confidenciais, como endereços e números de cartão de crédito. Alguns exemplos incluem compras on-line de passagens aéreas e de outras mercadorias. Alguns aplicatios exigem que ocê se registre em uma conta com a empresa antes de poder prosseguir com transações adicionais. Noamente, informações confidenciais deem ser transmitidas pela rede. Controlando Usuários Não Autenticados com Critérios ACL/POP Para controlar usuários não autenticados com critérios ACL/POP: Nota: O tipo de entrada any-other também é conhecido como o tipo de entrada any-authenticated. 1. Para permitir que um usuário não autenticado acesse objetos públicos, proteja o conteúdo público com uma ACL que contenha pelo menos a permissão Ler [PDWebPI]r para as entradas unauthenticated e any-other: unauthenticated [PDWebPI]r any-other [PDWebPI]r Nota: A entrada unauthenticated é uma máscara (uma operação and em níel de bits) com relação à entrada any-other quando as permissões são determinadas. Uma permissão para unauthenticated apenas será concedida se essa permissão também aparecer na entrada any-other. Como unauthenticated depende de any-other, não faz muito sentido que uma ACL contenha unauthenticated sem any-other. Se uma ACL contier unauthenticated sem any-other, a resposta padrão será a não concessão de permissões para unauthenticated. 2. Para exigir criptografia (SSL), proteja o conteúdo com um POP (Critério de Objetos Protegidos) que especifique a priacidade como uma condição. Consulte a Critério de Objetos Protegidos de Qualidade de Proteção na página 132. Capítulo 4. Critério de Segurança do IBM Tioli Access Manager Plug-in para Web Serers 133

134 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Capítulo 5. Soluções de Conexão Única para a Web Quando o Tioli Access Manager Plug-in para Web Serers é implementado como um seriço de autorização para fornecer proteção para um domínio protegido, existe, freqüentemente, um requisito para fornecer soluções de conexão única com recursos nesse domínio. Esse capítulo discute soluções de conexão única para o espaço da Web protegido pelo Tioli Access Manager Plug-in para Web Serers. Este capítulo inclui os seguintes tópicos: Conceitos de Conexão Única Conceitos de Conexão Única Estabelecendo uma Conexão Única Automaticamente com um Aplicatio Protegido na página 136 Conexão Única com o Plug-in a partir do WebSEAL ou de Outro Proxy na página 139 Utilizando o Cookie de Failoer para Conexão Única na página 140 Utilizando a GSO (Conexão Única Global) na página 141 Conexão Única SPNEGO (Security Proider NEGOtiation) na página 144 Conexão Única Utilizando Formulários na página 144 Quando um recurso protegido está localizado no seridor de aplicatio Web aprimorado pelo plug-in, um cliente que solicita esse recurso talez precise efetuar ários logons ao acessar diferentes aplicatios protegidos. Cada logon proaelmente solicitará diferentes identidades de logon. O problema de administrar e manter árias identidades de logon pode geralmente ser resolido com um mecanismo SSO (conexão única). A SSO permite que o usuário acesse um recurso utilizando apenas um logon inicial. Todos os requisitos adicionais de logon para recursos no seridor Web são tratados de forma transparente ao usuário. Existem árias arquiteturas de conexão única diferentes suportadas pelo Tioli Access Manager Plug-in para Web Serers. Elas são: 1. Uma instância de plug-in fornecendo conexão única com mais de um aplicatio protegido em um seridor. 2. Conexão única com o plug-in a partir do WebSEAL ou de outro agente proxy, como um gateway WAP. 3. Uso de cookies de failoer para fornecer conexão única entre diferentes domínios. 4. Uso do módulo GSO (Conexão Única Global) Lockbox para fornecer acesso a aplicatios utilizando informações armazenadas de credencial do usuário. 5. Uso do SPNEGO (Security Proider NEGOtiation) para permitir acesso a recursos em IIS Web Serers. 6. Autenticação com base em formulários como um mecanismo para a SSO. 7. CDSSO (Conexão Única Entre Domínios), que fornece um mecanismo para transferir credenciais do usuário entre ários domínios protegidos. Copyright IBM Corp. 2000, 2003 135

8. Conexão Única do e-community, na qual um usuário se autentica uma ez e recebe um token que o permite acessar outros domínios em uma comunidade irtual de domínios sem exigir uma reautenticação. Os primeiros seis cenários de SSO são discutidos neste capítulo. O sétimo cenário e o oitao cenário são tópicos do próximo capítulo. Estabelecendo uma Conexão Única Automaticamente com um Aplicatio Protegido Cabeçalhos HTTP e cookies LTPA (quando o aplicatio é o WebSphere Application Serer) podem ser utilizados para realizar a SSO com aplicatios em um seridor que são protegidos por uma instância de plug-in. Após a autenticação inicial do cliente, o plug-in pode construir um cabeçalho HTTP contendo informações de identidade do cliente que podem ser utilizadas para autenticação automática com aplicatios protegidos em execução no seridor. De forma semelhante, um cookie LTPA pode ser utilizado para realizar a SSO com um seridor de aplicatio Web, como o WebSphere. Configurando a Conexão Única com Aplicatios Protegidos Utilizando Cabeçalhos HTTP Os cabeçalhos HTTP utilizadas para conexão com um aplicatio são gerados pelo módulo de pós-autorização com base em cabeçalhos IV. O conjunto de cabeçalhos que podem ser gerados são coletiamente chamados de cabeçalhos IV. Após a autorização bem-sucedida de um pedido de usuário, o plug-in pode inserir cabeçalhos IV que definem a identidade do cliente no pedido para processamento por parte do aplicatio. Essas informações de cabeçalhos podem ser utilizadas como proa de identidade do usuário quando o pedido é tratado por um aplicatio hospedado pelo seridor Web protegido. O usuário não precisa efetuar logon sempre que um noo aplicatio protegido é acessado. Configurados para o processamento pós-autorização, os cabeçalhos IV são inseridos com um, alguns ou todos os tipos de cabeçalhos HTTP i-user, i-user-l, i-creds, i-groups e/ou i-remote-address. Esses tipos de cabeçalhos são descritos na tabela a seguir. Tabela 23. Descrições de Campos de Cabeçalhos IV Campo de Cabeçalho IV Descrição i-user O nome abreiado do usuário do Tioli Access Manager. Assumirá unauthenticated como padrão se o cliente não estier autenticado (desconhecido). i-user-l O nome de domínio completo do usuário (formato longo), por exemplo, o nome distinto LDAP. i-groups Uma lista dos grupos aos quais o usuário pertence. i-creds Estrutura de dados opacos codificados que representa a credencial do Tioli Access Manager do usuário. i-remote-address O endereço IP do cliente. Esse alor poderia representar o endereço IP de um seridor proxy ou de um NAT (conersor de endereços de rede). 136 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Atiando e Desatiando a Geração de Cabeçalhos IV Para atiar o plug-in de forma que ele insira cabeçalhos IV em pedidos autorizados, o plug-in precisa ser configurado para utilizar cabeçalhos IV para o processamento pós-autorização. A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar cabeçalhos IV para o processamento pós-autorização, atribua ao parâmetro post-authzn o alor de palara-chae i-headers na sub-rotina [common-modules] do arquio de configuração pdwebpi.conf. Ou seja: [common-modules] post-authzn = i-headers Configurando Parâmetros de Cabeçalhos IV Os parâmetros de autenticação com base em cabeçalhos IV são configurados na sub-rotina [i-headers] do arquio de configuração pdwebpi.conf. O parâmetro generate especifica o tipo de cabeçalho IV a ser gerado ao encaminhar pedidos em proxy. Por padrão, o plug-in gera todos os tipos de cabeçalhos IV ao encaminhar pedidos em proxy. As opções álidas são all, i-creds, i-user, i-user-l e i-remote-address. Para inserir mais de um tipo de cabeçalho, separe os alores com uma írgula. Por exemplo: [i-headers] generate = i-creds,i-user,i-user-1 Conexão Única com o WebSphere Application Serer Utilizando Cookies LTPA Quando o plug-in é instalado como uma camada protetora em um WebSphere Application Serer, os clientes de acesso enfrentam dois pontos de logon potenciais o plug-in e os aplicatios protegidos atendidos pelo WebSphere. Para fornecer um único ponto de logon nessa situação, o plug-in pode ser configurado para gerar e transmitir o mecanismo LTPA (Lightweight Third Party Authentication) com base em cookies a seridores de aplicatio Web que suportam cookies LTPA. Quando um usuário faz um pedido para um recurso em um seridor, esse usuário dee ser primeiramente autenticado no plug-in. Após a autenticação bem-sucedida, o plug-in gera um cookie LTPA em nome do usuário. O cookie LTPA, que sere como um token de autenticação para o seridor de aplicatio Web, contém informações de identidade e de senha do usuário. Essas informações são criptografadas com o uso de uma chae secreta protegida por senha compartilhada entre o plug-in e o seridor de aplicatio. O plug-in insere o cookie no cabeçalho HTTP do pedido que é eniado ao seridor de aplicatio Web. O seridor de aplicatio recebe o pedido, decriptografa o cookie e autentica o usuário com base nas informações de identidade fornecidas nesse cookie. Para aprimorar o desempenho, o plug-in armazena o cookie LTPA no cache de sessão e utiliza esse cookie LTPA armazenado em cache para pedidos subseqüentes durante a mesma sessão do usuário. Para obter detalhes sobre como definir os parâmetros para o cache de sessão, consulte Configurando o Cache de Sessão/Credenciais do Plug-in na página 53. Capítulo 5. Soluções de Conexão Única para a Web 137

Configurando a Conexão Única com o WebSphere Utilizando Cookies LTPA O uso de cookies LTPA para realizar a conexão única com seridores de aplicatio que suportam esses cookies LTPA faz parte do processamento pós-autorização do plug-in. Para atiar essa funcionalidade, insira o alor de chae ltpa para o parâmetro post-authzn na sub-rotina [common-modules] do arquio de configuração pdwebpi.conf: [common-modules] post-authzn = ltpa 138 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

A configuração de cookies LTPA é executada na sub-rotina [ltpa] do arquio de configuração pdwebpi.conf. Os parâmetros a seguir requerem configuração. Tabela 24. Parâmetros de Configuração LTPA ltpa-keyfile ltpa-stash-file ltpa-password ltpa-lifetime Parâmetro Descrição O nome completo do caminho para o arquio de chaes utilizado para criptografar as informações de identidade contidas no cookie. A localização do arquio stash de senha. Se esse arquio não existir, será necessário desfazer o comentário dessa entrada. A senha a ser utilizada quando não existir um arquio stash de senha. A duração, em segundos, do cookie LTPA. Notas Técnicas para a Conexão Única LTPA O arquio de chaes contém informações sobre um seridor de aplicatio Web específico. Se ocê adicionar mais de um seridor de aplicatio ao mesmo plug-in, todos os seridores compartilharão o mesmo arquio de chaes. Para que a conexão única seja bem-sucedida, o plug-in e o seridor de aplicatio deem, de alguma maneira, compartilhar as mesmas informações de registro. O seridor de aplicatio é responsáel pela configuração do LTPA e pela criação da chae secreta compartilhada. Conexão Única com o Plug-in a partir do WebSEAL ou de Outro Proxy Quando o seridor Web aprimorado pelo plug-in recebe pedidos de um aplicatio confiáel, como o WebSEAL ou um agente proxy de multiplexação, cabeçalhos IV podem ser inseridos nos pedidos transmitidos ao plug-in. Cabeçalhos IV contêm informações que identificam o cliente originador em ez do seridor de transmissão. As informações nos cabeçalhos são utilizadas para construir uma credencial do cliente originador para finalidades de autorização. Se o plug-in estier configurado para utilizar Cabeçalhos IV de forma a executar a autenticação do cliente, ele criará uma credencial de cliente utilizando a identidade extraída de um cabeçalho IV encontrado no pedido de transação. Como é fácil para os clientes falsificar cabeçalhos IV, essa credencial apenas será criada quando o sinalizador use secondary authenticator (usar autenticador secundário) no pedido de autenticação estier definido. Para autenticação, os cabeçalhos IV podem ser configurados para aceitar um, alguns ou todos os cabeçalhos i-user, i-user-l, i-creds ou i-remote-address no pedido como proa de autenticação quando recebidos por meio de um proxy. O cabeçalho i-remote-address é utilizado para registrar a endereço remoto real do usuário. Esses tipos de cabeçalhos IV são reconhecidos pelo Tioli Access Manager e pelo WebSEAL. Tabela 25. Descrições de Campos de Cabeçalhos IV Campo de Cabeçalho IV i-user i-user-l Descrição O nome abreiado do cliente. Assumirá unauthenticated como padrão se o cliente não estier autenticado (desconhecido). O nome de domínio completo do usuário (formato longo). Capítulo 5. Soluções de Conexão Única para a Web 139

Tabela 25. Descrições de Campos de Cabeçalhos IV (continuação) Campo de Cabeçalho IV i-groups i-creds i-remote-address Descrição Uma lista dos grupos aos quais o cliente pertence. Estrutura de dados opacos codificados que representa uma credencial do Tioli Access Manager. O endereço IP do cliente. Esse alor poderia representar o endereço IP de um seridor proxy ou de um NAT (conersor de endereços de rede). Nota: O Access Manager apenas confia em cabeçalhos recebidos de front-ends confiáeis. Um front-end será considerado confiáel se estier organizado como um MPA (Agente Proxy de Multiplexação). Para obter detalhes sobre como configurar o plug-in para suporte a MPAs, consulte Oferecendo Suporte para MPAs (Agentes Proxy de Multiplexação) na página 112. Para ser aceito como proa de identidade do cliente, o próprio WebSEAL ou outro proxy dee ser autenticado no plug-in. Isso é normalmente realizado por uma conexão SSL mutuamente autenticada entre o proxy e o seridor Web protegido pelo plug-in. Atiando e Desatiando a Autenticação com o Uso de Cabeçalhos IV A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a autenticação utilizando cabeçalhos IV, atribua a referência i-header ao parâmetro authentication: [common-modules] authentication = i-header Configurando Parâmetros de Cabeçalhos IV Os parâmetros de autenticação com base em cabeçalhos IV são configurados na sub-rotina [i-headers] do arquio de configuração pdwebpi.conf. O parâmetro accept especifica os tipos de cabeçalhos IV que são aceitos para a execução da autenticação com base em cabeçalhos IV. Por padrão, o plug-in aceita todos os tipos de cabeçalhos IV. As opções álidas são all, i-creds, i-user, i-user-l e i-remote-address. Para inserir mais de um tipo de cabeçalho, separe os alores com uma írgula. Por exemplo: [i-headers] accept = i-creds,i-user Utilizando o Cookie de Failoer para Conexão Única Com cookies de failoer configurados para o processamento pós-autorização, o plug-in criptografa os dados de credencial de um cliente em cookie específico para o seridor ou para o domínio inteiro. Esse cookie é colocado no naegador no momento em que o cliente se conecta pela primeira ez. Quando o cliente tenta acessar outro seridor protegido no domínio, o cookie será apresentado ao próximo seridor para o qual o cliente for redirecionado. Esse cookie será utilizado para reautenticação automático de forma que o cliente não precise executar manualmente a tarefa de reautenticação. Os plug-ins em seridores replicados 140 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

compartilham uma chae comum que decriptografa as informações de credenciais contidas no cookie, estabelecendo uma noa sessão. Nota: A segurança de tokens foi aprimorada no release 4.1 do plug in para a geração de cookies de failoer. Os aprimoramentos não são interoperáeis com o esquema de codificação de tokens do Tioli Access Manager 3.9. Para continuar a poder interoperar com ersões 3.9 do Tioli Access Manager Web Security, defina o parâmetro de configuração pre-410-compatibletokens na sub-rotina [pdweb-plugins] como true. Esse parâmetro abrange todos os processos e não pode ser especificado para cada host irtual. Atiando a Conexão Única com o Uso de Cookies de Failoer Os cookies de failoer podem ser configurados para executar tarefas de autenticação e de pós-autorização. Os plug-ins configurados para o processamento pós-autorização com o uso de cookies de failoer criptografam e armazenam uma credencial como um cookie de failoer na resposta de transação. Os plug-ins configurados para utilizar cookies de failoer para a execução da autenticação reautenticam clientes com o uso da credencial criptografada a partir de um cookie de failoer encontrado no pedido de transação. Para atiar a SSO utilizando cookies de failoer, atribua a referência failoer aos parâmetros authentication e post-authzn na sub-rotina [common-modules] do arquio de configuração: [common-modules] authentication = failoer post-authzn = failoer Para obter detalhes adicionais sobre configurar a autenticação com base em cookies de failoer, consulte Configurando a Autenticação com Base em Failoer na página 84. Utilizando a GSO (Conexão Única Global) O Tioli Access Manager Plug-in para Web Serers pode ser configurado de forma a conceder acesso para usuários aos recursos de computação que eles estão autorizados a utilizador por meio de um único login. Projetada para empresas de grande porte que consistem em ários sistemas e aplicatios dentro de ambientes de computação heterogêneos e distribuídos, a GSO elimina a necessidade de os usuários finais gerenciarem diersos nomes de usuário e senhas. Nota: A GSO não é uma solução de conexão única adequada para o iplanet Web Serer quando ele utiliza as mesmas instâncias LDAP do Tioli Access Manager. Para criar uma solução GSO, é necessário criar primeiramente recursos GSO e grupos de recursos GSO do Tioli Access Manager com o uso do Web Portal Manager ou do utilitário pdadmin. Para obter detalhes sobre como criar recursos GSO e grupos de recursos GSO, consulte o documento IBM Tioli Access Manager Base: Guia do Administrador. O módulo de pós-autorização por BA (Autenticação Básica) é chamado depois que um pedido foi autorizado para determinar se uma credencial de recurso está disponíel para o recurso solicitado. A credencial de recurso é uma combinação de Capítulo 5. Soluções de Conexão Única para a Web 141

nome do usuário/senha que é mapeada para cada recurso e armazenada no registro de usuários. O módulo de pós-autorização por BA recupera a credencial de recurso apropriada para o usuário e o recurso de aplicatio solicitado e cria um cabeçalho BA HTTP Básico utilizando a credencial de recurso recuperada e adiciona esse cabeçalho BA ao pedido HTTP. A credencial de recurso é recuperada a partir do registro de usuários apenas para o primeiro pedido. Para todos os pedidos subseqüentes, a credencial de recurso é recuperada como informações de sessão. A figura a seguir ilustra como o mecanismo GSO é utilizado para recuperar nomes de usuário e senhas para recursos de aplicatios backend. Figura 6. Acesso de Usuários a Aplicatios Protegidos Utilizando a GSO. 1. O usuário Michael solicita acesso ao aplicatio de seridor Web backend protegido trael-app. O Tioli Access Manager autentica o cliente, e uma identidade do Tioli Access Manager é obtida. Se o recurso solicitado estier desprotegido, o pedido será encaminhado ao seridor Web para tratamento. Nota: O processo de conexão única não depende do método de autenticação inicial. 2. O plug-in transmite a identidade do Tioli Access Manager ao seridor do registro de usuários (LDAP ou URAF). O seridor do registro de usuários mantém um banco de dados completo de informações de autenticação no formato de mapeamentos de recursos para informações de autenticação específicas. Essas informações de autenticação são uma combinação de nome do usuário/senha conhecida como credencial de recurso. Credenciais de recursos apenas podem ser criadas para usuários registrados. A tabela a seguir ilustra a estrutura do banco de dados de credenciais de recursos GSO: 142 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Michael resource: trael-app username=mike password=123 resource: payroll-app username=smith password=456 Jane resource: trael-app username=jane password=abc resource: payroll-app username=jones password=xyz 3. O registro retorna o nome do usuário mike e a senha 123 ao plug-in. 4. O plug-in insere as informações de nome do usuário e senha de Michael no cabeçalho BA (Autenticação Básica) HTTP do pedido que é eniado de olta ao seridor Web. 5. O seridor Web autentica Michael (para o recurso que ele solicitou) com base em suas credenciais no cabeçalho BA inserido no pedido (Etapa 4), como se ele fosse proeniente do cliente. Configurando a Conexão Única Global Para atiar a funcionalidade da conexão única global, é necessário configurar pdwebpi.conf. Na sub-rotina [common-modules], especifique o alor BA para o parâmetro post-authzn, conforme mostrado a seguir: [common-modules] authentication =... session =... post-authzn = BA Assegure-se de que, na sub-rotina modules, o parâmetro BA está atribuído pelo menos com o módulo padrão, ou seja: [modules] BA = pdwpi-ba-module Na sub-rotina [BA] do arquio de configuração pdwebpi.conf, existem diersos parâmetros utilizados para configurar o módulo de pós-autorização por BA. Eles são: basic-auth-realm strip-hdr add-hdr gso-resource-name supply-password supply-username Para realizar a GSO com aplicatios backend, os parâmetros add-hdr e gso-resource-name necessitam de configuração. Outros parâmetros BA são discutidos com mais detalhes adicionais em Configurando a Autenticação Básica na página 62. O parâmetro add-hdr controla a adição de um noo cabeçalho BA após a autenticação do pedido. Para realizar a GSO, defina esse parâmetro como o alor gso: [BA:irtual_host1]... add-hdr = gso Capítulo 5. Soluções de Conexão Única para a Web 143

A definição do parâmetro add-hdr como o alor gso significa que um noo cabeçalho BA é adicionado ao pedido HTTP com base em informações de recursos que estão armazenadas no registro de usuários. O parâmetro gso-resource-name na sub-rotina [BA] do arquio de configuração especifica o nome do recurso do seridor Web que dee atiado para a GSO. Isso pode ser especificado para cada host irtual. A credencial de recurso armazenada no registro de usuários é mapeada para cada recurso armazenado no registro de usuários. Defina o parâmetro gso-resource-name como o nome do recurso do Tioli Access Manager que dee ser atiado para a GSO. Por exemplo: [BA:irtual_host1]... gso-resource-name = payroll-app Apenas um nome de recurso GSO pode ser especificado para cada host irtual. Se nenhum alor for especificado para gso-resource-name, o nome do host irtual será utilizado como o nome do recurso GSO. Nota: Se ocê estier compartilhando um registro LDAP entre o Sun ONE (antigo iplanet) e o Tioli Access Manager, não poderá criar credenciais de recursos GSO no Tioli Access Manager com nomes de usuário de destino iguais aos nomes de usuário que aguardam a autenticação no Sun ONE Web Serer. Isso ocorre porque o Sun ONE Web Serer não consegue limitar os critérios de pesquisa LDAP ao autenticar usuários de forma a pesquisar apenas os objetos da classe de objeto LDAP correta. Conexão Única SPNEGO (Security Proider NEGOtiation) O uso do SPNEGO como um mecanismo de autenticação no plug-in oferece uma capacidade de conexão única que permite aos usuários acessar recursos em um IIS Web Serer protegido a partir de um cliente Windows sem precisarem de uma autenticação além do logon inicial no domínio. Detalhes operacionais e de configuração da conexão única SPNEGO estão incluídos em Configurando a Autenticação SPNEGO na página 74. Conexão Única Utilizando Formulários A autenticação com base em conexão única por formulários permite que o Tioli Access Manager Plug-in para Web Serers efetue transparentemente o login de usuário autenticado do Tioli Access Manager em um seridor Web protegido pelo plug-in que requer autenticação com o uso de um formulário HTML. A autenticação com base em conexão única por formulários suporta aplicatios existentes que utilizam formulários HTML para autenticação e que não podem ser modificados de forma a confiar diretamente na autenticação executada pelo plug-in. A conexão única por formulários do plug-in fornece uma rápida solução de integração que dee ser considerada uma solução intermediária a ser utilizada enquanto um método de autenticação mais confiáel e eficiente é desenolido. A atiação da autenticação com base em conexão única por formulários gera os seguintes resultados: O plug-in interrompe o processo de autenticação iniciado pelo aplicatio backend. O plug-in fornece os dados necessários pelo formulário de login e submete esse formulário em nome do usuário. 144 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

O usuário não sabe que um segundo login está sendo efetuado. O aplicatio backend não sabe que o formulário de login não está indo diretamente do usuário. O plug-in dee ser configurado para: Reconhecer e interceptar o formulário de login Preencher os dados de autenticação apropriados O administrador atia a conexão única por formulários configurando o modo como o formulário de login dee ser reconhecido, preenchido e processado. Fluxo do Processo da Conexão Única por Formulários O cenário a seguir assume que o plug-in já tenha autenticado o usuário. Figura 7. Fluxo do Processo da Conexão Única por Formulários.. Fluxo do processo da conexão única por formulários. 1. O usuário solicita um recurso em um host irtual protegido. 2. O plug-in transmite o pedido ao aplicatio backend. 3. Como o aplicatio backend requer a autenticação do usuário, um redirecionamento à página de login desse aplicatio é eniado de olta ao plug-in. 4. O plug-in transmite o redirecionamento ao naegador. 5. O naegador segue o redirecionamento e solicita a página de login. Capítulo 5. Soluções de Conexão Única para a Web 145

Nota: Todos os itens até esse ponto no fluxo de processo correspondem à funcionalidade padrão do plug-in. 6. O plug-in foi configurado para a conexão única por formulários. O módulo FSSO do plug-in reconhece o pedido como um pedido para uma página de login, com base nas informações contidas no arquio de configuração do plug-in. O pedido é eniado ao aplicatio. 7. O aplicatio retorna a página de login e, talez, seus cookies específicos. 8. O plug-in intercepta a resposta e analisa o HTML retornado para identificar o formulário de login. Quando o plug-in localiza um formulário HTML no documento, ele compara o URI de ação no formulário com o alor do parâmetro login-form-action no arquio de configuração do plug-in. Se houer uma correspondência, o plug-in utilizará o formulário localizado. Caso contrário, continuará procurando outros formulários. Se nenhum formulário na página corresponder ao padrão do URI de ação a partir do arquio de configuração, o plug-in interromperá o processamento da conexão única por formulários e transmitirá a resposta não modificada de olta ao naegador. Se um formulário de login for localizado, o plug-in analisará o HTML desse formulário no documento para identificar o método do pedido, o URI de ação e qualquer outro campo de entrada no formulário, salando-os para uso na etapa 10. Em seguida, eniará para o naegador um redirecionamento ao URI de ação do formulário de login com um identificador de pedido exclusio anexado como uma consulta. Todos os cookies específicos do aplicatio também serão incluídos com o redirecionamento. 9. O naegador segue o redirecionamento e solicita o URI de ação. 10. O plug-in reconhece o pedido de entrada de acordo com sua cadeia de consulta exclusia e gera o pedido de autenticação utilizando as regras a partir do parâmetro argument-stanza e dos dados salos na etapa 8. O formulário de login preenchido (pedido de autenticação) é eniado ao aplicatio backend. 11. O aplicatio faz a autenticação utilizando os dados fornecidos pelo plug-in no formulário. O aplicatio retorna um redirecionamento ao recurso originalmente solicitado. 12. O plug-in retorna o redirecionamento ao naegador. Nota: Esse processo conclui a funcionalidade específica da SSO por formulários. 13. O naegador segue o redirecionamento e solicita o recurso. 14. O plug-in transmite o pedido protegido. Durante esse processo, o naegador faz quatro pedidos ao plug-in. Sob a perspectia do usuário, apenas um pedido para o recurso é feito. Os outros pedidos ocorrem automaticamente por meio de redirecionamentos HTTP. Requisitos para o Suporte de Aplicatios A autenticação com base em conexão única por formulários é suportada em aplicatios que atendem aos seguintes requisitos: 1. A página (ou as páginas) de login para o aplicatio dee ser exclusiamente identificáel com o uso de uma única expressão comum ou de árias expressões comuns. 2. A página de login pode incluir mais de um formulário HTML. Entretanto, o formulário de login dee ser identificado por meio da aplicação de uma expressão comum aos URIs de ação de cada um dos formulários de login, ou o 146 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

formulário de login dee ser o primeiro formulário na página de login. Obsere que, ao utilizar o atributo action de forma a identificar o formulário de login, esse atributo action não passou pela filtragem HTML do plug-in. A expressão comum dee corresponder ao URI de ação antes de ser filtrado. 3. A criação de scripts no lado do cliente pode ser utilizada para alidar dados de entrada, mas não dee modificar esses dados de entrada. Isso impede o suporte para sites da Web utilizando o Jaascript para construir formulários de logon dinamicamente ou para definir cookies no naegador do usuário. 4. Os dados de login são submetidos em apenas um ponto no processo de autenticação. 5. O URI de logon a ser interceptado na etapa 8 da seção anterior dee ser processado como um único pedido pelo seridor Web subjacente. Scripts PHP tratados como comandos externos no Apache, por exemplo, estendem-se por ários subpedidos e não podem ser interceptados. Atiando a Conexão Única por Formulários O módulo FSSO trata o processo de conexão única por formulários. Esse módulo precisa ser chamado após a autorização do pedido e antes que o seridor Web responda ao pedido. Portanto, o módulo FSSO precisa ser configurado como um módulo post-authzn e um módulo de resposta. Eles são especificados na sub-rotina [common-modules] do arquio de configuração pdwebpi.conf. Ou seja: [common-modules]... response = fsso O módulo de resposta é utilizado para capturar o formulário de login apresentado pelo seridor Web de forma que ele possa ser processado. A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e o respectio nome da biblioteca compartilhada associada. Assegure-se de que a entrada para o fsso esteja presente: [modules] fsso = pdwpi-fsso-module Como a função principal do plug-in é proteger recursos da Web contra acessos não autorizados, ele dee autorizar todos os pedidos para recursos, mesmo que eles façam parte de um processo de conexão única por formulários. O plug-in erifica o banco de dados da ACL antes de permitir o acesso à página de login do aplicatio backend e também erifica antes de permitir o acesso ao URI especificado na ação do formulário (em que o formulário de login preenchido é eniado). Se o critério de segurança não fornecer opção para que o usuário atual acesse essas páginas, ocorrerá uma falha na conexão única por formulários. Configurando a Conexão Única por Formulários As informações de configuração da conexão única com base em formulários estão localizadas no arquio de configuração pdwebpi.conf, na sub-rotina [fsso] ou [fsso:irtual-host]. A sub-rotina contém uma ou mais entradas login-page-stanza que apontam para outras sub-rotinas de nomes personalizados contendo informações de configuração para as páginas de login localizadas no aplicatio backend. A capacidade de suportar árias páginas de login é importante, pois um seridor pode hospedar ários aplicatios, cada qual utilizando um método de autenticação diferente. Capítulo 5. Soluções de Conexão Única para a Web 147

Por exemplo: [fsso] login-page-stanza = login-from-1 login-page-stanza = login-form-2 A Sub-Rotina de Página de Login Personalizada Cada sub-rotina de página de login personalizada é utilizada para interceptar um padrão de URL específico. A sub-rotina pode conter os seguintes parâmetros: Parâmetro login-page login-form-action argument-stanza gso-resource Descrição Esse parâmetro especifica um padrão, com o uso de uma expressão comum, que identifica exclusiamente os pedidos para a página de login de um aplicatio. O padrão configurado é comparado com base no URI do pedido. Esse parâmetro especifica um padrão, com o uso de uma expressão comum, que identifica exclusiamente qual formulário contido na página interceptada corresponde ao formulário de login do aplicatio. Se ários formulários corresponderem ao padrão, o primeiro deles será utilizado. Esse parâmetro aponta para outra sub-rotina personalizada que lista os campos e os dados necessários para o preenchimento do formulário de login. Esse parâmetro fornece o nome do recurso do Tioli Access Manager que dee ser utilizado ao carregar dados de origem GSO definidos no parâmetro arguments-stanza. Apenas um nome de recurso GSO pode ser especificado para cada sub-rotina de página de login personalizada. Se nenhum alor for especificado para gso-resource, o nome do host irtual será utilizado como o nome do recurso GSO. Por exemplo: [login-form-1] login-page = /cgi-bin/getloginpage* login-form-action = * argument-stanza = form1-data gso-resource = payroll-app Sobre o Parâmetro login-page: O alor do parâmetro login-page é uma expressão comum que o plug-in utiliza para determinar se um pedido de entrada é realmente um pedido para uma página de login. Se esse for o caso, o plug-in interceptará esse pedido e iniciará o processamento da conexão única por formulários. Apenas um parâmetro login-page é permitido em cada sub-rotina de página de login personalizada. É necessário criar uma sub-rotina de página de login personalizada adicional para cada parâmetro login-page adicional. A expressão comum login-page é comparada com o URI do pedido. No exemplo a seguir, o URI de um host irtual protegido chamado myserer1 pode aparecer da seguinte maneira: https://myserer1.mycompany.com/auth/login.html A parte desse URI que é comparada com a expressão comum login-page é: /auth/login.html Sobre o Parâmetro login-form-action: O parâmetro login-form-action é utilizado para identificar o formulário de login na página retornada pelo seridor backend 148 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

após um pedido correspondente ao parâmetro login-page. Apenas um parâmetro login-form-action é permitido em cada sub-rotina. O alor do parâmetro login-form-action é uma expressão comum que é comparada com o conteúdo do atributo action= do marcação form HTML. O atributo action é um URI expresso como um caminho relatio, um caminho relatio ao seridor ou um caminho absoluto. O parâmetro login-form-action dee corresponder a esse caminho, pois é proeniente do seridor backend, mesmo que fosse normalmente modificado pelo plug-in antes de ser encaminhado ao cliente. Se ários atributos action na página corresponderem à expressão comum, apenas a primeira correspondência será aceita como o formulário de login. Se a expressão comum login-form-action não corresponder a nenhum formulário na página, um erro será retornado ao naegador, relatando que o formulário não pôde ser encontrado. Será possíel definir login-form-action = * como uma maneira simples de corresponder ao formulário de login quando a página incluir apenas um formulário de login. Utilizando Expressões Comuns: Os caracteres especiais permitidos nas expressões comuns utilizadas na configuração da conexão única por formulários são definidos no Apêndice E, Caracteres Especiais Permitidos em Expressões Comuns, na página 235. Na maioria dos casos, caracteres especiais não são necessários porque o pedido da página de login é um único URI identificáel. Em alguns casos, é possíel utilizar * no final da expressão de forma que os dados de consulta no final do URI não preinam a correspondência da página de login. A Sub-Rotina de Argumento: A sub-rotina de argumento personalizada contém uma ou mais entradas no seguinte formato: name = method:alue name O alor do parâmetro name é definido como igual ao alor do atributo name da marcação input HTML. Por exemplo: <input name=uid type=text>username</input> Esse parâmetro também pode utilizar o alor do atributo name da marcação select ou textarea HTML. method:alue Essa combinação de parâmetros recupera os dados de autenticação requeridos pelo formulário. Os dados de autenticação podem incluir: Dados de cadeias literais string:text A entrada utilizada é a cadeia de texto. Nome do usuário e senha GSO gso:username gso:password Capítulo 5. Soluções de Conexão Única para a Web 149

A entrada é o nome do usuário e a senha GSO do usuário atual (a partir do gso-resource de destino especificado na sub-rotina de página de login personalizada). Valor de um atributo na credencial do usuário cred:cred-ext-attr-name Por padrão, a credencial inclui informações como o nome de usuário e o DN do usuário do Tioli Access Manager. Para utilizar o nome do usuário do Tioli Access Manager como o alor de entrada, especifique esse alor como: cred:azn_cred_principal_name O DN do usuário pode ser acessado como: cred:azn_cred_authzn_id Atributos de credencial personalizados (adicionados com o uso do mecanismo tag/alue) também podem ser utilizados. Não é necessário especificar campos de entrada ocultos nessa sub-rotina. Esses campos são automaticamente recuperados a partir do formulário HTML e submetidos com o pedido de autenticação. Por exemplo: [form1-data] uid = string:brian Notas: 1. O plug-in não executa códigos de script (Jaascript, AxciteX, etc.) antes da submissão do formulário, o que poderá causar problemas se um código for necessário para o processo de login. Não ocorrerão problemas se esse código simplesmente erificar a entrada antes da submissão. Entretanto, poderão ocorrer problemas se o código modificar a entrada do usuário. 2. Embora a SSO por formulários possa utilizar as informações no banco de dados GSO, ela não interfere na capacidade GSO fornecida pelo módulo BA. Se necessário, será possíel fazer com que um destino GSO em uso preencha os cabeçalhos de Autenticação Básica eniados ao seridor backend e outro especificado na configuração da SSO por formulários para uso durante o preenchimento de formulários de login. Exemplo de Arquio de Configuração para o IBM HelpNow O site IBM HelpNow chama seu próprio login com base em formulários e é, portanto, um exemplo de como uma solução de conexão única por formulários pode fornecer um acesso perfeito ao site para os usuários cadastrados. Esta seção contém: Uma seção de formulário, semelhante ao formulário eniado na página de login HTML retornada pelo aplicatio HelpNow O arquio de configuração personalizado da conexão única por formulários utilizado para processar esse formulário O formulário localizado na página HTML interceptada: <form name="confirm" method="post" action="../files/wcls_hnb_welcomepage2.cgi"> <p> Employee Serial Number:&nbp; <input name="data" size="10" maxlength="6"> <p> 150 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Country Name: <select name="cntselect" size="1"> <OPTION alue="notselected" selected>select Country</OPTION> <OPTION alue=675>united Arab Emirates - IBM</OPTION> <OPTION alue=866>united Kingdom</OPTION> <OPTION alue=897>united States</OPTION> <OPTION alue=869>uruguay</option> <OPTION alue=871>venezuela</option> <OPTION alue=852>vietnam</option> <OPTION alue=707>yugoslaia</option> <OPTION alue=825>zimbabwe</option> </select> </p> <input type=submit alue=submit> </form> O arquio de configuração personalizado utilizado para processar esse formulário: helpnow FSSO configuration: [forms-sso-login-pages] login-page-stanza = helpnow [helpnow] # The HelpNow site redirects you to this page # you are required to log in. login-page = /bluebase/bin/files/wcls_hnb_welcomepage1.cgi # The login form is the first in the page, so we can just call it # *. login-form-action = * # The GSO resource, helpnow, contains the employee serial number. gso-resource = helpnow # Authentication arguments follow. argument-stanza = auth-data [auth-data] # The data field contains the employee serial number. data = gso:username # The Cntselect field contains a number corresponding to the employee s # country of origin. The string "897" corresponds to the USA. Cntselect = string:897 Capítulo 5. Soluções de Conexão Única para a Web 151

152 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Capítulo 6. Soluções de Conexão Entre Domínios Quando o Tioli Access Manager Plug-in para Web Serers é implementado para fornecer proteção para um domínio protegido, existe, freqüentemente, um requisito para fornecer soluções de conexão única com recursos. Esse capítulo discute dois métodos de realizar a conexão única entre diferentes domínios protegidos do plug-in; a conexão única do e-community e a CDSSO (conexão única entre domínios). Ambas as soluções utilizam um token confiáel para transmitir informações sobre o usuário entre diferentes domínios. A solução escolhida dependerá do níel de flexibilidade necessário. A conexão única do e-community utiliza um seridor central que coordena o processo de conexão única entre os diferentes domínios. Com a CDSSO, não existe um seridor de autenticação central e nenhum redirecionamento automatizado, o que proporciona mais flexibilidade. Os seguintes tópicos são discutidos: CDSSO (Conexão Única Entre Domínios) Conexão Única do e-community na página 159 CDSSO (Conexão Única Entre Domínios) A CDSSO (Conexão Única Entre Domínios) do Tioli Access Manager fornece um mecanismo para transferir credenciais do usuário entre ários domínios protegidos. A CDSSO suporta os objetios da arquitetura de rede escaláel permitindo a integração de múltiplos domínios seguros. Por exemplo, uma grande extranet corporatia pode ser configurada com dois ou mais domínios exclusios cada qual com seus próprios usuários e espaço de objetos. A CDSSO permite a moimentação de usuários entre os domínios com uma conexão única. O mecanismo de autenticação CDSSO não depende de um Seridor de Autenticação Master, como ocorre com a Conexão Única do e-community na página 159. Com a CDSSO, quando um usuário faz um pedido para um recurso localizado em outro domínio, o mecanismo CDSSO transfere um token de identidade de usuário criptografado do primeiro domínio para o segundo domínio. Nesse ponto, o segundo domínio possui a identidade do usuário (conforme a autenticação no primeiro domínio) e o usuário não é forçado a efetuar outro login. Os domínios CDSSO são baseados em domínios DNS. Todos os seridores no mesmo domínio DNS compartilham a mesma chae simétrica. Para realizar a CDSSO com seridores em outro domínio DNS (que também pode estar ou não em um domínio diferente do Tioli Access Manager), uma chae diferente é necessária. Fluxo do Processo de Autenticação para a CDSSO O fluxo de processo da CDSSO está descrito no diagrama e no texto a seguir. Qualquer usuário que quiser participar de ários domínios dee ter uma conta de usuário álida no domínio primário, neste caso, o domínio A, e uma identidade que possa ser mapeada para uma conta álida em cada um dos domínios remotos participantes. Um usuário não pode chamar a funcionalidade de CDSSO sem inicialmente autenticar em um domínio seguro inicial (A) que contenha a conta do usuário. Copyright IBM Corp. 2000, 2003 153

Figura 8. Fluxo de Processo da CDSSO.. 1. O usuário faz um pedido para acessar um recurso no domínio B utilizando um link personalizado em uma página da Web no domínio A. 2. O link contém uma expressão CDSSO especial especificada pelo parâmetro uri na sub-rotina [cdsso] do arquio de configuração pdwpi.conf. O alor padrão é pkmscdsso: /pkmscdsso?destination-url Por exemplo: /pkmscdsso?https://www.domainb.com/index.html O pedido é primeiramente processado pelo seridor de plug-in no domínio A. O plug-in constrói um token de autenticação que contém a identidade do usuário do Tioli Access Manager (nome abreiado), o domínio atual ( A ), informações adicionais sobre o usuário e uma data e hora. As informações adicionais sobre o usuário (atributos estendidos) são obtidas por uma chamada para a biblioteca compartilhada CDMF personalizada (cdmf_get_usr_attributes). Essa biblioteca tem a capacidade de fornecer atributos de usuário que podem ser utilizados pelo domínio B durante o processo de mapeamento do usuário. O DES triplo do plug-in criptografa esses dados de token com a chae simétrica gerada pelo utilitário cdsso_key_gen. Esse arquio de chaes é compartilhado e armazenado na sub-rotina [cdsso-domain-keys] do arquio de configuração pdwebpi.conf nos seridores Web aprimorados pelo plug-in do domínio A e do domínio B. O token contém data e hora configuráeis (authtoken-lifetime) que definem a duração do token.a data e hora, quando configuradas apropriadamente, podem eitar ataques de reprodução. 3. O seridor de plug-in do domínio A redireciona o pedido, incluindo o token criptografado, de olta ao naegador e, em seguida, ao seridor de plug-in do domínio B (redirecionamento HTTP). 4. O seridor de plug-in do domínio B utiliza sua ersão do mesmo arquio de chaes para decriptografar a alidar o token à medida que ele chega do domínio de referência. O seridor de plug-in do domínio B faz uma chamada para uma biblioteca do mecanismo de autenticação CDSSO. Essa biblioteca CDSSO, por sua ez, faz 154 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

uma chamada para a biblioteca CDMF personalizada, que executa o mapeamento real do usuário (cdmf_map_usr). A biblioteca CDMF transmite a identidade do usuário e todas as informações de atributos estendidos de olta para a biblioteca CDSSO. A biblioteca CDSSO utiliza essas informações para construir uma credencial. 5. O seriço de autorização do domínio B permite ou nega o acesso a objetos protegidos com base na credencial do usuário e nas permissões de ACL específicas associadas aos objetos solicitados. Atiando e Desatiando a Autenticação CDSSO A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a autenticação CDSSO, atribua o termo cdsso ao parâmetro authentication: [common-modules] authentication = cdsso Ao utilizar a autenticação CDSSO, o plug-in também dee ser configurado para o processamento pós-autorização CDSSO. Na sub-rotina [common-modules] do arquio de configuração pdwebpi.conf, adicione o parâmetro post-authzn, conforme mostrado a seguir: [common-modules] authentication = cdsso post-authzn = cdsso A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e o respectio nome da biblioteca compartilhada associada. Assegure-se de que a entrada para a autenticação com base em formulários esteja presente: [modules] cdsso = pdwpi-cdsso-module Criptografando os Dados do Token de Autenticação O plug-in dee criptografar os dados de autenticação colocados no token utilizando uma chae gerada pelo utilitário cdsso_key_gen. É necessário sincronizar essa chae compartilhando o arquio de chaes com cada seridor Web aprimorado pelo plug-in de cada domínio participante. Cada seridor de plug-in participante em cada domínio precisa utilizar a mesma chae. Nota: A criação e a distribuição de arquios de chaes não faz parte do processo CDSSO do Tioli Access Manager. Ao ser executado, o utilitário cdsso_key_gen requer que ocê especifique a localização (nome do caminho absoluto) do arquio chae: UNIX: # cdsso_key_gen absolute-pathname Windows: MSDOS> cdsso_key_gen absolute-pathname Insira essa localização do arquio de chaes na sub-rotina [cdsso-domain-keys] do arquio de configuração pdwebpi.conf do seridor de plug-in participante em cada domínio. A sub-rotina [cdsso-domain-keys] deria seu nome a partir do nome de pdwpi-cdsso-module definido na sub-rotina [modules]. Seu formato é [cdsso-module-name-domain-keys]. As chaes de domínio podem ser especificadas Capítulo 6. Soluções de Conexão Entre Domínios 155

para cada host irtual por meio da criação de uma sub-rotina [cdsso-module-namedomain-keys:irtual-host-name]. O formato da entrada inclui o nome do domínio e a localização do arquio de chaes: [cdsso-domain-keys] domain-name = keyfile-location Exemplo de Configuração do Domínio A: [cdsso-domain-keys] www.domainb.com = pathname/a-b.key Exemplo de Configuração do Domínio B: [cdsso-domaina-keys] www.domaina.com = pathname/a-b.key No exemplo anterior, o arquio A-B.key seria gerado em uma máquina (Plug-in A, por exemplo) e copiada manualmente (e com segurança) para a outra máquina (Plug-in B, por exemplo). Configurando a Data e a Hora do Token O token contém uma data e hora configuráeis que definem a duração do token de autenticação. Após a expiração da data e hora, o token é considerado inálido e deixa de ser utilizado. A data e a hora são utilizadas para ajudar a eitar ataques de reprodução definindo um alor curto o suficiente para eitar que o token seja tomado e reproduzido dentro de sua duração. O parâmetro authtoken-lifetime, localizado na sub-rotina [cdsso] do arquio de configuração pdwebpi.conf, define o alor de duração do token. Esse alor é expresso em segundos. O alor padrão é 180: [cdsso] authtoken-lifetime =180 Esse alor pode ser substituído para cada host irtual. É necessário lear em consideração qualquer inclinação de clock entre os domínios participantes. Incluindo Atributos de Credencial nos Tokens de Autenticação É possíel incluir atributos de credencial nos tokens CDSSO especificando-os na sub-rotina [cdsso-token-attributes] do arquio de configuração do plug-in. Os atributos a serem incluídos podem ser especificadas ponto a ponto a para cada domínio. A lista de atributos de credencial nessa sub-rotina apenas é releante quando as bibliotecas SSO padrão de criação e de consumo de tokens estão em uso. Se ocê não precisar de atributos de credencial em tokens de garantia CDSSO, poderá deixar essa sub-rotina azia. O nome padrão dessa sub-rotina é deriado do nome do módulo para pdwpi-cdsso-module, definido na sub-rotina [modules]. Seu formato é [cdsso_module_name-token-attributes]. Os alores na sub-rotina [cdsso-token-attributes] são o padrão entre todos os hosts irtuais e podem ser substituídos para cada host irtual criando uma sub-rotina [cdsso_module_name-token-attributes:irtual_host]. O formato das entradas é: domain_name = pattern1, pattern2,... pattern n. Os atributos de credencial correspondentes aos padrões especificados para um domínio ou host de destino são incluídos em tokens de garantia CDSSO 156 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

construídos para esse domínio ou host de destino. Apenas um único alor para cada atributo é utilizado e apenas alores de cadeia são suportados. Outros tipos de alores de atributos de credencial são ignorados. Padrões podem ser especificados com o uso dos caracteres de correspondência de padrões explicados no Apêndice E, Caracteres Especiais Permitidos em Expressões Comuns, na página 235. Por exemplo: [cdsso-token-attributes] ibm.com = attrprefix_*, *name* tioli.com = *_attrsuffix, some_exact_attribute Um conjunto padrão de atributos pode ser configurado com o uso de uma entrada <default> nessa sub-rotina. Esse conjunto padrão de atributos é utilizado quando não existe nenhuma outra entrada correspondente a um host de destino específico. Se a entrada <default> não estier presente, nenhum atributo será incluído por padrão. Aceitando e Rejeitando Atributos de Credencial a partir de Tokens de Autenticação CDSSO É possíel especificar os atributos de credencial a serem aceitos e a serem rejeitados a partir de tokens de autenticação CDSSO de entrada especificando os alores na sub-rotina [cdsso-incoming-attributes]. Ao contrário da configuração de atributos de saída, os atributos de entrada não podem ser configurados ponto a ponto ou para cada domínio. Apenas um conjunto de padrões de atributos pode ser configurado, e esses padrões serão aplicados aos tokens de entrada independentemente da origem. Esse processamento apenas ocorrerá se as bibliotecas SSO padrão de criação e de consumo de tokens estierem em uso. O nome padrão dessa sub-rotina é deriado do nome do módulo para pdwpi-cdsso-module, definido na sub-rotina [modules]. Seu formato é [cdsso_module_name-incoming-attributes]. Os alores nessa sub-rotina são o padrão entre todos os hosts irtuais. Entretanto, podem ser substituídos para cada host irtual configurando uma sub-rotina [cdsso_module_name-incomingattributes:irtual_host]. O formato das entradas nessa sub-rotina é: attribute_pattern = presere refresh Os atributos em tokens CDSSO correspondentes a uma entrada refresh são remoidos do token antes de a biblioteca CDMF ser chamada para mapear o usuário remoto para o domínio local. Os atributos correspondentes a uma entrada presere, ou não correspondentes a nenhuma entrada, são retidos. Se nenhuma entrada estier configurada, todos os atributos serão retidos. Especifique as Bibliotecas sso-create e sso-consume Para especificar as bibliotecas sso-create e sso-consume, edite o arquio de configuração do plug-in. Na sub-rotina [authentication-mechanisms], desfaça o comentário da entrada para sso-create e sso-consume e adicione o nome da biblioteca de de cookies de failoer do plug-in apropriada para o tipo de sistema operacional. A entrada do arquio de configuração padrão é: [authentication-mechanisms] sso-create = /opt/pdwebrte/lib/ibssocreate.so sso-consume = /opt/pdwebrte/lib/libssoconsume.so Capítulo 6. Soluções de Conexão Entre Domínios 157

Como alternatia, quando ocê tier desenolido uma biblioteca CDAS que implemente uma ersão personalizada da funcionalidade de sso-create e sso-consume, insira o nome do CDAS personalizado como o alor para a palara-chae do arquio de configuração. Por exemplo, se ocê tier desenolido um CDAS personalizado para sso-create, insira o nome do caminho absoluto: [authentication-mechanisms] sso-create = /dir_name/custom_cdas_sso-create.so Expressando Links CDSSO Os links para recursos em um domínio protegido secundário deem conter uma expressão CDSSO especial que é configurada com o uso do parâmetro uri na sub-rotina [cdsso] do arquio de configuração. O alor padrão é /pkmscdsso: /pkmscdsso?destinationurl Quando configurado como um módulo de pós-autorização, os pedidos para /pkmscdsso?remote-uri redirecionarão o cliente a remore-uri?pd-referer=thishost&argument=authentication-token. O nome do argumento da cadeia de consulta que especifica o token de autenticação é configurado com o uso do parâmetro cdsso-argument na sub-rotina [cdsso] do arquio de configuração pdwebpi.conf. O alor padrão é PD-ID. Ele pode ser substituído para cada host irtual. O alor padrão, PD-ID, do parâmetro cdsso-argument apenas dee ser alterado quando uma biblioteca SSO de criação/consumo personalizada está sendo utilizada. Ao utilizar as bibliotecas SSO de criação/consumo fornecidas, o padrão, PD-ID, dee ser utilizado. Protegendo o Token de Autenticação Embora o token de autenticação não contenha informações de autenticação (como nome do usuário e senha), ele contém uma identidade de usuário que é confiáel no domínio receptor. Portanto, o token em si dee ser protegido contra roubo e reprodução. O token é protegido contra roubo na rede com o uso do SSL para proteger as comunicações entre os seridores Web aprimorados pelo plug-in e os usuários. O token pode, de modo concebíel, ser roubado do histórico do naegador do usuário. A data e a hora no token deem ser curtas o suficiente para que seja improáel que o token seja roubado e reproduzido durante a sua duração. Porém, um token que tenha expirado com relação a sua data e hora ainda é ulneráel a ataques criptográficos. Se a chae utilizada para criptografar o token for descoberta ou estier comprometida de qualquer outra forma, um usuário com más intenções poderia construir seus próprios tokens. Esses tokens podem, então, ser inseridos em um fluxo de pseudo-cdsso. Eles não poderiam ser diferenciados dos tokens de autenticação reais para os seridores de plug-in que participam do domínio CDSSO. Por esse motio, as chaes utilizadas para proteger os tokens também deem ser cuidadosamente gerenciadas e alteradas regularmente. 158 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Conexão Única do e-community A funcionalidade de conexão única do e-community do Tioli Access Manager Plug-in para Web Serers permite que os usuários acessem recursos em ários seridores de diersos domínios sem exigir uma reautenticação. Um e-community é um grupo de domínios distintos (Tioli Access Manager ou DNS) que participam em um relacionamento comercial. Esses domínios participantes podem ser configurados como parte de um negócio (e, talez, utilizando nomes DNS diferentes por motios geográficos) ou como diferentes negócios com um relacionamento compartilhado (por exemplo, sede da empresa, uma empresa de seguros de ida e uma empresa de gerenciamento financeiro). Em qualquer um dos cenários, sempre há um domínio que é designado o domínio inicial ou proprietário. No caso dos negócios participantes, o domínio inicial possui os acordos comerciais que goernam o e-community. Em ambos os cenários, as informações de autenticação sobre os usuários que participam no e-community (incluindo os nomes e senhas de usuários utilizados para autenticação) são mantidas no domínio inicial. Essa disposição permite um único ponto de referência para questões de administração, como chamadas de help desk dentro do e-community que se referem ao domínio inicial. De forma alternatia, ocê pode utilizar o Tioli Access Manager Web Portal Manager para delegar o gerenciamento dessas informações de forma que os domínios participantes tenham responsabilidade pela administração de seus próprios usuários. O domínio inicial possui os usuários isto é, controla as informações de autenticação do usuário. Independentemente de onde um usuário faz um pedido para recursos, o domínio inicial está sempre onde o usuário dee ser autenticado. A autenticação ocorre junto a um MAS (Master Authentication Serer) um seridor (ou conjunto de seridores réplica) que está localizado no domínio inicial e configurado para autenticar todos os usuários. O deer de MAS dee ser restrito ao fornecimento de seriços de autenticação. O MAS não dee conter recursos disponíeis aos usuários. Depois que um usuário autenticou com êxito para o MAS, o MAS gera um token de garantia. Esse token é transmitido de olta ao seridor onde o usuário está fazendo o pedido. O seridor trata esse token de garantia como proa de que o usuário autenticou com êxito para o MAS e pode participar do e-community. A transferência de informações entre domínios do e-community é descrita em detalhes na seção Fluxo do Processo da Conexão Única do e-community na página 160. Recursos e Requisitos da Conexão Única do e-community A conexão única do e-community apresenta os seguintes recursos e requisitos: A funcionalidade do e-community suporta o acesso utilizando URLs diretos (marcadores) para recursos. A implementação do e-community requer uma configuração consistente atraés de todos os plug-ins em todos os domínios participantes do e-community. Todos os usuários que estão participando do e-community autenticam junto a um único MAS (Master Authentication Serer) localizado no domínio inicial. Capítulo 6. Soluções de Conexão Entre Domínios 159

A implementação do e-community permitirá a autenticação local em domínios remotos se o usuário não tier uma conta álida com o MAS. Um usuário que falha na autenticação com o MAS quando está solicitando um recurso em um domínio não-mas (mas participante) recebe a opção de autenticar para o seridor local onde o pedido está sendo feito. O MAS (e, conseqüentemente, outros seridores selecionados nos domínios remotos) garante a identidade autenticada do usuário. Cookies específicos do domínio são utilizados para identificar o seridor que pode fornecer seriços de garantia. Isso permite que os seridores em um domínio remoto solicitem informações de garantia localmente. O conteúdo criptografado de cookies do e-community não contém a identidade do usuário ou informações de segurança. Tokens especiais são utilizados para transmitir identidades do usuário garantidas criptografadas. O token de garantia não contém informações reais de autenticação do usuário. A integridade é fornecida pela chae secreta compartilhada (DES-triplo). O token contém um alor de tempo limite (duração) para limitar a duração da alidade do token. A implementação do e-community é suportada em HTTP e HTTPS. A configuração para o e-community é definida no arquio pdwebpi.conf de cada plug-in participante. Fluxo do Processo da Conexão Única do e-community Um e-community consiste em um MAS (Master Authentication Serer) aperfeiçoado pelo plug-in e em seridores adicionais aperfeiçoados pelo plug-in agindo como um e-community. A solução de conexão única do e-community também pode interoperar com recursos protegidos do WebSEAL. A implementação do e-community é baseada em um sistema de garantia. Normalmente, quando usuários não autenticados solicitam um recurso atraés do plug-in, são solicitadas a eles informações de autenticação. Em uma configuração do e-community, o seridor de plug-in identifica um seridor de garantia e solicita a erificação deste seridor de garantia que o usuário autenticou. O seridor de garantia armazena informações álidas de credenciais para o usuário. Para o primeiro pedido do usuário, o seridor de garantia é sempre o MAS. O MAS continua a serir como o seridor de garantia para recursos localizados no domínio inicial. Como o usuário continua com pedidos de recurso atraés do e-community, um seridor indiidual em cada domínio remoto pode construir sua própria credencial para o usuário (com base nas informações de identidade do usuário do MAS) e assumir a função de seridor de garantia para recursos em seu domínio. 160 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Figura 9. Registrando em um e-community. O exemplo acima mostra dois domínios, o domínio IBM e o domínio Lotus, que existem dentro de um e-community. Os processos a seguir ocorrem na primeira ez que um usuário efetua logon em um Web site seguro dentro do e-community: 1. O usuário solicita acesso a um recurso no seridor Web ww1.ibm.com. O plug-in intercepta o pedido e confirma se ww1.ibm.com está configurado como parte do e-community Tioli-IBM-Lotus. O seridor MAS no e-community é identificado a partir da configuração de ww1.ibm.com. 2. O pedido é transmitido para o MAS - www.tioli.com. O MAS autentica o pedido em nome de ww1.ibm.com e emite um token de garantia que se transforma na identidade do e-community do usuário. As informações de identidade do usuário no token são criptografadas. 3. O MAS enia o token de garantia para ww1.ibm.com, que trata esse token de garantia como proa de que o usuário foi autenticado com êxito no MAS e que já pode acessar o recurso solicitado com base em controles normais de autorização. O Cookie do e-community O cookie do e-community é um cookie específico do domínio definido por um plug-in, armazenado na memória do naegador do usuário e transmitido a outras instâncias do plug-in (no mesmo domínio) em pedidos subseqüentes. O cookie específico do domínio contém o nome do seridor de garantia, a identidade do e-community, uma localização (URL) do seridor de garantia e funcionalidade e um alor de duração. O cookie não contém informações sobre o usuário. Capítulo 6. Soluções de Conexão Entre Domínios 161

O cookie do e-community permite que os seridores nos domínios participantes solicitem informações de garantia localmente. O cookie do e-community para o domínio onde o MAS está localizado desempenha uma função menos significatia. O cookie possui um alor de duração (tempo limite) que é definido no arquio de configuração pdwebpi.conf. Esse alor de duração especifica por quanto tempo um seridor remoto é capaz de fornecer informações de garantia ao usuário. Quando a duração do cookie expirar, o usuário deerá ser redirecionado ao MAS para autenticação. O cookie é excluído da memória quando o naegador é fechado. Se o usuário efetuar logout de um domínio específico, o cookie do e-community será sobrescrito como azio. Esta ação efetiamente o remoe do naegador. O Pedido e a Resposta de Garantia A operação de garantia do e-community requer uma funcionalidade dedicada acessada atraés de dois URLs construídos especialmente: o pedido de garantia e a resposta de garantia. Esses URLs são construídos durante os redirecionamentos HTTP de garantia do e-community com base nas informações de configuração em pdwebpi.conf. O Pedido de Garantia O pedido de garantia é acionado quando um usuário solicita um recurso de um seridor de destino (configurado para o e-community) que não contém informações de credenciais para esse usuário. O seridor enia um redirecionamento HTTP para o seridor de garantia (o MAS ou um seridor identificado em um cookie do e-community). O pedido de garantia contém as seguintes informações: https://ouch_for_serer/pkmsouchfor?ecommunity_name&target_url O seridor que está recebendo erifica o ecommunity_name para alidar a identidade do e-community. O seridor que está recebendo utiliza target_url na resposta de garantia para redirecionar o naegador de olta à página solicitada originalmente. O URL de garantia pkmsouchfor é configuráel. Por exemplo: https://www.tioli.com/pkmsouchfor?companyabc&https://ww2.lotus.com/index.html A Resposta de Garantia A resposta de garantia é a resposta do seridor de garantia para o seridor de destino. A resposta de garantia contém as seguintes informações: https://target_url?pd-vfhost=ouch_for_serer&pd-vf=encrypted_token O parâmetro PD-VFHOST identifica o seridor que executou a operação de garantia. O seridor receptor (de destino) utiliza essas informações para selecionar a chae correta necessária para decriptografar o token de garantia (PD-VF). O parâmetro PD-VF representa o token de garantia criptografado. Por exemplo: https://ww2.lotus.com/index.html?pd-vfhost=www.tioli.com&pd-vf=3qhe9fjkp...ge56wgb 162 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

O Token de Garantia Para realizar a conexão única entre domínios, algumas informações de identidade do usuário deem ser transmitidas entre os seridores. Essas informações sensíeis são identificadas utilizando um redirecionamento que inclui as informações de identidade criptografadas como parte do URL. Esses dados criptografados são chamados de token de garantia. O token contém o status de êxito ou falha de garantia, a identidade do usuário (se bem-sucedido), o nome completo do seridor que criou o token, a identidade do e-community e um alor de tempo de criação. O portador de um token de garantia álido pode utilizar esse token para estabelecer uma sessão (e conjunto de credenciais) em um seridor sem explicitamente autenticar para esse seridor. O token é criptografado utilizando uma chae secreta DES-triplo compartilhada para que sua autenticidade possa ser erificada. As informações do token criptografado não são armazenadas no naegador. O token é transmitido apenas uma ez. O seridor que está recebendo utiliza essas informações para construir credenciais do usuário em seu próprio cache. O seridor utiliza essas credenciais para pedidos futuros desse usuário durante a mesma sessão. O token possui um alor de duração (tempo limite) que é definido no arquio de configuração pdwebpi.conf. Esse alor pode ser muito curto (segundos) para reduzir o risco de um ataque de reprodução. Nota: A segurança de tokens foi aprimorada no release 4.1 do plug in. Os aprimoramentos não são interoperáeis com o esquema de codificação de tokens do Tioli Access Manager 3.9. Para continuar a poder interoperar com ersões 3.9 do Tioli Access Manager Web Security, defina o parâmetro de configuração pre-410-compatible-tokens na sub-rotina [pdweb-plugins] como true. Esse parâmetro abrange todos os processos e não pode ser especificado para cada host irtual. Criptografando o Token de Garantia O Tioli Access Manager Plug-in para Web Serers dee criptografar os dados de autenticação colocados no token usando uma chae gerada pelo utilitário cdsso_key_gen, localizado no diretório pdwebrte/bin. É necessário sincronizar essa chae compartilhando o arquio de chaes com cada seridor de plug-in em cada domínio participante. Cada seridor de plug-in participante em cada domínio precisa utilizar a mesma chae. Nota: A criação e a distribuição de arquios de chaes não faz parte do processo do e-community do Tioli Access Manager.Você dee copiar as chaes manualmente e com segurança para cada seridor participante. Ao ser executado, o utilitário cdsso_key_gen requer a especificação do seu caminho completo e da localização (nome do caminho absoluto) do arquio de chaes: UNIX: Windows: # /opt/pdwebrte/bin/cdsso_key_gen absolute_pathname MSDOS> install_path/pdwebrte/bin/cdsso_key_gen absolute_pathname Capítulo 6. Soluções de Conexão Entre Domínios 163

As chaes de criptografia são configuradas na sub-rotina [ecsso-domain-keys] do arquio de configuração pdwebpi.conf. Os detalhes dessa configuração são discutidos na próxima seção, Configurando um e-community. Configurando um e-community Esta seção reisa todos os parâmetros de configuração necessários para uma implementação do e-community. Esses parâmetros estão localizados no arquio pdwebpi.conf. Esse arquio dee ser cuidadosamente configurado para cada plug-in participante do e-community. Atiando e Desatiando Membros do e-community A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar um seridor de plug-in de forma que ele opere em um e-community, atribua o termo ecsso aos parâmetros authentication e pre-authzn, conforme mostrado a seguir: [common-modules] authentication = ecsso pre-authzn = ecsso Durante a configuração para membros do e-community não-mas, a autenticação ecsso dee ter precedência sobre outros esquemas de autenticação, ou seja, o ecsso dee ser especificado antes dos outros esquemas de autenticação na lista de módulos de autenticação. Além disso, se o módulo ecsso precisar ter precedência sobre um módulo de autenticação especificado com um níel de autenticação mais alto que 1 (o padrão), o próprio módulo ecsso deerá ser configurado com, pelo menos, o mesmo níel de autenticação. A sub-rotina [modules] no arquio de configuração pdwebpi.conf define todos os mecanismos de autenticação disponíeis e os respectios nomes das bibliotecas compartilhadas associadas. Assegure-se de que a entrada para a SSO do e-community esteja presente: [modules] ecsso = pdwpi-ecsso-module e-community-name O parâmetro e-community-name identifica o nome do e-community ao qual o seridor pertence. Por exemplo: [ecsso] e-community-name = companyabc O alor de e-community-name dee ser o mesmo para todos os membros de um e-community. is-master-authn-serer Esse parâmetro identifica se esse seridor é ou não o MAS. Os alores possíeis são yes ou no. Ele seria definido da seguinte maneira para o MAS do e-community: [ecsso] is-master-authn-serer = yes Vários plug-ins podem ser configurados para agirem como seridores de autenticação master e, em seguida, colocados atrás de um recurso de equilíbrio de carga. Nesse cenário, o recurso de equilíbrio de carga é reconhecido como o MAS por todos os outros seridores de plug-in no e-community. 164 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Se is-master-authn-serer for definido como yes, esse seridor aceitará pedidos de garantia a partir de outras instâncias de plug-in com um e-community-name igual e cujas chaes de domínio estejam listadas na sub-rotina [ecsso-domain-keys]. master-authn-serer Se o parâmetro is-master-authn-serer for definido como no, o parâmetro master-authn-serer deerá ser especificado e será necessário desfazer seu comentário. O parâmetro identifica o nome completo do domínio do MAS do e-community. Por exemplo: [ecsso] master-authn-serer = www.tioli.com master-http-port Atribua o número da porta utilizada pelo seridor de autenticação master para receber pedidos HTTP. Se o número da porta não for a porta 80 padrão, o número da porta não padrão deerá ser especificado aqui. [ecsso] master-http-port = port_number master-https-port Atribua o número da porta utilizada pelo seridor de autenticação master para receber pedidos HTTPS. Se o número da porta não for a porta 443 padrão, o número da porta não padrão deerá ser especificado aqui. [ecsso] master-https-port = port_number f-token-lifetime Esse parâmetro define o alor de tempo limite de duração (em segundos) do token de garantia. Esse alor é erificado com base na hora de criação marcada no cookie. O alor padrão é de 180 segundos. É necessário lear em consideração qualquer inclinação de clock entre os seridores participantes.por padrão, o parâmetro é definido como: [ecsso] f-token-lifetime = 180 f-url Esse parâmetro especifica o URL de garantia. O alor dee começar com uma barra (/). O alor da definição padrão é: [ecsso] f-url = /pkmsouchfor Também é possíel expressar um URL estendido: f-url = /ecomma/pkmsouchfor f-argument O alor do parâmetro f-argument é o nome do argumento do token de garantia que aparece na resposta de garantia. O alor de PD-VF apenas deerá ser alterado se módulos personalizados de criação e consumo estierem em uso e se um nome de argumento diferente for utilizado para representar o token de garantia. O alor é utilizado para construir respostas de garantia pelo MAS e para diferenciar pedidos de entrada como pedidos com informações de garantia pelos seridores ECSSO participantes. [ecsso] f-argument = PD-VF Capítulo 6. Soluções de Conexão Entre Domínios 165

allow-login-retry Um MAS que utiliza um esquema de autenticação com base em nome do usuário e senha possuirá duas opções quando um usuário tier efetuado um logon sem êxito: poderá solicitar que o usuário insira noamente suas credenciais ou poderá redirecioná-lo imediatamente de olta ao seridor que ele tentou acessar originalmente sem estabelecer uma garantia para esse usuário. No último caso, o usuário será forçado a se autenticar diretamente no seridor subordinado. O parâmetro allow-login-retry controla esse comportamento no MAS. Esse parâmetro somente é aplicáel à configuração do MAS em uma comunidade ecsso. Nota: Os usuários podem tentar redefinir uma senha expirada. Outras falhas de login que ocorrerem no MAS, como uma conta bloqueada, causarão um redirecionamento imediato de olta ao seridor subordinado, independentemente do alor do parâmetro allow-login-retry. Por padrão, o parâmetro é definido como: [ecsso] allow-login-retry = true use-utf8 Esse parâmetro controla a codificação de cadeias nos cookies do e-community e nos tokens de garantia ECSSO. O alor desse parâmetro apenas afeta tokens de garantia criados e consumidos pelas bibliotecas SSO padrão de criação e de consumo. [ecsso] use-utf8 = true Chaes de Domínio ecsso As localizações dos arquios de chaes necessários para criptografar e decriptografar tokens entre o MAS e os seridores participantes de domínios remotos são definidas na sub-rotina [ecsso-domain-keys] do arquio de configuração. A configuração do MAS enole a definição das chaes para cada domínio do qual ele é o master. A configuração de membros do e-community que não sejam o MAS enole a definição da chae para o domínio e para o MAS. É necessário especificar os nomes completos dos domínios para os seridores e os nomes dos caminhos absolutos para as localizações dos arquios de chaes. O seguinte exemplo de configuração do MAS fornece ao MAS, localizado no domínio tioli.com, arquios de chaes para comunicação com dois domínios remotos: [ecsso-domain-keys] ibm.com = /abc/xyz/ibm-tioli.key lotus.com = /abc/xyz/lotus-tioli.key tioli = /abc/xyz/tioli.key Nota: No exemplo anterior, é essencial ter tioli.key para o intercâmbio de dados entre seridores no domínio tioli. A configuração para seridores no domínio enole a especificação do domínio do MAS e da chae correspondente utilizada para o intercâmbio de informações com o MAS. Uma chae também é necessária para o intercâmbio de dados entre seridores no domínio. Por exemplo, a sub-rotina [ecsso-domain-keys] para um seridor em um domínio participante de um e-community pode ter a seguinte aparência: 166 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

[ecsso-domain-keys] #the key for data exchange between the MAS (tioli.com) #and the ibm.com domain serers tioli.com = /abc/xyz/ibm-tioli.key #the key for data exchange between serers in the ibm.com domain ibm.com = /abc/xyz/ibm.key Incluindo Atributos de Credencial nos Tokens de Garantia É possíel incluir atributos de credencial nos tokens de garantia ecsso especificando-os na sub-rotina [ecsso-token-attributes] do arquio de configuração do plug-in. Os atributos a serem incluídos podem ser especificadas ponto a ponto a para cada domínio. A lista de atributos de credencial nessa sub-rotina apenas é releante quando as bibliotecas SSO padrão de criação e de consumo de tokens estão em uso. Se ocê não precisar de atributos de credencial em tokens de garantia ecsso, poderá deixar essa sub-rotina azia. O nome padrão dessa sub-rotina é deriado do nome do módulo para pdwpi-ecsso-module, definido na sub-rotina [modules]. Seu formato é [ecsso_module_name-token-attributes]. Os alores na sub-rotina [ecsso-token-attributes] são o padrão entre todos os hosts irtuais e podem ser substituídos para cada host irtual criando uma sub-rotina [ecsso_module_name-token-attributes:irtual_host]. O formato das entradas é: domain_name = pattern1, pattern2,... pattern n. Os atributos de credencial correspondentes aos padrões especificados para um domínio ou host de destino são incluídos em tokens de garantia ecsso construídos para esse domínio ou host de destino. Apenas um único alor para cada atributo é utilizado e apenas alores de cadeia são suportados. Outros tipos de alores de atributos de credencial são ignorados. Padrões podem ser especificados com o uso dos caracteres de correspondência de padrões explicados no Apêndice E, Caracteres Especiais Permitidos em Expressões Comuns, na página 235. Por exemplo: [ecsso-token-attributes] ibm.com = attrprefix_*, *name* tioli.com = *_attrsuffix, some_exact_attribute Um conjunto padrão de atributos pode ser configurado com o uso de uma entrada <default> nessa sub-rotina. Esse conjunto padrão de atributos é utilizado quando não existe nenhuma outra entrada correspondente a um host de destino específico. Se a entrada <default> não estier presente, nenhum atributo será incluído por padrão. Aceitando e Rejeitando Atributos de Credencial a partir de Tokens de Garantia É possíel especificar os atributos de credencial a serem aceitos e a serem rejeitados a partir de tokens de garantia de entrada especificando os alores na sub-rotina [ecsso-incoming-attributes]. Ao contrário da configuração de atributos de saída, os atributos de entrada não podem ser configurados ponto a ponto ou para cada domínio. Apenas um conjunto de padrões de atributos pode ser configurado, e esses padrões serão aplicados aos tokens de entrada independentemente da origem. Esse processamento apenas ocorrerá se as bibliotecas SSO padrão de criação e de consumo de tokens estierem em uso. O nome padrão dessa sub-rotina é deriado do nome do módulo para pdwpi-ecsso-module, definido na Capítulo 6. Soluções de Conexão Entre Domínios 167

sub-rotina [modules]. Seu formato é [ecsso_module_name-incoming-attributes]. Os alores nessa sub-rotina são o padrão entre todos os hosts irtuais. Entretanto, podem ser substituídos para cada host irtual configurando uma sub-rotina [ecsso_module_name-incoming-attributes:irtual_host]. O formato das entradas nessa sub-rotina é: attribute_pattern = presere refresh Os atributos em tokens de garantia ecsso correspondentes a uma entrada refresh são remoidos do token antes de a biblioteca CDMF ser chamada para mapear o usuário remoto para o domínio local. Os atributos correspondentes a uma entrada presere, ou não correspondentes a nenhuma entrada, são retidos. Se nenhuma entrada estier configurada, todos os atributos serão retidos. Especifique as Bibliotecas sso-create e sso-consume Para especificar as bibliotecas sso-create e sso-consume, edite o arquio de configuração do plug-in. Na sub-rotina [authentication-mechanisms], desfaça o comentário da entrada para sso-create e sso-consume e adicione o nome da biblioteca de de cookies de failoer do plug-in apropriada para o tipo de sistema operacional. A entrada do arquio de configuração padrão é: [authentication-mechanisms] sso-create = /opt/pdwebrte/lib/ibssocreate.so sso-consume = /opt/pdwebrte/lib/libssoconsume.so Como alternatia, quando ocê tier desenolido uma biblioteca CDAS que implemente uma ersão personalizada da funcionalidade de sso-create e sso-consume, insira o nome do CDAS personalizado como o alor para a palara-chae do arquio de configuração. Por exemplo, se ocê tier desenolido um CDAS personalizado para sso-create, insira o nome do caminho absoluto: [authentication-mechanisms] sso-create = /dir_name/custom_cdas_sso-create.so A falha ao configurar corretamente as chaes keys gera aisos no arquio de log do plug-in. Configurando a Conexão Única do e-community - um Exemplo No exemplo a seguir, existem dois e-communities configurados lotus-domino e ibm-db2 com um único MAS autenticando os pedidos para ambas as comunidades. 168 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Figura 10. Exemplo de Configuração da Conexão Única do e-community As seguintes condições aplicam-se a este exemplo: www.tioli.com é o MAS para os dois e-communities. Existem dois domínios distintos (um seridor em cada domínio por questões de simplicidade) no e-community lotus-domino domino.com e lotus.com. Os usuários que acessam um desses domínios podem acessar o outro sem precisarem se reautenticar, pois todo o acesso é concedido por meio do MAS. O e-community ibm-db2 contém dois domínios distintos ibm.com e db2.com. Os usuários que acessam um desses domínios podem acessar o outro sem precisarem se reautenticar. Os usuários que acessam um dos seridores ibm.com podem acessar o outro utilizando um token de garantia. A conexão única nesse caso é realizada sem que o MAS precise conceder acesso. No exemplo anterior, as seguintes opções de configuração são aplicáeis: Configuração do MAS www.tioli.com Como o MAS é o centro de controle para mais de um e-community, duas instâncias diferentes do módulo ecsso precisam ser configuradas, e os nomes dos e-communities controlados pelo MAS precisam ser definidos. O MAS dee ter especificado todas as chaes dos domínios principais em todas as comunidades que ele controla. A configuração é definida da seguinte maneira: [modules] ecsso1 = pdwpi-ecsso-module ecsso2 = pdwpi-ecsso-module [common-modules] authentication = ecsso1 authentication = ecsso2 pre-authzn = ecsso1 pre-authzn = ecsso2 [ecsso1] Capítulo 6. Soluções de Conexão Entre Domínios 169

e-community-name = lotus-domino is-master-authn-serer = yes...etc [ecsso2] e-community-name = ibm-db2 is-master-authn-serer = yes...etc [ecsso1-domain-keys] # one key for each domain the MAS controls domino.com = /abc/tiolikeys/tioli-domino.key lotus.com = /abc/tiolikeys/tioli-lotus.key db2.com = /abc/tiolikeys/tioli-db2.key ibm.com = /abc/tiolikeys/tioli-ibm.key Configuração de www.domino.com [modules] ecsso = pdwpi-ecsso-module [common-modules] authentication = ecsso pre-authzn = ecsso [ecsso] e-community-name = lotus-domino is-master-authn-serer = no master-authn-serer = www.tioli.com...etc [ecsso-domain-keys] #key for encrypting/decrypting data #between serers in the domino.com domain domino.com = /abc/domino-keys/domino.key #key for encrypting/decrypting data between #serers in the domino.com domain and the MAS tioli.com = /abc/domino-keys/tioli-domino.key Configuração de www.lotus.com Os parâmetros de configuração para realizar a conexão única com www.lotus.com serão idênticos aos configurados para www.domino.com, com exceção das chaes de domínio, que serão diferentes. A configuração das chaes de domínio para www.lotus.com poderia ser: [ecsso-domain-keys] #key for encrypting/decrypting data #between serers in the lotus.com domain lotus.com = /abc/lotus-keys/lotus.key #key for encrypting/decrypting data #between serers in the lotus.com domain and the MAS tioli.com = /abc/lotus-keys/tioli-lotus.key Configuração de www.db2.com [modules] ecsso = pdwpi-ecsso-module [common-modules] authentication = ecsso pre-authzn = ecsso [ecsso] e-community-name = ibm-db2 is-master-authn-serer = no master-authn-serer = www.tioli.com...etc 170 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

[ecsso-domain-keys] #key for encrypting/decrypting data #between serers in the db2.com domain db2.com = /abc/db2-keys/db2.key #key for encrypting/decrypting data between #serers in the db2.com domain and the MAS tioli.com = /abc/db2-keys/tioli-db2.key Configuração de ww1.ibm.com A configuração da conexão única do e-community para ww1.ibm.com é idêntica à configuração de www.db2.com. Duas chaes são necessárias, uma para criptografar/decriptografar dados entre o MAS e o domínio ibm.com e outra para criptografar/decriptografar dados entre seridores no domínio ibm.com (ou seja, ww1.ibm.com e ww2.ibm.com, neste exemplo). [ecsso-domain-keys] ibm.com = /abc/ibm-keys/ibm.key tioli.com = /abc/ibm-keys/tioli-ibm.key Configuração de ww2.ibm.com A definição de chaes para ww2.ibm.com será idêntica à definição de chaes para ww1.ibm.com. [ecsso-domain-keys] ibm.com = /abc/ibm-keys/ibm.key tioli.com = /abc/ibm-keys/tioli-ibm.key Capítulo 6. Soluções de Conexão Entre Domínios 171

172 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Capítulo 7. Integração de Aplicatios O Tioli Plug-in para Web Serers suporta a integração de aplicatios de terceiros por meio de ariáeis de ambiente e da capacidade de URLs dinâmicos. O plug-in amplia a extensão de ariáeis de ambiente e cabeçalhos HTTP de forma a permitir que aplicatios de terceiros executem operações com base na identidade de um cliente. Além disso, o plug-in pode fornecer controle de acesso sobre URLs dinâmicos, como os que contêm texto de consulta. Os tópicos a seguir são discutidos neste capítulo: Mantendo o Estado de Sessões Entre o Cliente e os Aplicatios Backend Fornecendo Controle de Acesso a URLs Dinâmicos na página 176 Mantendo o Estado de Sessões Entre o Cliente e os Aplicatios Backend Conforme discutido em Gerenciando o Estado de Sessões na página 52, o Tioli Access Manager para Web Serers pode manter o estado de sessões entre clientes ia HTTP e HTTPS utilizando árias informações diferentes. O plug-in também pode fornecer informações de sessões do usuário a aplicatios backend de forma que esses aplicatios possam manter o estado de sessões com os clientes. O fornecimento de informações de sessões do usuário dessa maneira proporciona um método para identificar a sessão do usuário e oferece a capacidade de eliminar uma sessão de usuário mediante a solicitação do aplicatio protegido pelo plug-in. Sem um estado de sessão estabelecido entre o cliente e o seridor, a comunicação entre eles deerá ser noamente negociada para cada pedido subseqüente. As informações de estado de sessões aprimoram o desempenho, eliminando a repetição de fechamentos e noas aberturas de conexões entre cliente/seridor. O cliente pode efetuar login uma ez e fazer diersos pedidos sem efetuar um login separado para cada um desses pedidos. Atiando o Gerenciamento de IDs de Sessão do Usuário O parâmetro add-session-id-to-cred na sub-rotina [performance] do arquio de configuração do plug-in permite atiar e desatiar a criação de um ID de Sessão do Usuário exclusio na credencial de cada cliente que faz um pedido. O alor padrão é true (atiado): [performace] add-session-id-to-cred = true Para desatiar a criação de IDs de Sessão do Usuário exclusios, defina add-session-id-to-cred como false. O ID de Sessão do Usuário exclusio é armazenado na credencial de um usuário como um atributo estendido com um nome e um alor: tagalue_user_session_id = user-session-id Na própria credencial, o nome do arquio de configuração de credencial (user_session_id) aparece com um prefixo de alor de marcação que pode ser configurado com o uso do parâmetro tag-alue-prefix na sub-rotina Copyright IBM Corp. 2000, 2003 173

[pdweb-plugins] do arquio de configuração. A especificação de um prefixo preine conflitos com outras informações existentes na credencial. O alor do ID de Sessão do Usuário é uma cadeia que identifica exclusiamente uma sessão específica para um usuário autenticado. O ID de Sessão do Usuário é uma cadeia codificada em MIME-64 que inclui o nome da instância de plug-in (para suportar árias instâncias de plug-in) e o ID de sessão do plug-in padrão para o usuário. Um único usuário que efetua login árias ezes (por exemplo, a partir de diferentes máquinas) possui diersos IDs de sessão do plug-in. Como o ID de Sessão do Usuário tem como base o ID de sessão do plug-in, existe um mapeamento de um para um entre eles. O ID de sessão do usuário exclusio é armazenado como um atributo para a credencial do usuário. Isso permite que o alor seja transmitido entre campos de junção como um cabeçalho HTTP (utilizando a funcionalidade de alor de marcação) e disponibilizado para um aplicatio backend. Inserindo Dados de Credencial no Cabeçalho HTTP O objetio do gerenciamento de sessões do usuário é fornecer o ID de Sessão do Usuário exclusio ao seridor de aplicatio. Esse objetio é alcançado por meio da configuração do atributo estendido HTTP-Tag-Value no objeto. O comando pdadmin object modify set attribute é utilizado para definir um atributo estendido em um objeto no espaço de objetos protegidos pelo plug-in. pdadmin> object modify object_name set attribute attr_name attr_alue Um atributo ( attr-name ) permite que o plug-in execute um tipo específico de funcionalidade. O atributo HTTP-Tag-Value permite que o plug-in extraia um alor de um atributo estendido de credencial e enie esse alor ao seridor em um cabeçalho HTTP. O alor do atributo estendido HTTP-Tag-Value utiliza o seguinte formato: credential_extended_attribute_name=http_header_name Para dados de IDs de Sessão do Usuário, a entrada credential_extended_attribute_name é igual ao nome do atributo estendido user_session_id especificado no arquio de configuração, mas sem o prefixo configurado. A entrada não faz distinção entre maiúsculas e minúsculas. O alor desse atributo estendido contém o ID de Sessão do Usuário exclusio. A entrada http_header_name especifica o nome do cabeçalho HTTP utilizado para fornecer os dados. Nesse exemplo, é utilizado um cabeçalho denominado PD-USER-SESSION-ID: pdadmin> object modify /PDWebPI/host set attribute \ HTTP-Tag-Value user_session_id=pd-user-session-id Quando o plug-in processa um pedido do usuário para um seridor de aplicatio backend, ele procura qualquer atributo estendido HTTP-Tag-Value que esteja configurado no objeto. Nesse exemplo, o plug-in examina a credencial do usuário que está fazendo o pedido, extrai o alor do ID de Sessão do Usuário a partir do atributo estendido tagalue_user_session_id na credencial e coloca esse alor em um cabeçalho HTTP como: 174 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

PD-USER-SESSION-ID:user_session_id_number Em resumo: Valor do atributo HTTP-Tag-Value definido no objeto do plug-in: Nome do atributo e alor que aparecem na credencial de usuário: Nome e alor do cabeçalho HTTP: user_session_id=pd-user-session-id tagalue_user_session_id:user_session_id_number PD-USER-SESSION-ID:user_session_id_number Se o aplicatio backend for um aplicatio CGI, a especificação CGI determinará que os cabeçalhos HTTP sejam disponibilizados a programas CGI como ariáeis de ambiente no formato: HTTP_HTTP_header_name Por exemplo: HTTP_PD-USER-SESSION-ID=user_session_id Finalizando Sessões de Usuário A funcionalidade do gerenciamento de IDs de sessão do usuário pode ser utilizada para finalizar sessões de usuário de acordo com um ID de sessão do usuário exclusio ou um nome de usuário do Tioli Access Manager. Esses comandos podem ser executados a partir da linha de comandos PDADMIN (utilizando serer task), mas foram planejados para uso por parte de um aplicatio backend por meio da API PDAdmin. A finalização de uma sessão com o uso do ID de Sessão do Usuário faz com que o plug-in descarte a sessão única identificada por esse ID de Sessão do Usuário. Outras sessões do mesmo usuário podem continuar. A finalização com o uso do nome de usuário do Tioli Access Manager faz com que o plug-in descarte TODAS as sessões que pertencem ao nome do usuário determinado. Esse comando poderá finalizar diersas sessões se o usuário tier efetuado login árias ezes a partir de diferentes localizações ou diferentes naegadores. Um usuário pode iniciar a finalização da sessão atual por meio do comando pkmslogout. Além disso, as informações no ID de Sessão do Usuário permitem que administradores e aplicatios backend monitorem e gerenciem usuários. Dois métodos para finalizar sessões de usuário em um níel de administração são descritos a seguir: Um administrador pode usar o utilitário pdadmin para finalizar uma única sessão de usuário utilizando o ID do usuário. pdadmin> serer task pdwebpi-plugin-instance-name terminate all_sessions user-id Utilizando o comando all-sessions conforme mostrado acima, cada sessão para o usuário especificado é finalizada em todos os hosts irtuais na máquina. Esse comando pode ser refinado de forma a finalizar sessões de usuário para um usuário específico em um host irtual determinado utilizando o parâmetro -host, conforme mostrado a seguir, (inserido como uma linha): pdadmin> serer task pdwebpi-plugin-instance-name terminate all_sessions user-id -host "irtual-host-name" Capítulo 7. Integração de Aplicatios 175

Fornecendo Controle de Acesso a URLs Dinâmicos O Tioli Access Manager Plug-in para Web Serers pode aplicar a autorização a objetos da Web com base em uma correspondência de padrões de toda a cadeia do pedido e não apenas no URL do objeto. Isso é útil para aplicatios Web que geram URLs dinamicamente em resposta a cada pedido de usuário que ainda exigem uma intensa proteção contra acesso ou uso não desejado. Isso também é útil para atribuir diferentes permissões a métodos distintos de scripts. Por exemplo, a cadeia de consulta GET/cgi-bin/serercontrol?action=showstatus poderia ter diferentes requisitos de segurança em comparação a GET/cgi-bin/serercontrol?action=shutdown. Cada um desses pedidos talez precise ser representado exclusiamente no espaço de objetos de forma que um critério diferente possa ser aplicado a cada um. O módulo dynurl permite a definição de um conjunto de padrões que são correspondidos com base em pedidos de entrada. Os padrões são correspondidos com base em toda a cadeia do pedido de forma que a correspondência de informações na cadeia de consulta seja possíel. Para cada padrão DynURL, é definido um objeto do Tioli Access Manager. Esse objeto aparece no espaço de objetos de forma o critério possa ser associado a ele. No tempo de execução, qualquer pedido que corresponda a um padrão dynurl é autorizado com o uso do objeto associado ao padrão e não do objeto que representa o URL. Com a definição de diferentes padrões que correspondem independentemente a cadeias de consulta distintas, diferentes objetos do Tioli Access Manager podem ser utilizados e um critério distinto pode ser aplicado. Configurando URLs Dinâmicos A sub-rotina [common-modules] no arquio de configuração pdwebpi.conf define o uso de todos os métodos de autenticação. Para atiar a correspondência de padrões de URLs dinâmicos para pedidos de entrada, o módulo dynurl precisa ser configurado como um módulo de pré-autorização. Isso permite que o módulo dynurl altere o objeto solicitado antes que o mecanismo de autorização seja atingido. [common-modules]... pre-authzn = dynurl... Assegure-se de que a entrada para URLs dinâmicos esteja presente na sub-rotina [modules] do arquio de configuração pdwebpi.conf: [modules]... dynurl = pdwpi-dynurl-module... A sub-rotina [dynurl] (por padrão ou o nome da sub-rotina correspondente ao nome do módulo configurado) contém as definições para o módulo de pré-autorização com base em URLs dinâmicos. Essa sub-rotina pode ser sobrescrita para cada host irtual, ou seja, [dynurl:irtual-host]. As entradas na sub-rotina [dynurl] apresentam o formato object = pattern, com cada entrada em linha separada. A ordem da lista determina a ordem na qual as regras são processadas. As entradas que ocorrem anteriormente na sub-rotina têm precedência sobre as entradas que ocorrem posteriormente na sub-rotina. Por exemplo: 176 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

[dynurl] /serershutdown = /serercontrol.asp\?*action=shutdown* /sererreset = /serercontrol.asp\?*action=reset* /helppages = *help.html Obsere que todos os objetos são iniciados com uma barra inertida ( / ). A última entrada na configuração acima mostra um segundo uso do módulo dynurl. Nesse caso, o padrão corresponde a um conjunto de URLs (qualquer URL que termine com help.html). Nesse caso, DynURL está executando um mapeamento de muitos para um para objetos do Tioli Access Manager. Todos os pedidos para páginas denominadas help.html (independentemente do caminho) serão autorizados com base no mesmo objeto do Tioli Access Manager. Isso pode ser útil em situações nas quais todos os arquios com nomes semelhantes (que podem ser agrupados por um padrão) possuem os mesmos requisitos de segurança. Entretanto, obsere que cada padrão definido é correspondido com base em cada pedido e, portanto, reduz cada autorização. Obsere também que o uso do padrão *help.html pode apresentar implicações de segurança para scripts, pois um pedido para, por exemplo, /serercontrol.asp?action=some_other_action&pointless_ariable _used_to_eade_acl_attached_to_serer_control.asp=help.html corresponderá ao URL dinâmico *help.html. Portanto, o acesso será aaliado com base no objeto /helppages e não no objeto /serercontrol.asp. De forma semelhante, um pedido para /someotherscript?action=someaction&other_ar=help.html será aaliado com base no objeto /helppages e não no objeto /someotherscript. Para obter uma lista dos caracteres especiais permitidos em expressões comuns utilizadas no arquio de configuração de conexão única por formulários, consulte o Apêndice E, Caracteres Especiais Permitidos em Expressões Comuns, na página 235. Na maioria dos casos, caracteres especiais não são necessários porque o pedido da página de login é um único URI identificáel. Em alguns casos, é possíel utilizar * no final da expressão de forma que os dados de consulta no final do URI não preinam a correspondência da página de login. Capítulo 7. Integração de Aplicatios 177

178 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Capítulo 8. Recuperação de Informações sobre Decisões de Autorização Este capítulo contém informações que descreem como o Tioli Access Manager Plug-in para Web Serers pode fornecer, ou adquirir, a ADI (informação sobre decisões de autorização) necessária para aaliar regras de autorização que protegem recursos no domínio do Tioli Access Manager. Os tópicos a seguir são discutidos neste capítulo: 1. Visão Geral da Recuperação da ADI 2. Recuperando a ADI a partir do Pedido de um Cliente do Plug-in na página 180 3. Recuperando uma ADI a partir da Credencial do Usuário na página 182 4. Fornecendo um Motio de Falha na página 182 5. Configurando a Recuperação Dinâmica da ADI na página 183 Visão Geral da Recuperação da ADI O aaliador de regras de autorização do Tioli Access Manager toma decisões de autorização com base em uma lógica Booleana aplicada a uma ADI (informação sobre decisões de autorização) específica. Informações detalhadas sobre a construção de regras de autorização (utilizando uma lógica Booleana) e de uma ADI podem ser encontradas no documento IBM Tioli Access Manager Base: Guia de Administração. A ADI necessária para a aaliação de regras pode ser recuperada a partir das seguintes origens: Parâmetros de decisão de autorização fornecidos à regra de autorização como uma ADI pelo seriço de autorização. Os parâmetros incluem o recurso de destino (objeto protegido) e a ação solicitada no recurso. Consulte o documento IBM Tioli Access Manager Base: Guia de Administração para obter informações adicionais sobre esse tópico. A credencial de usuário A credencial de usuário sempre é incluída com a chamada de função para o aaliador de regras de autorização e, portanto, está imediatamente disponíel. O ambiente do gerenciador de recurso (contexto do aplicatio) Um gerenciador de recurso, como o plug-in, pode ser configurado para fornecer a ADI a partir de seu próprio ambiente. Por exemplo, o plug-in tem a capacidade de fornecer a ADI contida em partes do pedido de um cliente. Um prefixo especial é utilizado na regra de autorização para acionar esse tipo de origem da ADI. Uma origem externa por meio de seriços de recuperação dinâmica da ADI. A ADI pode ser obtida externamente por meio do seriço da Web AMWebARS. Uma chamada é feita para o seriço da Web AMWebARS por meio do seriço de autorização do gerenciador de recurso. A ADI a partir da origem externa é retornada no formato XML ao aaliador de regras de autorização. A ADI pode ser obtida dinamicamente por meio de chamadas para seriços de autorização específicos que foram configurados para recuperar a ADI dinamicamente durante a aaliação de regras. Uma chamada é feita para cada Copyright IBM Corp. 2000, 2003 179

seriço de recuperação dinâmica da ADI, e os alores da ADI são retornados ao aaliador de regras de autorização. Exemplos de seriços de recuperação dinâmica da ADI fornecidos com o Tioli Access Manager são o Seriço de autorização sobre atributos de registro, que recupera alores da ADI a partir do registro de usuários, e o seriço de autorização AMWebARS, que recupera alores da ADI utilizando o seriço da Web AMWebARS. Ambos os seriços são discutidos com detalhes adicionais no documento Tioli Access Manager Authorization C Deeloper s Reference. Recuperando a ADI a partir do Pedido de um Cliente do Plug-in A ADI (informação sobre decisões de autorização) pode estar contida no cabeçalho do pedido, na cadeia de consulta do pedido e no corpo POST do pedido. É possíel criar regras de autorização que façam referência a essa ADI. Isso é feito com o uso de contêineres XML específicos do plug-in que fazem referência à ADI a ser adquirida. O parâmetro resource-manager-proided-adi na sub-rotina [aznapi-configuration] do arquio de configuração pdwebpi.conf especifica para o processo de aaliação de regras de autorização os prefixos que podem ser utilizados em nomes de contêiner especificados por regras de autorização. Para especificar ários prefixos, utilize diersas entradas do parâmetro resource-manager-proided-adi: Os nomes de contêiner a seguir apresentam prefixos que são apropriados para o plug-in: AMWS_hd_name Nome do contêiner do cabeçalho do pedido. O alor do cabeçalho HTTP denominado name no pedido HTTP é retornado ao aaliador de regras de autorização como uma ADI. AMWS_qs_name Nome do contêiner da cadeia de consulta do pedido. O alor de name no cadeia de consulta do pedido é retornado ao aaliador de regras de autorização como uma ADI. AMWS_pb_name Nome do contêiner do corpo POST do pedido. O alor de name no corpo POST do pedido é retornado ao aaliador de regras de autorização como uma ADI. Os prefixos podem ser específicos para cada gerenciador de recurso. Conseqüentemente, o gerenciador de recurso dee ser projetado de forma a responder adequadamente a um pedido para um ADI. São graadas regras de autorização que especificam a ADI necessária a partir de pedidos de clientes. Por exemplo, se o nome do host contido no cabeçalho HTTP for necessário como uma ADI, o prefixo AMWS_hd_ será utilizado no nome do contêiner XML especificado na regra. Esse prefixo específico do plug-in emite um alerta ao processo de aaliação de autorização informando que a ADI necessária está disponíel no pedido do cliente e que o plug-in sabe como localizar, extrair e retornar essa ADI. O nome do contêiner AMWS_hd_host é eniado ao plug-in. O plug-in responde ao nome do contêiner AMWS_hd_host procurando o cabeçalho host no pedido do cliente e extraindo o alor associado a esse cabeçalho. O plug-in retorna o alor do cabeçalho host (como um contêiner XML) ao processo de aaliação de regras de autorização. Esse processo de aaliação de regras de autorização utiliza o alor como a ADI na sua aaliação da regra. 180 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Exemplo: Recuperando uma ADI a partir do Cabeçalho do Pedido O exemplo de regra de autorização a seguir requer o nome do host da máquina do cliente. O pedido do cliente é configurado de forma a incluir o alor do nome do host no seu cabeçalho host. O uso do prefixo AMWS_hd_ na regra emite um alerta ao processo de aaliação de autorização informando que a ADI necessária está disponíel no pedido do cliente e que o plug-in sabe como localizar, extrair e retornar essa ADI. <xsl:if test= AMWS_hd_host = "machinea" >!TRUE!</xsl:if> O plug-in foi projetado para saber como tratar a extração de informações sobre ADI a partir do pedido: [aznapi-configuration] resource-manager-proided-adi = AMWS_hd_ O plug-in sabe que essas informações podem ser encontradas no nome do cabeçalho do pedido host. O plug-in extrai o alor contido no cabeçalho host e o retorna ao processo de aaliação de autorização. O exemplo de regra de autorização será aaliado como true se o alor fornecido no cabeçalho host do pedido for machinea. De maneira semelhante, as informações necessárias para aaliar uma regra de autorização podem ser proenientes do corpo POST do pedido ou da cadeia de consulta do pedido. Exemplo: Recuperando uma ADI a partir da Cadeia de Consulta do Pedido O exemplo de regra de autorização a seguir requer o nome do CEP do cliente transmitido na cadeia de consulta de um pedido GET (submetido em resposta a um formulário). O pedido do cliente é configurado de forma a incluir o alor do CEP no campo zip da cadeia de consulta do pedido. https://www.serice.com/location?zip=99999 O uso do prefixo AMWS_qs_ na regra emite um alerta ao processo de aaliação de autorização informando que a ADI necessária está disponíel no pedido do cliente e que o plug-in sabe como localizar, extrair e retornar essa ADI. <xsl:if test= AMWS_qs_zip = "99999" >!TRUE!</xsl:if> O plug-in foi projetado para saber como tratar a extração de informações sobre ADI a partir do pedido: [aznapi-configuration] resource-manager-proided-adi = AMWS_qs_ O plug-in sabe que essas informações podem ser encontradas na cadeia de consulta do pedido, no nome de campo zip. O plug-in extrai o alor contido no campo zip e o retorna ao processo de aaliação de autorização. O exemplo de regra de autorização será aaliado como true se o alor fornecido no campo zip da cadeia de consulta do pedido for 99999. De maneira semelhante, as informações necessárias para aaliar uma regra de autorização podem ser proenientes do corpo POST do pedido ou do cabeçalho do pedido. Capítulo 8. Recuperação de Informações sobre Decisões de Autorização 181

Exemplo: Recuperando uma ADI a partir do Corpo POST do Pedido O exemplo de regra de autorização a seguir requer o nome do alor total da compra do cliente a partir de um carrinho de compras da Web que foi transmitido no corpo de um pedido POST (submetido em resposta a um formulário). O pedido do cliente é configurado de forma a incluir o alor total da compra no campo purchase-total do corpo POST do pedido. O uso do prefixo AMWS_pb_ na regra emite um alerta ao processo de aaliação de autorização informando que a ADI necessária está disponíel no pedido do cliente e que o plug-in sabe como localizar, extrair e retornar essa ADI. <xsl:if test= AMWS_pb_purchase-total < "1000.00" >!TRUE!</xsl:if> O plug-in foi projetado para saber como tratar a extração de informações sobre ADI a partir do pedido: [aznapi-configuration] resource-manager-proided-adi = AMWS_pb_ O plug-in sabe que essas informações podem ser encontradas no corpo POST do pedido, no nome de campo purchase-total. O plug-in extrai o alor contido no campo purchase-total e o retorna ao processo de aaliação de autorização. O exemplo de regra de autorização será aaliado como true se o alor fornecido no campo purchase-total do corpo POST do pedido for menor que 1000.00. De maneira semelhante, as informações necessárias para aaliar uma regra de autorização podem ser proenientes do cabeçalho do pedido ou da cadeia de consulta do pedido. Recuperando uma ADI a partir da Credencial do Usuário Regras de autorização podem ser graadas para utilizar a ADI que é fornecida inicialmente ao aaliador de regras de autorização como parte da credencial. A chamada inicial para o seriço de autorização (azn_decision_access_allowed_ext()) contém realmente as informações de credencial do usuário. O aaliador de regras de autorização sempre examina essas informações de credencial para erificar a existência da ADI necessária para a regra que está sendo processada. A regra de autorização pode utilizar o alor de qualquer campo na credencial, incluindo os atributos estendidos adicionados à credencial durante a autenticação. A técnica para criar atributos estendidos na credencial do usuário é explicada em Adicionando Atributos Estendidos para Credenciais na página 107. Fornecendo um Motio de Falha Regras de autorização permitem configurar condições especiais, e muitas ezes complexas, que determinam a capacidade de acessar um recurso protegido. Entretanto, o resultado padrão de uma decisão de autorização com falhas é parar o progresso do pedido para o aplicatio de seriços que controla o recurso e apresentar ao cliente um mensagem de proibição ( forbidden ). Se a regra de autorização for graada de forma a incluir um motio de falha, e se for aaliada como FALSE pelo aaliador de regras de autorização do Tioli Access Manager, o plug-in receberá o motio de falha da regra junto com uma mensagem de proibição ( forbidden ) a partir do seriço de autorização. O motio da falha é geralmente ignorado e a decisão de proibição é imposta. 182 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Como opção, é possíel configurar o plug-in de forma a rejeitar essa resposta padrão e permitir que pedidos negados prossigam até um aplicatio de seriços backend. O pedido é acompanhado pelo motio da falha fornecido na regra de autorização. Dessa maneira, o aplicatio de seriços backend tem a oportunidade de prosseguir com sua própria resposta a essa situação. Essa configuração opcional é especificada com o uso do parâmetro pass-on-rule-failure-reason na sub-rotina [boolean-rules] do arquio pdwebpi.conf. Regras de autorização são normalmente utilizadas em conjunto com aplicatios de seriços que podem entender e tratar esse níel mais sofisticado de controle de acesso. Em alguns casos, o aplicatio de seriços dee receber um pedido negado pelo seriço de autorização do Tioli Access Manager. Esse aplicatio é graado de forma a entender as informações sobre o motio da falha e pode fornecer sua própria resposta a um pedido reproado por uma regra de autorização do Tioli Access Manager. Por exemplo, o componente de processamento de ordens de um aplicatio de carrinho de compras pode ser controlado por uma regra de autorização que negará a ação em uma ordem se o preço total da compra exceder o limite de crédito do usuário. É importante que o aplicatio de carrinho de compras receba todo o pedido e o motio da falha. Agora, esse aplicatio pode assumir totalmente os problemas e fornecer uma resposta de fácil compreensão para o usuário, como aconselhá-lo a eliminar uma parte da ordem. A interação com o usuário é preserada em ez de ser eliminada. Sempre utilize essa opção com cautela. É importante coordenar o uso de motios de falha em regras de autorização com a capacidade de um aplicatio de seriços no sentido de interpretar e responder a essas informações. Você não deseja criar acidentalmente uma situação na qual o acesso é concedido a um recurso controlado por um aplicatio que não consegue responder precisamente ao cabeçalho AM_AZN_FAILURE. Configurando a Recuperação Dinâmica da ADI É possíel graar regras que exijam uma ADI (informação sobre decisões de autorização) cuja localização não consiga ser determinada em nenhuma das informações às quais o seriço de autorização do Tioli Access Manager possui acesso. Nesses casos, é necessário recuperar a ADI a partir de uma origem externa. Essa recuperação pode ser executada em tempo real por um seriço de autorização de recuperação dinâmica da ADI. O seriço da Web AMWebARS, atualmente fornecido com o WebSEAL Attribute Retrieal Serice, é um tipo de seriço de autorização de recuperação. O ARS (Attribute Retrieal Serice) fornece seriços de comunicação e conersão de formatos entre a biblioteca de seriços de autorização do plug-in e um proedor externo de ADI. O diagrama a seguir ilustra o fluxo do processo para o seriço da Web AMWEBARS: Capítulo 8. Recuperação de Informações sobre Decisões de Autorização 183

Figura 11. Fluxo de processo do ARS.. Fluxo de processo: 1. O cliente faz um pedido para um recurso protegido por uma regra de autorização. 2. A aaliador de regras de autorização parte do seriço de autorização determina se uma ADI específica é necessária para concluir a aaliação da regra. A ADI solicitada não está disponíel a partir da credencial do usuário, do seriço de autorização ou do plug-in. 3. A tarefa da recuperação da ADI é eniada ao seriço da Web AMWebARS por meio da biblioteca de seriços de autorização. Esse seriço formata o pedido para a ADI como um pedido SOAP. O pedido SOAP é eniado ia HTTP à interface WSDL (Web Serice Description Language) do seriço da Web AMWebARS. 4. O seriço da Web AMWebARS formata o pedido apropriadamente para o seriço de perfil externo que dee fornecer a ADI. 5. O seriço de perfil externo retorna a ADI apropriada. 6. A ADI é formatada em outro contêiner SOAP e retornada ao seriço de autorização do plug-in. Nesse ponto, o aaliador de regras de autorização possui as informações necessárias para aaliar a regra e tomar uma decisão no sentido de aceitar ou negar o pedido original do cliente. Para obter informações sobre como implementar o ARS, consulte o documento Tioli Access Manager WebSEAL: Guia do Administrador. Configurando o Plug-in para Utilizar o Seriço da Web AMWebARS Execute as tarefas a seguir de forma a configurar o plug-in para utilizar o seriço da Web AMWebARS: 1. No arquio de configuração pdwebpi.conf, especifique o nome de identificação (ID) do seriço de autorização de recuperação dinâmica da ADI que é consultado quando uma ADI ausente é detectada durante a aaliação de uma regra. Nesse caso, o seriço da Web AMWebARS é especificado: 184 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

[aznapi-configuration] dynamic-adi-entitlements-serices = AMWebARS 2. No arquio de configuração pdwebpi.conf, utilize o ID do seriço de autorização de recuperação dinâmica da ADI como um parâmetro de forma a especificar a biblioteca interna apropriada que formata pedidos de ADI externos e que interpreta respostas de entrada. Por exemplo: [aznapi-entitlement-serices] dynadi = azn_ent_amwebars 3. No arquio de configuração pdwebpi.conf, especifique o URL para o seriço da Web dynadi localizado no ambiente WebSphere (inserido como uma linha): [amwebars] serice-url = http://websphere_hostname:websphere_port \ /dynadi/dynadi/sericetoisericeportadapter 4. Inicie noamente o plug-in. Capítulo 8. Recuperação de Informações sobre Decisões de Autorização 185

186 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Apêndice A. Utilizando pdbackup para Fazer Backup dos Dados do Plug-in Funcionalidade O utilitário pdbackup permite fazer o backup e a restauração dos dados do Tioli Access Manager. O utilitário pdbackup usa, como um argumento, um arquio de lista de backups que especifica os arquios e os diretórios que requerem backup. Cada componente principal do Tioli Access Manager (como o Base, o WebSEAL e o Plug-in) possui o seu próprio arquio de lista. O arquio pdinfo-pdwebpi.lst especifica os arquios e os diretórios do plug-in que são copiados para backup pelo utilitário pdbackup. Este apêndice descree como usar o utilitário pdbackup para fazer o backup e a restauração dos dados do plug-in. A referência completa para o utilitário pdbackup está localizada no documento IBM Tioli Access Manager: Referência de Comandos. Fazendo Backup dos Dados do Plug-in O utilitário pdbackup faz o backup da lista de arquios e de diretórios contidos no arquio de lista de backups do plug-in, pdinfo-pdwebpi.lst. UNIX: Por padrão, pdinfo-pdwebpi.lst está localizado em /opt/pdwebpi/etc/. Por padrão, o archie de backup resultante é armazenado como um único arquio.tar em /ar/policydirector/pdbackup. O nome do arquio.tar padrão é construído com o uso do nome do arquio de lista de backups, incluindo uma data e uma hora: list-file-name_ddmmyyy.hh_mm.tar Por exemplo: pdinfo-pdwebpi.lst_30jul2003.10_39.tar Como alternatia, é possíel especificar: Um nome de arquio personalizado para o arquio.tar (utilize a opção file) Esse nome de arquio personalizado não contém uma data e uma hora. Uma localização de diretório personalizada para o arquio.tar (utilize a opção path) O conteúdo do arquio.tar é extraído nos seguintes diretórios: opt/ ar/ tmp/ Windows: Por padrão, o arquio pdinfo-pdwebpi.lst está localizado em C:\Arquios de programas\tioli\pdwebpi\etc\ Por padrão, o archie de backup resultante é armazenado como uma única árore de diretórios no diretório C:\Arquios de programas\tioli\pdwebpi\pdbackup\. Copyright IBM Corp. 2000, 2003 187

O nome do diretório.dar padrão é construído a partir do nome do arquio de lista de backups, incluindo uma data e uma hora: list-file-name_ddmmmyyyy.hh_mm.dar Por exemplo: pdinfo-pdwebpi.lst_30jul2003.10_39.dar O conteúdo do arquio.dar é extraído em um subdiretório e em um arquio: %C% Registry O diretório %C% contém a árore completa de backups. O nome desse diretório é determinado pela designação de letra da unidade na qual os arquios e os diretórios do plug-in estão localizados. O arquio de registro armazena as chaes de registro (extensões.reg). Como alternatia, é possíel especificar: Um nome de arquio personalizado para o archie de diretório.dar (utilize a opção file) Esse nome de arquio personalizado não contém uma data e uma hora. Uma localização de diretório personalizada para o archie de diretório.dar (utilize a opção path) Restaurando Dados do Plug-in UNIX: Os diretórios e os arquios em archie são restaurados a partir do arquio.tar para o diretório /opt/pdwebpi. Windows: Os arquios em archie são restaurados para suas localizações originais de diretório de instalação. Sintaxe Uma referência completa para utilitário pdbackup pode ser encontrada no documento IBM Tioli Access Manager: Referência de Comandos. pdbackup a backup l backup-list-pathname \ [ path custom-pathname][ file archie-pathname] [ usage] [?] pdbackup a restore file archie-pathname \ [ path custom-pathname] [ usage] [?] Opção Descrição a [backup restore extract] Especifica a operação de backup, restauração ou extração. l backup-list-pathname Especifica o caminho completo para o arquio de lista de backups (pdinfo-pdwebpi.lst). path custom-pathname Utilizada para backup, especifica uma localização personalizada de diretório de archie. 188 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

file archie-pathname Utilizada para backup, especifica um nome personalizado para o arquio archie. Utilizada para restauração, especifica o caminho completo para o arquio archie que dee ser restaurado. É possíel utilizar ersões resumidas dos nomes de opções de comando, mas a abreiação não dee ser ambígua. Por exemplo, ocê pode digitar a para action. Entretanto, os alores dos argumentos para essas opções não podem ser abreiados. Exemplos Exemplos para UNIX 1. O exemplo a seguir executa um backup padrão com alores padrão: pdbackup -a backup -l /opt/pdwebpi/etc/pdinfo-pdwebpi.lst Isso resulta em um arquio denominado pdinfo-pdwebpi.lst_date.time.tar que é armazenado no diretório /ar/policydirector/pdbackup. 2. O exemplo a seguir executa um backup e armazena o arquio archie padrão no diretório /ar/backup: pdbackup -a backup -l /opt/pdwebpi/etc/pdinfo-pdwebpi.lst -path /ar/backup Isso resulta em um arquio denominado pdinfo-pdwebpi.lst_date.time.tar, localizado no diretório /ar/pdbackup. 3. O exemplo a seguir executa um backup e cria um arquio archie denominado amwebarchie.tar: pdbackup -a backup -l /opt/pdwebpi/etc/pdinfo-pdwebpi.lst -file amwebarchie A extensão do archie padrão (.tar) é anexada ao nome do arquio amwebarchie personalizado. Esse arquio é armazenado no diretório padrão /ar/policydirector/pdbackup. 4. O exemplo a seguir restaura o arquio archie a partir da localização de diretório padrão: pdbackup -a restore -file pdinfo-pdwebpi.lst_29aug2003.07_24.tar 5. O exemplo a seguir restaura o arquio archie a partir do diretório /ar/pdback: pdbackup -a restore -file /ar/pdback/pdinfo-pdwebpi.lst_29aug2003.07_25.tar Exemplos para Windows 1. O exemplo a seguir executa um backup padrão com alores padrão: pdbackup -a backup -l install_path\etc\pdinfo-pdwebpi.lst Isso resulta em um arquio denominado pdinfo-pdwebpi.lst_date.time.dar, localizado no diretório install_path\pdbackup do plug-in. 2. O exemplo a seguir executa um backup utilizando o nome do arquio archie padrão e armazena esse arquio no diretório C:\pdback: pdbackup -a backup -l install_path\etc\pdinfo-pdwebpi.lst -path c:\pdback 3. O exemplo a seguir executa um backup e cria um arquio denominado pdarchie.dar: Apêndice A. Utilizando pdbackup para Fazer Backup dos Dados do Plug-in 189

pdbackup -a backup -l install_path\etc\pdinfo-pdwebpi.lst -file pdarchie A extensão do archie padrão (.dar) é aplicada ao nome do arquio pdarchie personalizado. O arquio é armazenado no diretório padrão install_path\pdbackup. 4. O exemplo a seguir executa um backup para o diretório \pdback na unidade F: pdbackup -a backup -l pdinfo-pdwebpi.lst -path f:\pdback 5. O exemplo a seguir restaura o arquio archie a partir do diretório padrão (único diretório mostrado em duas linhas): pdbackup -a restore -file install_path\pdbackup \pdinfo-pdwebpi.lst_29jun2003.07_24.dar 6. O exemplo a seguir restaura arquios a partir do diretório H:\pdbackup: pdbackup -a restore -file h:\pdbackup\pdinfo-pdwebpi.lst_29jun2003.07_25.dar Conteúdo de pdinfo-pdwebpi.lst [UNIX FILES] # fully qualified file names./opt/pdwebpi/etc./ar/pdwebpi/audit./ar/pdwebpi/db./ar/pdwebpi/keytab./ar/pdwebpi/log [UNIX CONF FILES] # configuration files that specify a file to include # file:stanza:option /opt/pdwebpi/etc/pdwebpi.conf:uraf-ad:ad-serer-config /opt/pdwebpi/etc/pdwebpi.conf:uraf-domino:domino-serer-config /opt/pdwebpi/etc/pdwebpi.conf:ldap:ldap-serer-config /opt/pdwebpi/etc/pdwebpi.conf:ldap:ssl-keyfile /opt/pdwebpi/etc/pdwebpi.conf:ldap:ssl-keyfile-stash /opt/pdwebpi/etc/pdwebpi.conf:failoer:failoer-cookies-keyfile /opt/pdwebpi/etc/pdwebpi.conf:ltpa:ltpa-keyfile /opt/pdwebpi/etc/pdwebpi.conf:ltpa:ltpa-stash-file /opt/pdwebpi/etc/pdwebpi.conf:iis:query-log-file /opt/pdwebpi/etc/pdwebpi.conf:iis:log-file /opt/pdwebpi/etc/pdwebpi.conf:iplanet:query-log-file [WINDOWS FILES] BASEDIR=SOFTWARE\Tioli\Access Manager Plug-in for Web Serers:Path <BASEDIR>etc <BASEDIR>log <BASEDIR>audit <BASEDIR>db <BASEDIR>keytab [WINDOWS CONF FILES] # configuration files that specify a file to include # file:stanza:option <BASEDIR>etc/pdwebpi.conf:uraf-ad:ad-serer-config <BASEDIR>etc/pdwebpi.conf:uraf-domino:domino-serer-config <BASEDIR>etc/pdwebpi.conf:ldap:ldap-serer-config <BASEDIR>etc/pdwebpi.conf:ldap:ssl-keyfile <BASEDIR>etc/pdwebpi.conf:ldap:ssl-keyfile-stash <BASEDIR>etc/pdwebpi.conf:failoer:failoer-cookies-keyfile <BASEDIR>etc/pdwebpi.conf:ltpa:ltpa-keyfile <BASEDIR>etc/pdwebpi.conf:ltpa:ltpa-stash-file <BASEDIR>etc/pdwebpi.conf:iis:query-log-file <BASEDIR>etc/pdwebpi.conf:iis:log-file <BASEDIR>etc/pdwebpi.conf:iplanet:query-log-file 190 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

[WINDOWS REGISTRY] # especificar chaes para backup SOFTWARE\Tioli Dados de Backup Adicionais As sub-rotinas e os parâmetros a seguir não estão listados no arquio pdinfo-pdwebpi.lst e, portanto, não são automaticamente copiados para backup. Se for necessário fazer o backup desses dados, ocê deerá editar o arquio pdinfo-pdwebpi.lst e adicionar essas informações. Siga o formato descrito no início do arquio pdinfo-pdwebpi.lst. [cdsso-domain-keys] <domain name> = <key file> [ecsso-domain-keys] <domain name> = <key file> Apêndice A. Utilizando pdbackup para Fazer Backup dos Dados do Plug-in 191

192 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Apêndice B. Referência de pdwebpi.conf O Tioli Access Manager Plug-in para Web Serers é configurado com o uso dos parâmetros localizados no arquio de configuração pdwebpi.conf. Esse arquio está localizado no seguinte diretório: UNIX: Windows: install_path/etc/ install_path\etc\ As seções a seguir fornecem descrições para cada um dos parâmetros configuráeis contidos no arquio de configuração pdwebpi.conf. Esses parâmetros estão agrupados nas tabelas a seguir, dependendo do seu uso: Geral, Autenticação, Sessões, LDAP, Proxy, API de Autorização, Específico para um Seridor Web. Parâmetros de Configuração Gerais Tabela 26. Parâmetros de Configuração Gerais [pdweb-plugins] Parâmetro Geral Descrição Define os hosts irtuais que serão protegidos pelo Tioli Access Manager Plug-in para Web Serers, bem como outros parâmetros de configuração padrão ou globais. irtual-host web-serer Identificação de sub-rotinas subordinadas que contêm informações de configuração sobre hosts irtuais específicos. Identifica o tipo de seridor Web em uso. Os alores aceitáeis são: iis para o Microsoft Internet Information Serices ihs para o IBM HTTP Serer iplanet para o Sun ONE (anteriormente iplanet) Web Serer apache para o Apache Esse parâmetro é automaticamente definido durante a instalação. Copyright IBM Corp. 2000, 2003 193

Tabela 26. Parâmetros de Configuração Gerais (continuação) Parâmetro windows-file-system Geral Descrição Indica ao Authorization Serer que deem ser tomadas precauções para eitar problemas de segurança relacionados aos URIs que representam recursos do sistema de arquios do Windows. Definido como true, qualquer acesso a um URI com elementos de caminho, como os nomes de caminho abreiados do Windows 2000, é proibido. Especificamente, os elementos de caminho que terminam com ~digit são rejeitados. Em sistemas Windows, esse parâmetro é definido como true por padrão. Em sistemas UNIX, ele é definido como false. case-sensitie Esse parâmetro poderá ser substituído para cada host irtual se for especificado na sub-rotina [irtual_host] apropriada. Informa ao Authorization Serer como tratar a formatação de maiúsculas e minúsculas dos URIs. Definido como false, os URIs são conertidos em minúsculas durante a construção do nome do objeto correspondente do Tioli Access Manager com base no qual uma decisão de autorização é tomada. Em sistemas UNIX, esse parâmetro é definido como true. Em sistemas Windows, ele é definido como false. Quando o parâmetro windows-file-system é definido como true e case-sensitie não está definido, os URIs são conertidos em minúsculas por padrão. Obsere que a parte /PDWebPI/branch do nome do objeto não é conertida. log-file logs log-entries Esse parâmetro poderá ser substituído para cada host irtual se for especificado na sub-rotina [irtual_host] apropriada. Identifica o nome do arquio e caminho do arquio de log no qual todas as tarefas do Authorization Serer são capturadas. Pode ser especificado como um nome de caminho absoluto ou relatio. Especifica o número de arquios de log a serem criados antes de reutilizar o primeiro arquio de log. Especifica o número de entradas de log a serem graadas antes da transferência para um noo arquio de log. 194 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 26. Parâmetros de Configuração Gerais (continuação) Parâmetro mpa-enabled Geral Descrição MPAs (Agentes Proxy de Multiplexação) são gateways que acomodam o acesso de ários clientes. É estabelecido um único canal autenticado para o seridor de origem, e todas as comunicações de pedido e resposta dos clientes são eniadas por meio desse canal. Definido como true, a capacidade do MPA é atiada. mpa-protected-object user group pre-410-compatible-tokens use-accept-language-header use-accept-charset-header max-cached-http-body send-p3p-header tag-alue-prefix Definido como false, a capacidade do MPA é desatiada. Esse parâmetro poderá ser substituído para cada host irtual se for definido na sub-rotina [irtual_host]. Define o objeto MPA com base no qual a decisão de autorização é tomada. Esse parâmetro poderá ser substituído para cada host irtual se for definido na sub-rotina [irtual_host]. Em sistemas UNIX, esse parâmetro contém o nome do usuário, o gerenciador e o proxy como os quais os processos deem ser executados. Em sistemas UNIX, esse parâmetro contém o nome do grupo, o gerenciador e o proxy como os quais os processos deem ser executados. Atia ou desatia a compatibilidade entre os aprimoramentos de token no Tioli Access Manager ersão 4.1 e no Tioli Access Manager ersão 3.9. Definido como true, a segurança de tokens para a geração de cookies de conexão única e de failoer para o e-community interoperará com o esquema de codificação de tokens do Tioli Access Manager 3.9. Esse parâmetro abrange todos os processos e não pode ser especificado para cada host irtual. Atia ou desatia o uso do cabeçalho HTTP accept-language durante a tentatia de localizar o idioma para a resposta HTML gerada. Atia ou desatia o uso do cabeçalho HTTP accept-charset durante a tentatia de localizar o conjunto de caracteres no qual decodificar elementos de um pedido HTTP ou de gerar uma resposta HTML. Especifica a quantidade máxima de dados do corpo HTTP que serão armazenados em cache para qualquer pedido determinado. Se a quantidade de dados do corpo exceder o máximo configurado, todos esses dados serão descartados. Controla se o Tioli Access Manager Plug-in para Web Serers adicionará ou não um cabeçalho P3P contendo uma instrução de critério compacto a qualquer resposta HTTP na qual ele tenha definido cookies. Especifica o prefixo opcional adicionado a nomes de atributos de credencial utilizados para cabeçalhos HTTP tag/alue. Apêndice B. Referência de pdwebpi.conf 195

Tabela 26. Parâmetros de Configuração Gerais (continuação) Parâmetro use-uri-encoded-session-id [module-mgr] remoe-headers Geral Contém detalhes para o gerenciador de módulos proxy. [wpiconfig] path erify-step-up-user Descrição Controla se o ID da sessão especificado na tarefa de administração terminate session dee ou não ser codificado em um URI. Especifica se todos os cabeçalhos que possam ser definidos pelo módulo tag-alue deem ou não ser remoidos do pedido antes do processamento de tag-alue. A remoção desses cabeçalhos assegura que eles não poderão ser inseridos por um agente de usuário mal intencionado para falsificar os alores deriados da credencial. AVISO! A DESATIVAÇÃO DA CAPACIDADE DE REMOÇÃO DE CABEÇALHOS PODERÁ INTRODUZIR UMA VULNERABILIDADE DE SEGURANÇA EM UM SITE DA WEB. OS APLICATIVOS DEPENDENTES DOS CABEÇALHOS TAG-VALUE QUE NÃO FOREM REMOVIDOS DO PEDIDO ANTES DO PROCESSAMENTO DE TAG-VALUE DEVERÃO SER NOVAMENTE IMPLEMENTADOS PARA EVITAR A POSSIBILIDADE DE QUE OS CABEÇALHOS HTTP TAG-VALUE SEJAM FALSIFICADOS POR AGENTES DE USUÁRIO MAL-INTENCIONADOS. O caminho que contém os arquios da biblioteca compartilhada de módulos. Como o plug-in pesquisará todas as entradas, é permitida mais de uma entrada de caminho. Determina, no caso de uma operação progressia, se o noo ID do usuário dee ou não corresponder a qualquer ID de usuário preexistente. Contém informações que são definidas pelo programa de configuração de forma a auxiliar na desconfiguração. [user-agent] serer-type install-dir hosts Definido durante a configuração de forma a auxiliar na desconfiguração. Definido durante a configuração de forma a auxiliar na desconfiguração. Definido durante a configuração de forma a auxiliar na desconfiguração. Cria mapeamentos entre agentes de usuário, conforme definido pelo cabeçalho HTTP user-agent, e um locale específico. O formato é: user-agent-pattern = locale string 196 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Parâmetros de Configuração de Autenticação Tabela 27. Parâmetros de Configuração de Autenticação [modules] Parâmetro Autenticação Descrição Declara os métodos de autenticação disponíeis e a biblioteca associada. O formato é: module_name = shared_library_name acctmgmt BA cert failoer forms fsso ip-addr i-headers session-cookie ssl-id tag-alue http-hdr token ltpa ecsso cdsso login-redirect ntlm spnego web-log boolean rules switch-user dynurl cred-refresh ext-auth-int [common-modules] Gerenciamento de Contas Autenticação Básica Certificado Failoer Formulários Conexão única por formulários Endereço IP Cabeçalhos IV Cookie de Sessão ID do SSL Valor de marcação Cabeçalho HTTP Token Cookie LTPA Conexão única do e-community Conexão única entre domínios Redirecionamento de Login NTLM Security Proider Negotiation Log da Web Regras booleanas Comutação de Usuários URL Dinâmico Atualização de credenciais Interface de autenticação externa Contém a configuração do módulo [common]. A sub-rotina consiste no formato: module-type = module-name. Os módulos de suporte incluem: Authentication Session Pre-authzn Especifica os métodos a serem utilizados para a autenticação de usuários. Especifica os métodos a serem utilizados para a manutenção do estado de sessões. Especifica os métodos a serem utilizados para qualquer processamento necessário anterior à autorização do usuário. Apêndice B. Referência de pdwebpi.conf 197

Tabela 27. Parâmetros de Configuração de Autenticação (continuação) Parâmetro Post-authzn Response [authentication-leels] Autenticação Descrição Especifica os métodos a serem utilizados para o processamento pós-autorização. Especifica os métodos a serem utilizados para qualquer processamento em respostas a partir do seridor Web. A sub-rotina [authentication-leels] define níeis de autenticação progressia, bem como a ordem dos métodos de autenticação definidos na sub-rotina [modules]. O formato é: leel = module_name Um método de autenticação assume como padrão um níel igual a 1 quando não existe nenhuma entrada definida para esse método. A ordem de autenticação é determinada como o níel de autenticação mais alto até o níel de autenticação mais baixo para os métodos de autenticação definidos. Se um níel de autenticação for compartilhado por ários métodos de autenticação, a sub-ordem será determinada pela ordem na qual os módulos aparecem na sub-rotina [modules]. [authentication-mechanisms] [sessions] passwd-cdas passwd-ldap passwd-uraf token-cdas cert-ssl cert-cdas http-request sso-create sso-consume passwd-strength cred-ext-attrs kerberos5 ext-auth-interface failoer-password cdsso su-password su-token-card su-certificate su-http-request su-cdsso Lista de mecanismos de autenticação adicionais suportados e de bibliotecas compartilhadas associadas que estão inculados ao subsistema de autenticação do Tioli Access Manager. Declara os alores padrão que são comuns a todos os módulos de sessão. max-entries timeout inactie-timeout resend-pdwebpi-cookies reauth-lifetime-reset Define o número máximo de sessões que podem ser armazenadas em uma única instância de um módulo de sessão. Define a duração máxima de uma sessão em segundos. Define a duração necessária do tempo inatio, em segundos, para uma sessão antes que ela atinja o tempo limite. Define se cookies de Plug-In da Web deem ou não eniados com cada pedido. Se for yes, o cronômetro de duração de credenciais será zerado depois que uma noa autenticação for concluída com êxito. 198 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 27. Parâmetros de Configuração de Autenticação (continuação) [performance] Parâmetro reauth-grace-period Autenticação Descrição Especifica o tempo, em segundos, que o cliente possui como período de tolerância durante o qual deerá executar com êxito uma noa autenticação se a credencial tier expirado de alguma maneira. Contém árias opções de configuração que podem ajudar a ajustar o desempenho do sistema. enable-pop add-session-id-to-cred [user-agent] Controla se os POPs são impostos ou não. Controla se o ID da sessão será adicionado ou não à credencial da sessão. Utilizado para criar mapeamentos entre agentes de usuário, conforme definido pelo cabeçalho HTTP user-agent, e um locale específico. Está em conformidade com o formato: user-agent-pattern = locale-string. [BA] [failoer] basic-auth-realm strip-hdr add-hdr gso-resource-name supply-password supply-username Declara a região que aparecerá no diálogo apresentado ao usuário durante o logon de autenticação básica. DEVE estar delimitado por aspas duplas. Controla a remoção do cabeçalho BA em pedidos. As opções álidas são: ignore - Não realizar nenhuma ação com o cabeçalho BA. always - Remoer o cabeçalho BA do pedido. unauth - Remoer o cabeçalho BA do pedido se esse cabeçalho não tier sido autenticado. Controla a adição de um noo cabeçalho BA a um pedido. As opções álidas para essa entrada são: none - Não adicionar um noo cabeçalho BA ao pedido (padrão). gso - Adicionar um cabeçalho GSO BA ao pedido. supply - Fornecer uma senha ou um nome de usuário estático, ou ambos, no cabeçalho BA. Contém o nome do recurso GSO utilizado para criar cabeçalhos GSO BA. A especificação de um alor é opcional quando add-hdr está definido como gso. Quando add-hdr está definido como gso e gso-resource-name não está definido, o nome do host irtual que faz o tratamento do pedido é utilizado. Um alor será necessário se add-hdr estier definido como supply. Quando definido, o parâmetro especifica a senha estática utilizada no cabeçalho BA criado. Contém o nome de usuário estática utilizado no cabeçalho BA criado. A definição desse parâmetro é opcional quando o parâmetro add-hdr está definido como supply. Quando o parâmetro supply está definido e supply-username não foi definido (ou seja, permanece marcado como comentário), o nome do usuário autenticado é utilizado no cabeçalho BA criado. Apêndice B. Referência de pdwebpi.conf 199

Tabela 27. Parâmetros de Configuração de Autenticação (continuação) Parâmetro Autenticação Descrição Contém todos os detalhes de configuração para os módulos de pós-autorização e de autenticação com base em cookies de failoer. failoer-cookies-keyfile failoer-cookies-lifetime failoer-update-cookie enable-failoer-cookie-fordomain failoer-require-lifetimetimestamp-alidation failoer-require-actiitytimestamp-alidation use-utf8 [failoer-add-attributes] [failoer-restore-attributes] [ltpa] Declara o caminho para o arquio de chaes utilizado para criptografar e decriptografar dados de credenciais no cookie de failoer. A duração álida de um cookie de failoer, em minutos. Atia/desatia o cookie de failoer na extensão do domínio inteiro. Define com que freqüência a data e a hora da atiidade do cookie de failoer são atualizadas. Se for definido como 0, o cookie de failoer será atualizado a cada pedido. Se for definido como um número inteiro positio, o cookie de failoer será atualizado depois que esse tempo, em segundos, tier decorrido. Se for definido como um número inteiro negatio, o cookie de failoer apenas será atualizado quando a autenticação ocorrer ou quando a credencial for atualizada. Essas entradas determinam se a alidação de hora e hora é necessária para o êxito da autenticação com base em failoer. As definições são: true: false: A data e a hora são necessárias. Se estierem ausentes ou forem inálidas, a autenticação com base em failoer falhará. A data e a hora não são necessárias; mas, se existirem e forem inálidas, a autenticação com base em failoer falhará. Se os plug-ins da Web precisarem aceitar cookies de failoer gerados por uma ersão anterior do AMWebPI ou do AMWebSEAL, essa opção deerá ser utilizada para ambos os itens. Define qual conjunto de caracteres dee ser utilizado para codificar o cookie de failoer. Contém a configuração dos atributos que deem ser adicionados a um cookie de failoer a partir da credencial original. Contém a configuração dos atributos que deem ser recuperados para a credencial a partir do cookie de failoer quando um usuário é autenticado com um cookie de failoer. Contém todos os detalhes do módulo de pós-autorização com base em cookies LTPA. Esse módulo foi desenolido para possibilitar a capacidade de conexão única com um WebSphere Serer. ltpa-keyfile ltpa-stash-file ltpa-password ltpa-lifetime Nome do caminho completo do arquio de chaes LTPA. Localização do arquio stash de senha. A senha a ser utilizada no lugar o arquio stash. A duração, em segundos, do cookie LTPA. 200 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 27. Parâmetros de Configuração de Autenticação (continuação) [forms] Parâmetro Autenticação Descrição Contém todos os detalhes do módulo de login com base em formulários. [fsso] login-form login-uri create-ba-hdr use-utf8 O nome do arquio do formulário de logon. O URI para o qual o formulário de login submete os detalhes de login. Os detalhes de login deem ser submetidos para esse URI com o nome do usuário especificado no atributo de dados POST username e com a senha do usuário especificada no atributo de dados POST password. Valor booleano para indicar se o nome do usuário e a senha fornecidos deem ou não ser fornecidos em um cabeçalho BA ao aplicatio de destino. Indica se o cabeçalho BA, caso tenha sido criado, dee ou não ser codificado com o uso do UTF-8 ou do conjunto de códigos local. O alor padrão é true. Lista os formulários de login a serem interceptados pelo módulo de Conexão Única por Formulários. login-page-stanza [login-form-1] Registra o nome de uma ou mais sub-rotinas que contêm os detalhes de cada formulário de login a ser interceptado. Formulários de login são identificados por um processo de correspondência de padrões de 2 estágios. O FSSO intercepta todas as páginas que correspondem à expressão comum login-page. Os formulários de login nessas páginas são localizados por meio da correspondência entre o atributo action de elementos de formulário HTML e a expressão comum login-form-action. login-page login-form-action argument-stanza [auth-data] Essa entrada de configuração está localizada na sub-rotina especificada pelo parâmetro login-page-stanza. Ela especifica um padrão, com o uso de uma expressão comum, que identifica exclusiamente os pedidos para a página de login de um aplicatio ao utilizar a funcionalidade de conexão única por formulários do plug-in. O padrão configurado é comparado com base no URI do pedido. Esse parâmetro está localizado na sub-rotina especificada pelo parâmetro login-page-stanza. Ele especifica um padrão, com o uso de uma expressão comum, que identifica exclusiamente qual formulário contido na página interceptada corresponde ao formulário de login do aplicatio ao utilizar a funcionalidade de conexão única por formulários do plug-in. Se ários formulários corresponderem ao padrão, o primeiro deles será utilizado. Esse parâmetro está localizado na sub-rotina especificada pelo parâmetro login-page-stanza. Ele aponta para outra sub-rotina personalizada que lista os campos e os dados necessários para o preenchimento do formulário de login. Apêndice B. Referência de pdwebpi.conf 201

Tabela 27. Parâmetros de Configuração de Autenticação (continuação) Parâmetro Autenticação Descrição Contém uma ou mais entradas do formulário: name = method:alue. Esse parâmetro está localizado na sub-rotina especificada pelo parâmetro argument-stanza. name corresponde ao atributo name de um elemento de entrada no formulário de login. method pode ser cred, gso ou string. alue contém uma cadeia interpretada de acordo com o alor do método. [web-log] Contém todos os detalhes do módulo que especifica as informações a serem incluídas no arquio de log de acessos do seridor Web e, para o SunONE Web Serer, o IHS Web Serer e o Apache Web Serer, a ariáel REMOTE_USER CGI. format-string unauth-user-string unauth-serer-user-string [tag-alue] auth-type cache-definitions cache-refresh-interal [token-card] use-utf8 use-uri-encoding A página de login de token-card. token-login-form next-token-form Cadeia de formatações utilizada para construir o nome do usuário do log da Web e, para o SunONE Web Serer, o IHS Web Serer e o Apache Web Serer, a ariáel REMOTE_USER CGI. A cadeia que é utilizada para indicar um usuário não autenticado do Access Manager (%u) no arquio de log de acessos do seridor Web. A cadeia que é utilizada para indicar um usuário não autenticado do seridor Web (%u) no arquio de log de acessos desse seridor Web. Uma cadeia de formatações para especificar o tipo de autenticação para os seridores Web que permitem essa manipulação. O único seridor Web que permite essa manipulação é o iplanet. Um booleano que indica se as definições de tag/alue anexadas ao espaço de objetos deem ou não ser armazenadas em cache. Se forem armazenadas em cache, o proxy precisará ser noamente iniciado para selecionar as alterações nas definições de tag/alue. O interalo de atualização, em segundos, para o cache de definições. Define qual conjunto de caracteres dee ser utilizado para codificar os dados de tag-alue. Se o alor for definido como false, os dados de tag-alue serão codificados na página de código local. O alor padrão é true. Define se a codificação em URI dos dados de tag-alue dee ou não ser executada. O nome do arquio para a página de logon de token. Define o formulário exibido ao cliente do usuário para solicitar o próximo token. O cliente é solicitado a inserir outro token quando o seridor não consegue autenticar com êxito o usuário a partir do primeiro token. 202 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 27. Parâmetros de Configuração de Autenticação (continuação) [http-hdr] Parâmetro Autenticação Descrição Contém todos os detalhes do módulo de sessão e de autenticação com base em cabeçalho HTTP. [i-headers] header O nome do cabeçalho transmitido ao CDAS (Cross Domain Authentication Serice) para autenticação. Contém todos os detalhes do módulo de pós-autorização e de autenticação com base em Cabeçalhos IV. [acctmgmt] accept generate use-utf8 serer-name-header Lista dos cabeçalhos a serem aceitos como proa de autenticação a partir de um proxy. As opções álidas são: all - Aceita todos os tipos de cabeçalho. i-creds - Informações sobre credenciais de usuários. i-user - Nome resumido do usuário. i-user-l - Nome completo do usuário. i-groups i-remote-address - Endereço IP do cliente. serer-name Lista de cabeçalhos a serem gerados ao encaminhar um pedido a partir de um proxy. As opções álidas são: all - Gera todos os tipos de cabeçalho. i-creds - Informações sobre credenciais de usuários. i-user - Nome resumido do usuário. i-user-l - Nome completo do usuário. i-remote-address - Endereço IP do cliente. Define se os cabeçalhos i deem ser codificados em UTF-8 ou no conjunto de códigos local. Se os plug-ins da Web precisarem aceitar cabeçalhos i gerados por uma ersão anterior do AMWebPI ou do AMWebSEAL, esse alor deerá ser definido como false. O nome do cabeçalho a ser utilizando quando serer-name estier presente na lista de alores a serem gerados. O alor padrão é i-serer-name. Contém dados para o módulo de pós-autorização com base em gerenciamento de contas. Esse módulo é responsáel pelo gerenciamento de operações de contas, como alterar a senha do usuário e efetuar logout. password-change-form password-change-form-uri password-change-uri password-change-success password-change-failure logout-uri O formulário exibido quando um usuário solicita uma alteração de senha. O URI acessado quando um usuário solicita uma alteração de senha. O destino de URI após uma alteração de senha. A página exibida quando um usuário conclui com êxito uma alteração de senha. A página exibida quando o usuário não consegue efetuar logon com êxito. O destino de URI após o logout do usuário. Apêndice B. Referência de pdwebpi.conf 203

Tabela 27. Parâmetros de Configuração de Autenticação (continuação) [ecsso] Parâmetro help-uri help-page logout-success Autenticação Descrição A localização da página de ajuda. O nome do arquio da página de ajuda exibida quando um usuário solicita ajuda. O URI ou o arquio exibido quando um usuário efetua logout com êxito. Conexão Única do e-community. O nome da sub-rotina dee corresponder ao nome do módulo para pdwpi-ecsso-module definido na sub-rotina [modules]. Para o tratamento correto do URI de logout (/pkmslogout, por padrão) by default) relacionado à Conexão Única do e-community, o módulo de pré-autorização ecsso dee ser configurado antes do módulo de pré-autorização acct-mgmt. e-community-name is-master-authn-serer master-authn-serer master-http-port master-https-port f-token-lifetime f-url allow-login-retry f-argument use-utf8 O nome do e-community exibido em pedidos e tokens de garantia. Especifica se o seridor é ou não um seridor master no e-community. Definido como yes, esse seridor aceita pedidos de garantia de outras instâncias de plug-in cujas chaes de domínio estão listadas na sub-rotina [ecsso-domain-keys]. O nome do seridor master em um e-community. Esse parâmetro será obrigatório se is-master-authn-serer estier definido como no. Especifica a porta (diferente da porta padrão 80) no seridor de autenticação master que atende a pedidos HTTP. Esse parâmetro será ignorado se o seridor corresponder ao seridor de autenticação master. Especifica a porta (diferente da porta padrão 443) no seridor de autenticação master que atende a pedidos HTTPS. Esse parâmetro será ignorado se o seridor corresponder ao seridor de autenticação master. A duração, em segundos, do token de garantia. O URL de garantia. Atia ou desatia a noa tentatia de login de usuário quando um usuário não autenticado é redirecionado ao seridor master para autenticação. Definido como true, o seridor master permite que o usuário insira noamente seu nome de usuário/senha após uma tentatia inicial fracassada. Definido como false, o usuário é redirecionado noamente ao seridor slae sem uma confirmação para esse usuário. O nome do argumento do token de garantia, conforme exibido na resposta de garantia. Atia ou desatia a codificação de cadeias utf8 nos cookies do e-community e nos tokens de garantia ECSSO. [ecsso-token-attributes] ou [ecsso_module_name-token-attributes:irtual_host] domain_name = pattern1, pattern2,... pattern n Especifica os atributos de credencial a serem incluídos nos tokens de garantia ECSSO. [ecsso-incoming-attributes] ou [ecsso_module_name-incoming-attributes] 204 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 27. Parâmetros de Configuração de Autenticação (continuação) Parâmetro attribute_pattern = presere refresh [ecsso-domain-keys] Autenticação Descrição Especifica os atributos de credencial a serem aceitos e a serem rejeitados para tokens de garantia de entrada. Define as chaes a serem utilizadas durante a comunicação com participantes a partir dos domínios especificados em um e-community. O nome dessa sub-rotina é deriado do nome do módulo para pdwpi-ecsso-module definido na sub-rotina [modules]. Seu formato é [ecsso-module-name-domain-keys]. O formato é:domain-name = key-file [cdsso] uri cdsso-argument authtoken-lifetime use-utf8 [cdsso-token-attributes] O uri especial que indica um redirecionamento e uma conexão única do CDSSO. O nome do argumento de cadeia de consulta que especifica o token de autenticação. É utilizado no uri de redirecionamento. A duração, em segundos, do token de autenticação. Controla a codificação de cadeias no token CDSSO. Essa opção apenas afeta os tokens CDSSO criados e consumidos pelas bibliotecas SSO padrão de criação e de consumo. Os tokens são codificados em UTF-8 por padrão. Define os conjuntos de atributos a serem incluídos em tokens de autenticação CDSSO, especificados para cada período ou para cada domínio. Esse processamento apenas ocorrerá se as bibliotecas SSO padrão de criação e de consumo de tokens estierem em uso. O formato dessas entradas é: domain-name = pattern-1, pattern-2,... pattern-n [cdsso-incoming-attributes] Define os conjuntos de atributos a serem aceitos e rejeitados a partir de tokens de autenticação CDSSO de entrada. O formato das entradas nessa sub-rotina é: attribute pattern=presere refresh [cdsso-domain-keys] Define as chaes a serem utilizadas durante a comunicação com participantes a partir dos domínios especificados em um e-community. O formato é: domain-name = key-file O nome dessa sub-rotina é deriado do nome do módulo para pdwpi-ecsso-module definido na sub-rotina [modules]. Seu formato é [ecsso-module-name-domain-keys]. [login-redirect] Contém todos os detalhes do módulo de pós-autorização com base em redirecionamento de login. Para que esse módulo funcione corretamente, DEVE ser configurado antes do módulo de pré-autorização com base em gerenciamento de contas. [spnego] redirect-uri spnego-krb-serice-name spnego-krb-keytab-file O URI para o qual um usuário é redirecionado após uma autenticação bem-sucedida. Armazena o nome do seriço no qual o seridor AMWebPI é autenticado durante a inicialização do módulo de autorização spnego. O nome do caminho do arquio de configuração do Kerberos. Apêndice B. Referência de pdwebpi.conf 205

Tabela 27. Parâmetros de Configuração de Autenticação (continuação) [ntlm] Parâmetro [web-serer-authn] use-pre-windows-2000-logonname use-pre-windows-2000-logonname [boolean-rules] Autenticação Descrição Permite que o nome de logon pré-windows 2000 represente o usuário autenticado no Tioli Access Manager. Corresponde à parte username do nome de logon DOMAIN\USERNAME. Permite que o nome de logon pré-windows 2000 represente o usuário autenticado no Tioli Access Manager. Corresponde à parte username do nome de logon DOMAIN\USERNAME. Altera a forma como as regras de autorização booleanas afetam o resultado da decisão de acesso. pass-on-rule-failure-reason [http-method-perms] Definido como o padrão, false, ou ausente, se uma regra de autorização booleana retornar!false!, o pedido será negado. Entretanto, definido como true, se uma regra de autorização retornar!false! e houer uma cadeia do motio da falha associada ao objeto da regra no banco de dados de critérios, o acesso será permitido, com essa cadeia do motio da falha inserida no pedido HTTP, no cabeçalho AM_AZN_FAILURE. Define as permissões necessárias para executar um pedido utilizando um método HTTP específico. [ext-auth-int] <default> Define as permissões necessárias para qualquer método não especificado explicitamente na sub-rotina. A entrada <default> propriamente dita não possui um alor padrão e dee ser especificada como uma string não azia na sub-rotina. Permite que uma credencial seja criada com base em informações fornecidas por um aplicatio backend. auth-url trigger-url redirect-url-hdr-name pac-hdr-name pac-sc-id-hdr-name user-id-hdr-name user-auth-leel-hdr-name user-qop-hdr-name user-ext-attr-list-hdr-name [switch-user] switch-user-form O URL para o qual um usuário é redirecionado quando um eento de autenticação é acionado deido ao critério de segurança configurado. O URL utilizado para indicar que a resposta dee ser utilizada para gerar uma credencial. Essas entradas contêm os nomes dos cabeçalhos de resposta que são utilizados na geração da credencial. Especifica o nome do arquio HTML que é retornado ao cliente após o pedido para su. O arquio dee estar localizado no diretório /opt/pdwebpi/nls/html/lang/charset. 206 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 27. Parâmetros de Configuração de Autenticação (continuação) switch-user-uri Parâmetro switch-user-post-uri [dynurl] Autenticação Descrição Especifica o nome do URI que é utilizado para chamar a função Comutação de Usuários. Especifica o URI para o qual o formulário su é submetido. Especifica as definições para o módulo de pré-autorização com base em URL dinâmico. O formato é: object = pattern Parâmetros de Configuração de Sessões Tabela 28. Parâmetros de Configuração de Sessões [sessions] Parâmetro max-entries timeout inactie-timeout resend-pdwebpi-cookies [session-cookie] [cred-refresh] reauth-lifetime-reset reauth-grace-period use-same-session Sessões Descrição O número máximo de sessões armazenadas em uma única instância de um módulo de sessão. O número máximo de sessões por módulo de sessão e por host irtual. A duração máxima, em segundos, de uma sessão. A duração do tempo inatio, em segundos, necessária para uma sessão antes que ela atinja o tempo limite. Atia ou desatia o enio de cookies do Plug-in da Web com cada pedido. Controla o cronômetro de duração da sessão. Definido como yes, o cronômetro de duração da sessão (ou seja, o alor definido no parâmetro de tempo limite) é zerado após uma noa autenticação bem-sucedida. Definido como no, uma reinicialização não é executada para uma noa autenticação bem-sucedida. Define o tempo, em segundos, que o cliente possui como período de tolerância durante o qual deerá executar com êxito uma noa autenticação quando a credencial tier expirado de alguma maneira. Especifica se os protocolos HTTP e HTTPS deem ou não utilizar a mesma sessão. Contém as informações de configuração para os atributos que deerão ser preserados a partir da credencial original e para os atributos que deerão ser atualizados na noa credencial quando ocorrer uma operação de atualização de credenciais. presere refresh Define os atributos a serem preserados a partir da credencial de usuário original. Define os atributos a serem atualizados na noa credencial. Apêndice B. Referência de pdwebpi.conf 207

Parâmetros de Configuração LDAP Tabela 29. Parâmetros de Configuração LDAP [ldap] Parâmetro bind-pwd ssl-enabled ssl-keyfile ssl-keyfile-dn ssl-keyfile-pwd cache-enabled ldap-serer-config auth-using-compare prefer-readwrite-serer bind-dn default-policy-oerride-support user-and-group-in-same-suffix LDAP Descrição A senha para o Daemon do Plug-in da Web (definida durante a configuração). Indica se o SSL está ou atiado ou não. Indica o caminho/nome de arquio do arquio de chaes SSL. Indica o rótulo de certificado no arquio de chaes SSL, se houer. Indica a senha do arquio de chaes SSL. Atia ou desatia o cache LDAP local. Localização do arquio ldap.conf. Indica se a autenticação dee ser executada com o uso da ligação LDAP ou por meio da comparação de senhas. Indica se o seridor LDAP graáel deerá ou não ser selecionado quando estier disponíel. Indica o Nome Distinto do daemon. Dee ser yes ou no. Quando for yes, nenhum Critério de usuário será erificado. Apenas o Critério padrão será erificado (economiza algumas pesquisas LDAP). Indica se os grupos estão definidos ou não no mesmo sufixo LDAP que o usuário. Parâmetros de Configuração de Proxy Tabela 30. Parâmetros de Configuração de Proxy [proxy-if] Parâmetro id number-of-workers worker-size cleanup-interal max-session-lifetime Proxy Descrição Especifica o ID ou o nome do arquio de memória compartilhada para a interface proxy. Esse ID dee corresponder ao ID utilizado pelos plug-ins. O número de encadeamentos subordinados que tratam pedidos de plug-ins. A quantidade de memória pré-alocada para cada encadeamento subordinado que trata pedidos de plug-ins. O tempo, em segundos, entre cada limpeza de memória. O tempo, em segundos, durante o qual o plug-in aguarda uma resposta do Authorization Serer antes de atingir o tempo limite. 208 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 30. Parâmetros de Configuração de Proxy (continuação) [proxy] Parâmetro error-page acct-locked-page retry-limit-reached-page login-success Proxy Descrição O caminho para a página exibida no naegador do usuário quando ocorre um erro inesperado do seridor. O caminho para a página exibida quando um usuário tenta acessar uma conta bloqueada. O caminho para a página exibida quando o número máximo permitido de tentatias fracassadas de logon for atingido. O número máximo de falhas de logon permitidas é definido no LDAP com o uso do comando policy. Especifica a página a ser exibida quando o plug-in não possui uma página para a qual redirecionar o usuário após um login bem-sucedido de token ou formulários. Essa situação pode ocorrer quando ocê constrói um formulário de login que retorna diretamente ao plug-in os dados POST de login. Parâmetros de Configuração da API de Autorização Tabela 31. Parâmetros de Configuração da API de Autorização Parâmetro [aznapi-configuration] API de Autorização Configuração e Parâmetros de Auditoria de Registro. logsize Descrição O tamanho, em bytes, acima do qual um noo arquio de log é criado. Se for definido como 0, um noo arquio de log não será criado. logflush logaudit auditlog auditcfg Se for definido como um número negatio, um noo arquio de log será criado diariamente, independentemente do tamanho. O interalo, em segundos, no qual os logs são descarregados. O alor máximo é 21600 (6 horas). Atia ou desatia o registro de auditoria. O nome do arquio de auditoria. Atia ou desatia registros de auditoria específicos para cada componente. Os alores álidos são: authn - Capturar eentos de autenticação. db-file azn - Capturar eentos autorização. Localização do arquio em cache de banco de dados de ACLs. Apêndice B. Referência de pdwebpi.conf 209

Tabela 31. Parâmetros de Configuração da API de Autorização (continuação) Parâmetro cache-refresh-interal listen-flags policy-cache-size resource-manager-proided-adi input-adi-xml-prolog xsl-stylesheet-prolog dynamic-adi-entitlement-serices cred-attribute-entitlement-serices [aznapi-entitlement-serices] Definições de Seriços da API de Autorização. serice_id API de Autorização Descrição O interalo, em segundos, entre erificações de atualizações para o seridor de autorização master. Atia ou desatia sinalizadores para a recepção de notificações sobre atualizações do cache de critérios. O tamanho máximo do cache de critérios na memória. Esse alor controla a quantidade de informações que são armazenadas em cache. O tamanho é especificado como o número de entradas. Especifica as definições de prefixos para a recuperação de informações sobre decisões de autorização a partir do pedido HTTP. Os alores associados a esse parâmetro não deem ser alterados. O prolog a ser adicionado ao início do documento XML que é criado com o uso da ADI (Informação sobre Decisões de Acesso) necessária para aaliar uma regra de autorização Booleana. O prolog a ser adicionado ao início da folha de estilo XSL que é criada com o uso do texto XSL que define uma regra de autorização Booleana. Esse parâmetro especifica uma lista de IDs de seriços de autorização configurados que serão consultados pelo mecanismo de regras se uma ADI ausente for detectada durante uma aaliação de regras de autorização. Os seriços de autorização listados deem respeitar as especificações de saída e de entrada para um seriço de recuperação dinâmica da ADI que estão descritas no documento Authorization Programmer s Guide. Quando é detectado que a ADI está ausente durante uma aaliação de regras, cada seriço na lista configurada é consultado, na ordem apropriada. Essas entradas deem fazer referência a seriços existentes de autorização que foram carregados com o uso de entradas de seriço na sub-rotina de configuração de seriços de autorização ou no atributo de inicialização. Uma lista de IDs de seriços de autorização configurados que será chamada durante a criação da credencial para reunir atributos a serem inseridos nessa credencial. Cada entrada da sub-rotina define tipos diferentes do seriço aznapi. Para obter informações adicionais, consulte o documento IBM Tioli Access Manager Authorization C API Deeloper s Reference. 210 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 31. Parâmetros de Configuração da API de Autorização (continuação) Parâmetro AZN_ENT_EXT_ATTR API de Autorização Descrição Este é um parâmetro em níel de sistema que não dee ser alterado. Ele permite o uso de atributos estendidos no espaço de objetos. Parâmetros de Configuração Específicos para um Seridor Web Tabela 32. Parâmetros de Configuração Específicos para um Seridor Web [p3p-header] Parâmetro Específico para um Seridor Web Descrição Especifica o critério compacto P3P que se aplica a todos os cookies HTTP definidos. p3p-element Esse parâmetro pode ser utilizado para especificar uma referência a um critério XML completo além do critério compacto configurado com o uso de outros parâmetros nessa sub-rotina. access disputes remedies non-identifiable Desfazer o comentário da linha, p3p-element = policyref="/w3c/p3p.xml", direciona o plug-in ao critério XML completo. Especifica o acesso do usuário às informações contidas e inculadas pelo cookie. Valores possíeis: none all nonident contact-and-other ident-contact other-ident Especifica se o critério P3P completo contém ou não algumas informações relacionadas a disputas sobre as informações contidas no cookie. Os alores álidos são true ou false. Esse parâmetro é desatiado por padrão. Especifica as possíeis soluções para disputas. Os alores possíeis são: correct money law Se não for especificado, nenhuma informação sobre soluções será incluída no critério. Quando definido como true, esse parâmetro especifica que nenhuma informação no cookie, ou que nenhuma informação inculada pelo cookie, identifica pessoalmente o usuário de nenhuma maneira. Os alores álidos são true ou false. Esse parâmetro é desatiado por padrão. Apêndice B. Referência de pdwebpi.conf 211

Tabela 32. Parâmetros de Configuração Específicos para um Seridor Web (continuação) purpose Parâmetro Específico para um Seridor Web Descrição Especifica a finalidade das informações no cookie e inculadas pelo cookie. Os alores possíeis são: current admin deelop tailoring pseudo-analysis pseudo-decision indiidual-analysis indiidual-decision contact historical telemarketing e other-purpose. Para todos os alores, com exceção de current, um especificador adicional pode ser configurado. Os alores possíeis são: always opt-in opt-out. recipient retention Para finalidades não especificadas, o alor padrão é always. Esse alor é especificado após a finalidade, separado por um caractere de dois pontos, por exemplo: purpose = contact:opt-in Especifica os destinatários das informações no cookie e das informações inculadas pelo cookie. Os alores possíeis são: ours deliery same unrelated public other-recipient. Especifica por quanto tempo as informações no cookie ou as informações inculadas pelo cookie deem ser mantidas. Os alores possíeis são: no-retention stated-purpose legal-requirement business-practices indefinitely. 212 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 32. Parâmetros de Configuração Específicos para um Seridor Web (continuação) categories Parâmetro Específico para um Seridor Web Descrição Especifica os tipos de informações armazenadas no cookie ou inculadas pelo cookie. [ihs] query-contents query-log-file doc-root [apache] query-contents Se o parâmetro non-identifiable for definido como true, nenhuma categoria precisará ser configurada. Os alores possíeis são: physical online uniqueid purchase financial computer naigation interactie demographic content state political health preference location goernment other-category Especifica o programa de conteúdo de consultas a ser utilizado para naegar no espaço da Web do IBM HTTP Serer pelo comando pdadmin> object list. Esse parâmetro pode ser substituído para cada ramificação por meio da especificação de um alor para ele em uma sub-rotina denominada [ihs:branch], por exemplo, [ihs:/pdwebpi/foo.bar.com] Localização do arquio de log para erros encontrados pelo programa de conteúdo de consultas. Especifica a raiz da documentação que fornece a capacidade de naegação no espaço da Web necessária para executar comandos pdadmin> object list. Esse parâmetro é definido pelo utilitário de configuração ao configurar hosts irtuais. Ele é especificado para cada ramificação de critério em uma sub-rotina [ihs:branch], por exemplo, [ihs:/pdwebpi/foo.bar.com] Especifica o programa de conteúdo de consultas a ser utilizado para naegar no espaço da Web do Apache pelo comando pdadmin> object list. Esse parâmetro pode ser substituído para cada ramificação por meio da especificação de um alor para ele em uma sub-rotina denominada [apache:branch], por exemplo, [apache:/pdwebpi/lotus.com] Apêndice B. Referência de pdwebpi.conf 213

Tabela 32. Parâmetros de Configuração Específicos para um Seridor Web (continuação) query-log-file doc-root [iis] [iplanet] Parâmetro query-contents query-log-file log-file use-error-pages Específico para um Seridor Web Descrição Localização do arquio de log para erros encontrados pelo programa de conteúdo de consultas. Especifica a raiz da documentação que fornece a capacidade de naegação no espaço da Web necessária para executar comandos pdadmin> object list. Esse parâmetro é definido pelo utilitário de configuração ao configurar hosts irtuais. Ele é especificado para cada ramificação de critério em uma sub-rotina [apache:branch], por exemplo, [apache:/pdwebpi/lotus.com] Especifica o programa de conteúdo de consultas para naegar no espaço da Web do IIS pelo comando pdadmin. Esse parâmetro pode ser substituído para cada ramificação por meio da especificação de um alor para ele em uma sub-rotina denominada [iis:branch], por exemplo, [iis:/pdwebpi/foo.bar.com] Localização do arquio de log para erros encontrados pelo programa de conteúdo de consultas. Define o arquio de log para mensagens de rastreio e erro a partir do plug-in para IIS. As mensagens são mantidas separadas do arquio de log do Authorization Serer de forma a garantir a consistência dos arquios. Ele é especificado como um caminho relatio, ou seja, a localização está relacionada ao subdiretório de log do diretório de instalação. Se for especificado como um caminho absoluto, esse caminho absoluto será utilizado. Controla e as páginas configuradas pelo IIS para o código de erro são retornadas ao cliente ou, em ez disso, se algumas páginas simples construídas são retornadas. Parâmetros de configuração específicos para o Tioli Access Manager Plug-in para iplanet Web Serer. query-contents query-log-file Especifica o programa de conteúdo de consultas para naegar no espaço da Web do Sun ONE pelo comando pdadmin. Esse parâmetro pode ser substituído para cada ramificação por meio da especificação de um alor para ele em uma sub-rotina denominada [iplanet:branch], por exemplo, [iplanet:/pdwebpi/foo.bar.com] Localização do arquio de log para erros encontrados pelo programa de conteúdo de consultas. 214 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 32. Parâmetros de Configuração Específicos para um Seridor Web (continuação) Parâmetro doc-root Específico para um Seridor Web Descrição Especifica a raiz da documentação que fornece a capacidade de naegação no espaço da Web necessária para executar comandos pdadmin> object list. Esse parâmetro é definido pelo utilitário de configuração ao configurar hosts irtuais. Ele é especificado para cada ramificação de critério em uma sub-rotina [iplanet:branch], por exemplo, [iplanet:/pdwebpi/foo.bar.com] Apêndice B. Referência de pdwebpi.conf 215

216 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Apêndice C. Referência Rápida de Módulos Autenticação é o método de identificar uma entidade ou um processo indiidual que está tentando efetuar logon em um domínio protegido. O método de autenticação utilizado por um indiíduo ou um processo para acessar o domínio protegido de um plug-in pode assumir uma entre as árias formas possíeis. O IBM Tioli Access Manager Plug-in para Web Serers suporta diersos métodos de autenticação. Esses métodos de autenticação estão listados com uma descrição apropriada nas tabelas a seguir. Tabela 33. Referência de Métodos/Módulos de Autenticação de Plug-ins Método/módulo de autenticação BA pdwpi-ba-module forms pdwpi-forms-module Descrição Módulo de autenticação por Autenticação Básica. Também pode ser configurado como um módulo de pós-autorização ou de sessão. Módulo de autenticação com base em Formulários HTML. Faz a autenticação utilizando um nome de usuário e uma senha submetidos por meio de um formulário. ip-addr pdwpi-ipaddr-module Quando esse módulo é utilizado, ele também dee ser configurado como um módulo de pós-autorização. Módulo de autenticação com base em Endereço IP do Cliente. Fornece a autenticação exclusiamente com base no endereço IP do cliente. Um mecanismo de autenticação http-request dee ser fornecido pelo cliente de forma a mapear as informações sobre endereço IP para um responsáel do Tioli Access Manager. http-hdr pdwpi-httphdr-module token pdwpi-token-module Também pode ser configurado como um módulo de sessão. Módulo de autenticação com base em Cabeçalho HTTP. Fornece a autenticação exclusiamente com base no alor de um cabeçalho HTTP nomeado no pedido. Um mecanismo de autenticação http-request dee ser fornecido pelo cliente de forma a mapear as informações sobre cabeçalho para um responsáel do Tioli Access Manager. Também pode ser configurado como um módulo de sessão. Módulo de autenticação com base em Token. O Tioli Access Manager Plug-in para Web Serers suporta a autenticação com o uso de um código de acesso de token fornecido pelo cliente. Essa autenticação utiliza um logon de dois fatores com base em fobs RSA SecureID. Quando esse módulo é utilizado, ele também dee ser configurado como um módulo de pós-autorização. Copyright IBM Corp. 2000, 2003 217

Tabela 33. Referência de Métodos/Módulos de Autenticação de Plug-ins (continuação) Método/módulo de autenticação cert pdwpi-certificate-module Descrição Módulo de autenticação com base em Certificado do Cliente. O DN de assunto do certificado do cliente é mapeado pelo mecanismo de autenticação cert-ssl para um nome de responsáel do Tioli Access Manager. O mecanismo de autenticação cert-ssl requer que o DN de assunto do certificado do cliente seja mapeado diretamente para o DN de um usuário do Tioli Access Manager no registro de usuários. failoer pdwpi-failoercookie-module Esse módulo ignora pedidos de autenticação para outros pedidos que não chegaram por meio de uma sessão SSL e, portanto, pode ser configurado com segurança para hosts irtuais que tratam a autorização de pedidos HTTP e HTTPS. Módulo de autenticação com base em Cookie de Failoer. Esse módulo aceita um cookie de failoer para autenticar um usuário. i-headers pdwpi-i-headers-module Quando esse módulo é utilizado, ele também dee ser configurado como um módulo de pós-autorização. Módulo de autenticação com base em Cabeçalhos IV. Fornece a autenticação com base nos alores do cabeçalho HTTP i-user, i-user-l, i-creds ou i-remote-address no pedido. Isso é útil para utilizar a conexão única no Tioli Access Manager Plug-in para Web Serers quando um usuário já está autenticado em um seridor proxy front-end. Para ser confiáel, o pedido dee ter chegado utilizando uma sessão autenticada com um seridor proxy front-end (por exemplo, campos de junção do WebSEAL). O proxy dee ser autenticado como um usuário com a permissão Proxy ([PDWebPI]p) sobre a ramificação do espaço de objetos protegidos do host irtual que está sendo acessado. Para a autenticação com o uso do cabeçalho i-remote-address, um mecanismo de autenticação http-request dee ser fornecido pelo cliente de forma a mapear as informações sobre endereço IP a um responsáel do Tioli Access Manager. Esse módulo também pode ser configurado como um módulo de pós-autorização e de sessão. 218 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 33. Referência de Métodos/Módulos de Autenticação de Plug-ins (continuação) Método/módulo de autenticação ecsso pdwpi-ecsso-module Descrição Módulo de autenticação com base em Conexão Única do e-community. Esse módulo dee ser configurado como um módulo de autenticação para hosts irtuais que não sejam o seridor de autenticação master que está participando do e-community. unauth pdpwi-unauth-module ltpa pdwpi-ltpa-module spnego pdwpi-spnego-module cdsso pdwpi-cdsso-module ext-auth-int pdwpi-ext-auth-int -module Quando esse módulo é utilizado, ele também dee ser configurado como um módulo de pré-autorização. Módulo de autenticação para Usuários Não Autenticados. Esse módulo está listado aqui por questão de integridade. Ele é sempre implicitamente configurado como o módulo de autenticação de menor precedência e é utilizado para gerar uma credencial para usuários não autenticados. Módulo de autenticação LTPA Aceita e autentica usuários com base em um cookie LTPA. Esse cookie LTPA pode ser fornecido pelo WebSEAL ou por um WebSphere Serer. Módulo de autenticação SPNEGO Utiliza o protocolo de autenticação SPNEGO padrão nos domínios de LAN do Windows para obter uma solução de Conexão Única para implementações de plug-ins no IIS. Módulo de autenticação CDSSO Permite a conexão única entre diferentes domínios. Módulo de interface de autenticação externa. Permite que uma credencial seja criada com base nas informações fornecidas por um aplicatio backend. Tabela 34. Módulos de Autenticação Específicos para o Windows Módulo ntlm pdwpi-ntlm-module web-serer-authn pdwpi-websrauth-module Descrição Módulo de autenticação NTLM. O NTLM é um módulo de autenticação específico para o Windows que utiliza o nome de logon do Windows 2000 para representar o usuário autenticado no Tioli Access Manager. Módulo de autenticação para seridor Web. O módulo de autenticação para seridor Web é um módulo de autenticação para plataformas Windows. Esse módulo utiliza o nome de logon do Windows 2000 para representar o usuário autenticado no Tioli Access Manager. Apêndice C. Referência Rápida de Módulos 219

Tabela 35. Referência de Módulos de Sessão de Plug-ins BA pdwpi-ba-module Módulo Descrição Módulo de sessão por Autenticação Básica. Utiliza o alor do cabeçalho de Autorização por Autenticação Básica como uma chae de sessão. Quando esse módulo é utilizado, ele também dee ser configurado como um módulo de autenticação. ip-addr pdwpi-ipaddr-module http-hdr pdwpi-httphdr-module session-cookie pdwpi-sesscookie-module ssl-id pdwpi-sslsessid-module i-headers pdwpi-i-headers-module ltpa pdwpi-ltpa-module Também pode ser configurado como um módulo de pós-autorização. Módulo de sessão com base em Endereço IP. Utiliza o endereço IP de um cliente autenticado como a chae de sessão. Quando esse módulo é utilizado, ele também dee ser configurado como um módulo de autenticação. Módulo de sessão com base em Cabeçalho HTTP. Utiliza um cabeçalho HTTP autenticado como a chae de sessão. Quando esse módulo é utilizado, ele também dee ser configurado como um módulo de autenticação. Módulo de sessão com base em Cookies de Sessão. Esse módulo gera e aceita cookies para uso na identificação de sessões. Geralmente, ele apenas é utilizado como um mecanismo de identificação de sessões de baixa prioridade. Módulo de sessão com base em IDs de Sessão SSL. Utiliza o ID da Sessão SSL como uma chae de sessão. Obsere que, embora esse módulo seja fornecido na distribuição para Windows do Tioli Access Manager Plug-in para Web Serers, o Microsoft Internet Information Serices Web Serer não fornece informações sobre ID da Sessão SSL ao plug-in e, portanto, não é possíel utilizar IDs de Sessão SSL como chaes de sessão para o IIS. Módulo de sessão com base em Cabeçalhos IV Utiliza cabeçalhos IV para manter o estado das sessões. Módulo de sessão LTPA. Utiliza cookies LTPA para manter o estado das sessões. Tabela 36. Referência de Módulos de Pré-autorização de Plug-ins Módulo boolean-rules pdwpi-boolean-rules-module Descrição Módulo de pré-autorização com base em Regras Booleanas. 220 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 36. Referência de Módulos de Pré-autorização de Plug-ins (continuação) Módulo switch-user pdwpi-switch-user-module Descrição Módulo de pré-autorização com base em Comutação de Usuários. dynurl pdwpi-dynurl-module Módulo de pré-autorização com base em URL Dinâmico. acctmgt pdwpi-acct-mgmt-module cred-refresh pdwpi-cred-refresh-module Módulo de pré-autorização com base em Gerenciamento de Contas. Esse módulo fornece os recursos de logout (/pkmslogout), alteração de senha (/pkmspasswd) e ajuda (/pkmshelp). Módulo de pré-autorização com base em Atualização de Credenciais. forms pdwpi-forms-module token pdwpi-token-module ext-auth-int pdwpi-ext-auth-int-module Módulo de pré-autorização com base em Formulários. Módulo de pré-autorização com base em Token. O Tioli Access Manager Plug-in para Web Serers suporta a autenticação com o uso de um código de acesso de token fornecido pelo cliente. Essa autenticação utiliza um logon de dois fatores com base em fobs RSA SecureID. Quando o módulo de token é utilizado, ele também dee ser configurado como um módulo de autenticação. Módulo de pré-autorização com base em interface de autenticação externa. login-redirect pdwpi-loginredirect-module ecsso pdwpi-ecsso-module Módulo de pré-autorização com base em Redirecionamento de Login. Ao efetuar login utilizando qualquer um dos métodos suportados pelo plug-in, o usuário é redirecionado a uma página configurada após a autenticação bem-sucedida. Módulo de pré-autorização com base em Conexão Única do e-community. Todos os hosts irtuais que participam de um e-community deem ter o módulo ecsso configurado como um módulo de pós-autorização. Esse módulo também dee ser configurado como um módulo de autenticação para todos os participantes que não sejam o seridor de autenticação master. Apêndice C. Referência Rápida de Módulos 221

Tabela 37. Referência de Módulos de Pós-autorização de Plug-ins Módulo forms pdwpi-forms-module Descrição Módulo de pós-autorização com base em Formulários HTML. Esse módulo trata a submissão dos dados de formulários durante um logon com base em Formulários HTML. Quando esse módulo é utilizado, ele também dee ser configurado como um módulo de autenticação. BA pdwpi-ba-module failoer pdwpi-failoercookie-module Esse módulo também pode definir o cabeçalho BA a partir do nome do usuário e da senha submetidos. Módulo de pós-autorização por Autenticação Básica. Modifica o cabeçalho BA isto pelo seridor Web ou criando esse cabeçalho a partir de dados de segurança GSO. Módulo de pós-autorização com base em Cookies de Failoer. Esse módulo gera um cookie de failoer para o cliente. i-headers pdwpi-i-headers-module tag-alue pdwpi-tag-alue-module ltpa pdwpi-ltpa-module cdsso pdwpi-cdsso-module Quando o módulo de cookies de failoer é utilizado, ele também dee ser configurado como um módulo de autenticação. Módulo de pós-autorização com base em Cabeçalhos IV. Esse módulo insere informações sobre a identidade de usuários como cabeçalhos IV no pedido antes de permitir que esse pedido seja tratado pelo seridor Web. Isso é útil para fornecer uma conexão única em um aplicatio hospedado pelo seridor Web. Os cabeçalhos que podem ser adicionados são i-user, i-user-l, i-groups, i-creds e i-remote-address. Esse módulo também pode ser configurado como um módulo de autenticação e de sessão. Módulo de pós-autorização com base em Marcação/Valor. Esse módulo insere atributos estendidos adicionais a partir da credencial do usuário como cabeçalhos HTTP no pedido antes de permitir que esse pedido seja tratado pelo seridor Web. Esses atributos estendidos normalmente correspondem aos atributos do usuário a partir do registro de usuários. Módulo de pós-autorização com base em Cookies LTPA. Esse módulo insere um cookie LTPA (Lightweight Third Party Authentication) do WAS (WebSphere Application Serer) no pedido antes de permitir que esse pedido seja tratado pelo seridor Web. Isso fornece uma conexão única em um WAS hospedado pelo seridor Web. Módulo de pós-autorização CDSSO. 222 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Tabela 37. Referência de Módulos de Pós-autorização de Plug-ins (continuação) Módulo boolean-rules pdwpi-boolean-rules-module fsso pdwpi-fsso-module web-log pdwpi-web-log-module Descrição Módulo de pós-autorização com base em Regras Booleanas. Módulo de Conexão Única por Formulários. Módulo de pós-autorização com base em Log da Web. Tabela 38. Referência de Módulos de Resposta Módulo fsso pdwpi-fsso-module ext-auth-int pdwpi-ext-auth-int-module Descrição Módulo de resposta com base em Conexão Única por Formulários. Módulo de resposta com base em interface de autenticação externa. Apêndice C. Referência Rápida de Módulos 223

224 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Apêndice D. Referência Rápida de Comandos Copyright IBM Corp. 2000, 2003 225

pdwebpi_start Inicia, inicia noamente e pára o processo do Tioli Access Manager Plug-in para Web Serers em instalações UNIX. Obsere que o Plug-in para Web Serers é automaticamente iniciado e parado quando o produto Tioli Access Manager Base é iniciado ou parado. Além disso, exibe o status de todos os seridores Web. Nota: Se necessário, o comando pdwebpi_start pode ser utilizado para controlar o Plug-in para Web Serers, independentemente do produto Tioli Access Manager Base. Sintaxe pdwebpi_start start pdwebpi_start stop pdwebpi_start restart pdwebpi_start status Parâmetros pdwebpi_start {start stop restart status} em que: start Inicia o processo do Plug-in para Web Serers em instalações no UNIX. stop Pára o processo do Plug-in para Web Serers em instalações no UNIX. restart Pára e, em seguida, inicia noamente o processo do Plug-in para Web Serers em instalações no UNIX. status Fornece informações de status do Plug-in para Web Serers em instalações no UNIX. Comentários Para iniciar e parar instalações do plug-in no Windows, identifique o processo do Plug-in para Web Serers no Painel de Controle de Seriços e utilize os botões de controle apropriados. Disponibilidade Esse comando está localizado nos seguintes diretórios de instalação padrão: Sistemas UNIX: /opt/pdwebpi/sbin/ Em sistemas Windows: C:\Arquios de programas\tioli\pdwebpi\sbin\ Quando um diretório de instalação diferente do padrão é selecionado, esse utilitário está localizado no diretório sbin no diretório de instalação (por exemplo, install_dir\sbin\). Códigos de Retorno Os seguintes códigos de status de saída podem ser retornados: 226 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

0 O comando foi concluído com êxito. 1 Ocorreu um erro. Apêndice D. Referência Rápida de Comandos 227

pdwebpi Fornece informações sobre a ersão do Tioli Access Manager Plug-in para Web Serers. Além disso, determina se o Plug-in para Web Serers dee ser executado como um daemon ou em primeiro plano. Sintaxe pdwebpi [ foreground] [ ersion] Parâmetros foreground Executa o binário do Plug-in para Web Serers no primeiro plano em ez de executá-lo como um daemon. ersion Fornece informações sobre ersão para a instalação do Plug-in para Web Serers. Disponibilidade Esse comando está localizado nos seguintes diretórios de instalação padrão: Sistemas UNIX: /opt/pdwebpi/bin/ Em sistemas Windows: C:\Arquios de programas\tioli\pdwebpi\bin\ Quando um diretório de instalação diferente do padrão é selecionado, esse utilitário está localizado no diretório bin no diretório de instalação (por exemplo, install_dir\bin\). Códigos de Retorno Os seguintes códigos de status de saída podem ser retornados: 0 O comando foi concluído com êxito. 1 O command falhou. Quando ocorre uma falha em um comando, são fornecidos uma descrição do erro e um código de status do erro no formato hexadecimal (por exemplo, 0x14c012f2). Consulte o IBM Tioli Access Manager Error Message Reference. Essa referência fornece uma lista das mensagens de erro do Tioli Access Manager de acordo com códigos decimais ou hexadecimais. 228 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

pdwpi-ersion Lista as informações de ersão e copyright para a instalação do Tioli Access Manager Plug-in para Web Serers. Sintaxe pdwpi-ersion [ h] [ V] [ l binary [binary... ]] Parâmetros h Exibe uma mensagem de ajuda ou de uso. l Especifica uma lista longa, que relaciona as ersões de todos os binários e não apenas a ersão do pacote. V Exibe as informações sobre ersão para o binário pdwpi-ersion. binary [binary] Exibe informações sobre ersão para binários especificados ou para todos os arquios se nenhum arquio binário for especificado. Disponibilidade Esse comando está localizado nos seguintes diretórios de instalação padrão: Sistemas UNIX: /opt/pdwebpi/bin/ Em sistemas Windows: C:\Arquios de programas\tioli\pdwebpi\bin\ Quando um diretório de instalação diferente do padrão é selecionado, esse utilitário está localizado no diretório bin no diretório de instalação (por exemplo, install_dir\bin\). Códigos de Retorno Os seguintes códigos de status de saída podem ser retornados: 0 O comando foi concluído com êxito. 1 Ocorreu um erro. Apêndice D. Referência Rápida de Comandos 229

pdwpicfg action config Configura o Tioli Access Manager Plug-in para Web Serers. Sintaxe pdwpicfg action config admin_id admin_id admin_pwd admin_pwd auth_port authorization_port_number web_serer {iis iplanet ihs apache} iis_filter {yes no} web_directory serer_install_directory hosts irtual_host_id ssl_enable {yes no} keyfile keyfile key_pwd key_password key_label key_label ssl_port ssl_port_number pdwpicfg action config interactie {yes no} pdwpicfg action config rspfile response_file pdwpicfg operations pdwpicfg help [ options] pdwpicfg usage pdwpicfg? Parâmetros admin_id admin_id Especifica o identificador do usuário de administração (normalmente, sec_master). admin_pwd admin_pwd Especifica a senha do usuário administratio admin_id. auth_port authorization_port_number Especifica o número da porta do Authorization Serer. O alor do número da porta padrão é 7237. help [options] Lista o nome da opção e uma descrição resumida. Se uma ou mais opções forem especificadas, listará cada opção e uma bree descrição. interactie {yes no} Atiará o modo interatio para o comando se for yes; caso contrário, desatiará o modo interatio para esse comando. O alor padrão é yes. iis_filter {yes no} Atiará a filtragem do IIS (Internet Information Serer) se for yes; caso contrário, desatiará a filtragem do IIS. keyfile keyfile Especifica o arquio de chaes SSL do LDAP. Não há um alor padrão. Especifique essa opção quando o comando não estier sendo executado no modo interatio e quando ocê tier atiado o SSL entre o Plug-in para Web Serers e o LDAP. key_label key_label Especifica o rótulo de chaes SSL do LDAP. Não há um alor padrão. 230 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Especifique essa opção quando o comando não estier sendo executado no modo interatio e quando ocê tier atiado o SSL entre o Plug-in para Web Serers e o LDAP. key_pwd key_password Especifica a senha do arquio de chaes SSL do LDAP. operations Lista cada um dos nomes de opção, um após o outro, sem descrições. rspfile response_file Fornece o nome de arquio e o caminho completo para o arquio de resposta do Plug-in para Web Serers a ser utilizado durante a instalação silenciosa. Um arquio de resposta pode ser utilizado para configuração ou desconfiguração. Não há um nome de arquio de resposta padrão. O arquio de resposta contém sub-rotinas e entradas de sub-rotinas para pares de opção=alor. Para utilizar arquios de resposta, consulte os procedimentos no IBM Tioli Access Manager para e-business: Guia de Instalação de Segurança da Web. ssl_enable {yes no} Atiará comunicações SSL com o LDAP se for yes; caso contrário, desatiará comunicações SSL com o LDAP. O alor padrão é yes. ssl_port ssl_port_number Especifica a porta SSL do LDAP. O alor do número da porta padrão é 636. usage Exibe a sintaxe de uso para esse comando. Também exibe um exemplo. hosts irtual_host_id Especifica os hosts irtuais que deem ser protegidos. O alor dee estar no formato de uma lista separada por írgulas de IDs de hosts irtuais. Não dee haer espaços entre os IDs de hosts irtuais. web_directory serer_install_directory Especifica o diretório de instalação do seridor Web. web_serer {iis iplanet ihs apache} Especifica o tipo de seridor Web no qual o Plug-in para Web Serers dee ser instalado. As opções são: iis para o Internet Information Serer, iplanet para o Sun ONE Serer, ihs para o IBM HTTP Serer ou apache para o Apache Serer. Essa opção assume como padrão o tipo e a localização do seridor Web configurado.? Exibe a sintaxe de uso para esse comando. Também exibe um exemplo. Disponibilidade Esse comando está localizado nos seguintes diretórios de instalação padrão: Sistemas UNIX: /opt/pdwebpi/bin/ Em sistemas Windows: C:\Arquios de programas\tioli\pdwebpi\bin\ Quando um diretório de instalação diferente do padrão é selecionado, esse utilitário está localizado no diretório bin no diretório de instalação (por exemplo, install_dir\bin\). Códigos de Retorno Os seguintes códigos de status de saída podem ser retornados: Apêndice D. Referência Rápida de Comandos 231

0 O comando foi concluído com êxito. 1 O command falhou. Quando ocorre uma falha em um comando, são fornecidos uma descrição do erro e um código de status do erro no formato hexadecimal (por exemplo, 0x14c012f2). Consulte o IBM Tioli Access Manager Error Message Reference. Essa referência fornece uma lista das mensagens de erro do Tioli Access Manager de acordo com códigos decimais ou hexadecimais. 232 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

pdwpicfg action unconfig Desconfigura o Tioli Access Manager Plug-in para Web Serers. Sintaxe pdwpicfg action unconfig admin_id admin_id admin_pwd admin_pwd force {yes no} remoe {none acls objspace all} hosts irtual_host_id pdwpicfg action unconfig interactie {yes no} pdwpicfg action unconfig rspfile response_file pdwpicfg operations pdwpicfg help [ options] pdwpicfg usage pdwpicfg? Parâmetros admin_id admin_id Especifica o identificador do usuário de administração (normalmente, sec_master). admin_pwd admin_pwd Especifica a senha do usuário administratio admin_id. force {yes no} Força o aanço do processo de desconfiguração mesmo que não seja possíel entrar em contato com o Policy Serer. O alor padrão é no. help [options] Lista o nome da opção e uma descrição resumida. Se uma ou mais opções forem especificadas, listará cada opção e uma bree descrição. interactie {yes no} Atiará o modo interatio para o comando se for yes; caso contrário, desatiará o modo interatio para esse comando. O alor padrão é yes. operations Lista cada um dos nomes de opção, um após o outro, sem descrições. remoe {none acls objspace all} Especifica se é necessário remoer o espaço de objetos ou as ACLs, ou ambos, como parte do processo de desconfiguração. O alor padrão é none. rspfile response_file Fornece o nome de arquio e o caminho completo para o arquio de resposta do Plug-in para Web Serers a ser utilizado durante a instalação silenciosa. Um arquio de resposta pode ser utilizado para configuração ou desconfiguração. Não há um nome de arquio de resposta padrão. O arquio de resposta contém sub-rotinas e entradas de sub-rotinas para pares de opção=alor. Para utilizar arquios de resposta, consulte os procedimentos no IBM Tioli Access Manager para e-business: Guia de Instalação de Segurança da Web. usage Exibe a sintaxe de uso para esse comando. Também exibe um exemplo. Apêndice D. Referência Rápida de Comandos 233

hosts irtual_host_id Especifica os identificadores dos hosts irtuais que deem ser desconfigurados. O alor pode estar no formato de uma lista separada por írgulas de IDs de hosts irtuais. Não dee haer espaços entre os IDs de hosts irtuais.? Exibe a sintaxe de uso para esse comando. Também exibe um exemplo. Disponibilidade Esse comando está localizado nos seguintes diretórios de instalação padrão: Sistemas UNIX: /opt/pdwebpi/bin/ Em sistemas Windows: C:\Arquios de programas\tioli\pdwebpi\bin\ Quando um diretório de instalação diferente do padrão é selecionado, esse utilitário está localizado no diretório bin no diretório de instalação (por exemplo, install_dir\bin\). Códigos de Retorno Os seguintes códigos de status de saída podem ser retornados: 0 O comando foi concluído com êxito. 1 O command falhou. Quando ocorre uma falha em um comando, são fornecidos uma descrição do erro e um código de status do erro no formato hexadecimal (por exemplo, 0x14c012f2). Consulte o IBM Tioli Access Manager Error Message Reference. Essa referência fornece uma lista das mensagens de erro do Tioli Access Manager de acordo com códigos decimais ou hexadecimais. 234 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Apêndice E. Caracteres Especiais Permitidos em Expressões Comuns A tabela a seguir lista os caracteres especiais permitidos em expressões comuns utilizadas no arquio de configuração pdwebpi.conf. * Corresponde a zero ou mais caracteres? Corresponde a qualquer caractere \ Caractere de escape (por exemplo, \? corresponde a?) [acd] [^acd] [a-z] [^0-9] [a-za-z] Corresponde ao caractere a, c ou d (faz distinção entre maiúsculas e minúsculas) Corresponde a qualquer caractere, com exceção de a, c ou d (faz distinção entre maiúsculas e minúsculas) Corresponde a qualquer caractere entre a e z (letras minúsculas) Corresponde a qualquer caractere que não esteja entre 0 e 9 (não um número) Corresponde a qualquer caractere entre a e z (minúsculas) ou A e Z (maiúsculas) Copyright IBM Corp. 2000, 2003 235

236 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Apêndice F. Aisos Estas informações foram desenolidas para produtos e seriços oferecidos nos Estados Unidos. É possíel que a IBM não ofereça os produtos, seriços ou recursos discutidos nesta publicação em outros países. Consulte seu representante IBM local sobre os produtos e seriços atualmente disponíeis na sua região. Qualquer referência a um produto, programa ou seriço da IBM não tem a intenção de afirmar ou inferir que somente esse produto, programa ou seriço possa ser utilizado. Qualquer produto, programa ou seriço funcionalmente equialente que não infrinja nenhum direito de propriedade intelectual da IBM poder ser utilizado. Contudo, é de responsabilidade do usuário aaliar e erificar o funcionamento de qualquer produto, programa ou seriço que não seja da IBM. A IBM pode ter patentes ou solicitações de patentes pendentes relatias a assuntos tratados nesta publicação. O fornecimento desta publicação não garante ao Cliente nenhum direito sobre tais patentes. Pedidos de licença deem ser eniados, por escrito, para: Gerência de Relações Comerciais e Industriais da IBM Brasil A. Pasteur, 138-146, Botafogo Rio de Janeiro, RJ CEP: 22290-240 Para pedidos de licença relacionados a informações de DBCS (conjunto de caracteres de byte duplo), entre em contato com o Departamento de Propriedade Intelectual da IBM em seu país ou enie pedidos de licença, por escrito, para: IBM World Trade Asia Corporation Licensing2-31 Roppongi 3-chome, Minato-kuTokyo 106-0032, Japan O seguinte parágrafo não se aplica ao Reino Unido e a nenhum país em que tais disposições não esteja de acordo com a legislação local: A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO NO ESTADO EM QUE SE ENCONTRA SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO LIMITANDO, AS GARANTIAS IMPLÍCITAS DE NÃO INFRINGIR A COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO OBJETIVO. Alguns países não permitem a exclusão de garantias expressas ou implícitas em certas transações; portanto, esta disposição pode não se aplicar ao Cliente. Estas informações podem incluir imprecisões técnicas ou erros tipográficos. Periodicamente, são feitas alterações nas informações aqui contidas; tais alterações serão incorporadas em futuras edições desta publicação. A IBM pode, a qualquer momento, aperfeiçoar e/ou alterar os produtos e/ou programas descritos nesta publicação, sem aiso préio. Referências nestas informações a web sites não-ibm são fornecidas apenas por coneniência e não representam de forma alguma um endosso a esses Web sites. Os materiais nesses Web sites não são parte dos materiais deste produto IBM e o uso de tais Web sites é por conta e risco do Cliente. A IBM pode utilizar e diulgar quaisquer informações fornecidas, em qualquer forma que julgar adequada, sem incorrer em qualquer obrigação com relação a ocê. Copyright IBM Corp. 2000, 2003 237

Licenciados deste programa que desejam obter informações adicionais sobre este assunto com o objetio de permitir: (i) a troca de informações entre programas criados independentemente e outros programas (incluindo este) e (ii) a utilização mútua das informações trocadas, deem entrar em contato com: Gerência de Relações Comerciais e Industriais da IBM Brasil A. Pasteur, 138-146, Botafogo Rio de Janeiro, RJ CEP: 22290-240 Tais informações podem estar disponíeis, sujeitas a termos e condições apropriadas, incluindo em alguns casos o pagamento de uma taxa. O programa licenciado descrito neste documento e todo o material licenciado disponíel são fornecidos pela IBM sob os termos do Contrato com o Cliente IBM, do Contrato de Licença do Programa Internacional IBM ou de qualquer outro contrato equialente. Quaisquer dados de desempenho contidos neste documento foram determinados em um ambiente controlado. Portanto, os resultados obtidos em outros ambientes operacionais podem ariar significatiamente. Algumas medidas podem ter sido feitas nos sistemas a níel de desenolimento e não há garantias de que estas medidas serão as mesmas nos sistemas geralmente disponíeis. Além disso, algumas medidas podem ter sido estimadas por extrapolação. Os resultados reais podem ariar. Os usuários deste documento deem erificar os dados aplicáeis para seu ambiente específico. As informações relatias a produtos não-ibm foram obtidas junto aos fornecedores dos respectios produtos, de seus anúncios publicados ou de outras fontes disponíeis publicamente. A IBM não testou esses produtos e não pode confirmar a precisão de seu desempenho, compatibilidade nem qualquer outra reiindicação relacionada a produtos não-ibm. Dúidas sobre os recursos de produtos não-ibm deem ser encaminhadas diretamente a seus fornecedores. Todas as declarações relacionadas aos objetios e intenções futuras da IBM estão sujeitas a alterações ou cancelamento sem aiso préio, e representam apenas metas e objetios. Estas informações são apenas para finalidades de planejamento. As informações aqui contidas estão sujeitas a alterações antes da disponibilização dos produtos descritos. Esta publicação contém exemplos de dados e relatórios utilizados em operações diárias de negócios. Estas informações contêm exemplos de dados e relatórios utilizados nas operações diárias de negócios. Todos esses nomes são fictícios e qualquer semelhança a esses nomes e endereços utilizados por uma empresa real é mera coincidência. Se estas informações estierem sendo exibidas em cópia eletrônica, as fotografias e ilustrações coloridas podem não aparecer. Marcas As marcas a seguir são marcas ou marcas registradas da International Business Machines Corporation nos Estados Unidos e/ou em outros países: 238 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

AIX DB2 IBM IBM (logotipo) OS/390 SecureWay Tioli Tioli (logotipo) Uniersal Database WebSphere z/os zseries Microsoft e Windows são marcas da Microsoft Corporation nos Estados Unidos e/ou em outros países. UNIX é uma marca registrada do The Open Group nos Estados Unidos e em outros países. Outros nomes de empresas, produtos e seriços podem ser marcas ou marcas de seriço de terceiros. Apêndice F. Aisos 239

240 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Glossário A ação. O atributo de permissão de uma ACL (lista de controle de acesso). Consulte também lista de controle de acesso. ACL. Consulte lista de controle de acesso. ACL (lista de controle de acesso). Em segurança de computadores, uma lista associada a um objeto que identifica todas as pessoas que podem acessar o objeto e seus direitos de acesso. Por exemplo, uma lista de controle de acesso é associada a um arquio que identifica os usuários que podem acessar o arquio e os direitos do usuário a esse arquio. arquio de banco de dados de chaes. conjunto de chaes. arquio de chaes. Consulte Consulte conjunto de chaes. arquio de resposta. Um arquio que contém um conjunto de respostas predefinidas às perguntas feitas por um programa e que é utilizado em ez de digitar esses alores um por ez. arquio de roteamento. Um arquio ASCII que contém comandos que controlam a configuração das mensagens. assinatura digital. No e-commerce, dados que são anexados a uma unidade de dados ou que são uma transformação criptográfica dela e que permitem que o destinatário da unidade de dados erifique a origem e a integridade da unidade e reconheça uma possíel falsificação. atiação de função. O processo de aplicar as permissões de acesso a uma função. atribuição de função. O processo de atribuir uma função a um usuário, como o usuário possuir as permissões de acesso apropriadas para o objeto definido para essa função. autenticação. (1) Em segurança de computadores, a erificação da identidade de um usuário ou sua elegibilidade para acessar um objeto. (2) Em segurança de computadores a erificação de que uma mensagem não foi alterada ou corrompida. (3) Em segurança de computadores, um processo utilizado para erificar o usuário de um sistema de informações ou de recursos protegidos. Consulte também autenticação com multifatores, autenticação com base na rede e autenticação aumentada. autenticação aumentada. Um critério POP (protected object policy) que confia em uma hierarquia pré-configurada de níeis de autenticação e aplica um níel específico de autenticação, de acordo com o critério definido em um recurso. A POP de autenticação aumentada não força o usuário a autenticar utilizando ários níeis de autenticação para acessar qualquer recurso indicado, mas exige que o usuário autentique em um níel no mínimo igual ao exigido pelo critério que protege um recurso. autenticação básica. Um método de autenticação que exige que o usuário digite um nome de usuário e senha álidos antes de obter acesso a um recurso on-line seguro. autenticação com base na rede. Uma POP (protected object policy) que controla o acesso aos objetos com base no endereço IP (internet protocol) do usuário. Consulte também protected object policy. autenticação com multifatores. Uma POP (protected object policy) que força o usuário a efetuar autenticação utilizando dois ou mais níeis de autenticação. Por exemplo, o controle de acesso em um recurso protegido pode exigir que os usuários sejam autenticados com nome do usuário/senha e com nome do usuário/código de token. Consulte também protected object policy. autorização. (1) Em segurança de computadores, o direito concedido ao usuário para se comunicar com ou fazer uso de um sistema de computadores. (2) O processo de conceder a um usuário acesso completo ou restrito a um objeto, recurso ou função. B BA. Consulte autenticação básica. blade. Componente que oferece seriços e componentes específicos do aplicatio. C CA. Consulte autoridade de certificação. CA (autoridade de certificação). Uma organização que emite certificados. A autoridade de certificação autentica a identidade do proprietário do certificado e os seriços que o proprietário está autorizado a utilizar, emite noos certificados, renoa os certificados existentes e reoga os certificados pertencentes aos usuários que não estão mais autorizados a utilizá-los. Copyright IBM Corp. 2000, 2003 241

campos de junção. Uma conexão HTTP ou HTTPS entre um seridor WebSEAL front-end e um seridor de aplicatios da Web backend. O WebSEAL utiliza campos de junção para oferecer seriços de proteção em nome do seridor backend. CDAS. Consulte Cross Domain Authentication Serice. CDAS (cross domain authentication serice). Um seriço do WebSEAL que fornece um mecanismo de biblioteca compartilhada que permite substituir os mecanismos de autenticação padrão do WebSEAL por um processo personalizado que retorna uma identidade do Tioli Access Manager para o WebSEAL. Consulte também WebSEAL. CDMF. Consulte Cross Domain Mapping Framework. CDMF (cross domain mapping framework). Uma interface de programação que permite que um desenoledor personalize o mapeamento de identidades do usuário e o tratamento de atributos do usuário quando as funções SSO do WebSEAL e-community SSO são utilizadas. certificado. Em segurança de computadores, um documento digital que liga uma chae pública à identidade do proprietário do certificado, permitindo assim que o proprietário do certificado seja autenticado. Um certificado é emitido por um autoridade de certificação. CGI. Consulte common gateway interface. CGI (common gateway interface). Um padrão da Internet para definir scripts que transmitem informações de um seridor Web para um programa aplicatio, por meio de um pedido HTTP e ice-ersa. Um script CGI é um programa CGI graado em uma linguagem de script, como Perl. chae. Em segurança de computadores, uma seqüência de símbolos utilizados com um algoritmo criptográfico para criptografar e descriptografar dados. Consulte chae priada e chae pública. chae priada. Em segurança de computadores, uma chae conhecida somente pelo seu proprietário. Compare com chae pública. chae pública. Em segurança de computadores, uma chae que é disponibilizada para todos. Compare com chae priada. cifrado. Dados criptografados que são ilegíeis até que sejam conertidos em dados comuns (descriptografados) com uma chae. conexão. (1) Em comunicação de dados, uma associação estabelecida entre unidades funcionais para transportar informações. (2) Em TCP/IP, o caminho entre dois aplicatios de protocolo que fornece seriço de entrega de fluxo de dados confiáel. Na Internet, uma conexão se estende um aplicatio TCP em um sistema a um aplicatio TCP em outro sistema. (3) Em comunicações de sistemas, uma linha atraés da qual os dados podem ser passados entre dois sistemas ou entre um sistema e um dispositio. configuração. (1) A maneira pela qual o hardware e o software de um sistema de processamento de informações são organizados e interconectados. (2) As máquinas, dispositios e programas que formam um sistema, um subsistema ou uma rede. conjunto de chaes. Em segurança de computadores, um arquio que contém chaes públicas, chaes priadas, raízes confiáeis e certificados. Conjunto de protocolos de Internet. Um conjunto de protocolos desenolidos para serem utilizados na Internet e publicados como RFCs (Requests for Comments) atraés da IETF (Internet Engineering Task Force). controle de acesso. Em segurança de computadores, o processo de assegurar que os recursos de um sistema de computador possam ser acessados somente pelos usuários autorizados, de maneiras autorizadas. cookie. Informações que um seridor armazena em uma máquina cliente e que acessa durante as próximas sessões. Os cookies permitem que os seridores lembrem-se de informações específicas sobre os clientes. credenciais. Informações detalhadas, obtidas durante a autenticação, que descreem o usuário, quaisquer associações de grupo e outros atributos de identidade relacionados à segurança. As credenciais podem ser utilizadas para executar uma grande ariedade de seriços, como autorização, auditoria e delegação. criptografia. Em segurança de computadores, o processo de transformar dados em uma forma ininteligíel, para que os dados originais não possam ser obtidos ou possam ser obtidos somente utilizando um processo de descriptografia. criptografia RSA. Um sistema de criptografia de chae pública utilizado para criptografia e autenticação. Ele foi inentado em 1977 por Ron Riest, Adi Shamir e Leonard Adleman. A segurança do sistema depende da dificuldade de fatorar o produto de dois números primos grandes. critério. Conjunto de regras aplicadas a recursos gerenciados. D daemon. Um programa que é executado automaticamente para desempenhar funções contínuas ou periódicas em todo o sistema, como controle de 242 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

rede. Alguns daemons são atiados automaticamente para realizar suas tarefas; outros operam periodicamente. DN. Consulte nome distinto. DN (Nome Distinto). O nome que identifica com exclusiidade uma entrada em um diretório. Um nome distinto é formado de pares atributo:alor, separados por írgulas. domínio. (1) Um grupo lógico de usuários, sistemas e recursos que compartilham seriços comuns e geralmente funcionam com uma finalidade em comum. (2) A parte de uma rede de computadores na qual os recursos de processamento de dados estão sob controle comum. Consulte também nome de domínio. domínio de gerenciamento. O domínio padrão no qual o Tioli Access Manager aplica os critérios de segurança para autenticação, autorização e controle de acesso. Esse domínio é criado quando o seridor de critério é configurado. Consulte também domínio. E EAS. Consulte External Authorization Serice. escalabilidade. A capacidade de um sistema da rede em responder aos crescentes números de usuários que acessam os recursos. espaço de objeto protegido. A representação de objeto irtual dos recursos reais do sistema que é utilizada para aplicar ACLs e POPs e para autorizar o acesso do usuário. Consulte também objeto protegido e critério do objeto protegido. esquema. O conjunto de instruções, expressas em uma linguagem de definição de dados, que descreem completamente a estrutura de um banco de dados. Em um banco de dados relacional, o esquema define as tabelas, os campos em cada tabela e os relacionamentos entre campos e tabelas. esquema de diretório. Os tipos de atributos e classes de objetos álidos que podem aparecer em um diretório. Os tipos de atributos e classes de objetos definem a sintaxe dos alores de atributos, quais atributos deem estar presentes e quais podem estar presentes para o diretório. F FTP (file transfer protocol). No conjunto de protocolos de Internet, um protocolo da camada de aplicatios que utiliza seriços TCP (Transmission Control Protocol) e Telnet para transferir arquios com muitos dados entre máquinas ou hosts. G gerenciamento de segurança. A disciplina de gerenciamento que trata da capacidade de uma organização em controlar o acesso a aplicatios e dados que são críticos para seu sucesso. GSO. Consulte conexão global. GSO (conexão global). Uma solução de conexão única que permite que o usuário forneça nomes de usuário e senhas alternatios para o seridor de aplicatios da Web backend. A conexão global permite que os usuários tenham acesso aos recursos de computação que tenham autorização para utilizar por meio de um login único. Projetado para empresas grandes que consistem em ários sistemas e aplicatios dentro de ambientes de computação heterogêneos e distribuídos, o GSO elimina a necessidade de os usuários gerenciarem ários nomes de usuário e senhas. Consulte também conexão única. H host. Um computador que é conectado a uma rede (como uma rede Internet ou SNA) e fornece um ponto de acesso para aquela rede. Também, dependendo do ambiente, o host pode fornecer controle centralizado da rede. O host pode ser um cliente, um seridor ou um cliente e um seridor ao mesmo tempo. host irtual. A capacidade de um seridor da Web que permite que ele apareça como mais de um host na Internet. HTTP. Consulte Hypertext Transfer Protocol. HTTP (hypertext transfer protocol). No conjunto de protocolos da Internet, o protocolo que é utilizado para transferir e exibir documentos de hipertexto. I instalação silenciosa. Uma instalação que não enia mensagens para o console, mas, em ez disso, armazena as mensagens e os erros nos arquios de log. Além disso, uma instalação silenciosa pode utilizar arquios de resposta para entrada de dados. Consulte também arquio de resposta. IP. IPC. Consulte Internet Protocol. Consulte Comunicação Interprocessos. IPC (comunicação interprocessos). (1) O processo pelo qual os programas comunicam dados entre si e sincronizam suas atiidades. Semáforos, sinais e filas de mensagens internas são métodos comuns de comunicação entre processos. (2) Um mecanismo de um Glossário 243

sistema operacional que permite que processos se comuniquem entre si dentro do mesmo computador ou atraés de uma rede. IP (Internet protocol). No conjunto de protocolos da Internet, um protocolo sem conexão que direciona dados atraés de uma rede ou de redes interconectadas e age como um intermediário entre as camadas de protocolos mais altas e a rede física. L LDAP. Consulte Lightweight Directory Access Protocol. LDAP (lightweight directory access protocol). Um protocolo aberto que (a) utiliza o TCP/IP para fornecer acesso aos diretórios que suportam um modelo X.500 e (b) não fica sujeito aos requisitos de recursos do X.500 DAP (Directory Access Protocol) mais complexo. Os aplicatios que utilizam o LDAP (conhecidos como aplicatios habilitados para diretório) podem utilizar o diretório como um armazenamento de dados comum e para recuperar informações sobre pessoas ou seriços, como endereços de e-mail, chaes públicas ou parâmetros de configuração específicos do seriço. O LDAP foi especificado originalmente no RFC 1777. O LDAP ersão 3 está especificado no RFC 2251 e a IETF continua a trabalhar em funções padrão adicionais. Alguns dos esquemas padrão definidos pelo IETF para LDAP são encontrados no RFC 2256. ligar. Relacionar um identificador a outro objeto em um programa; por exemplo, relacionar um identificador a um alor, endereço ou outro identificador, ou associar os parâmetros formais e parâmetros reais. lista de atributos. Uma lista inculada que contém informações estendidas, utilizadas para tomar decisões sobre autorização. As listas de atributos consistem em um conjunto de pares nome = alor. LTPA. Consulte lightweight third party authentication. LTPA (lightweight third party authentication). Uma estrutura de autenticação que permite conexão única entre uma série de seridores da Web que estão dentro de um domínio de Internet. M Management Serer. critério. Obsoleto. Consulte seridor de metadados. Dados que descreem as características dos dados armazenados. migração. A instalação de uma noa ersão ou release de um programa para substituir uma ersão ou release anterior. MPA (multiplexing proxy agent). Um gateway que acomoda acesso a ários clientes. Algumas ezes, esses gateways são conhecidos como WAP (Wireless Access Protocol) quando o cliente acessa um domínio seguro utilizando o WAP. Os gateways estabelecem um único canal autenticado para o seridor de origem e criam um túnel para todos os pedidos de clientes e respostas por meio desse canal. N nome de domínio. No conjunto de protocolos da Internet, um nome de um sistema host. Um nome de domínio consiste em uma seqüência de subnomes separados por um caractere delimitador. Por exemplo, se o FQDN (Nome Completo do Domínio) de um sistema host é as400.rchland.net.ibm.com, cada item a seguir é um nome de domínio: as400.rchland.net.ibm.com, net.ibm.com, ibm.com. O objeto de contêiner. Uma designação estrutural que organiza o espaço do objeto em regiões funcionais distintas. objeto de recurso. A representação de um recurso real da rede, como um seriço, arquio e programa. objeto protegido. A representação lógica dos recursos reais do sistema que é utilizada para aplicar ACLs e POPs e para autorizar o acesso do usuário. Consulte também critério do objeto protegido e espaço do objeto protegido. P PAC. Consulte priilege attribute certificate. par de chaes. Em segurança de computadores, uma chae pública e uma chae priada. Quando o par de chaes é utilizado para criptografia, o emissor utiliza a chae pública para criptografar a mensagem e o destinatário utiliza a chae priada para descriptografar a mensagem. Quando o par de chaes é utilizado para assinatura, o signatário utiliza a chae priada para criptografar uma representação da mensagem e o destinatário utiliza a chae pública para descriptografar a representação da mensagem para erificação de assinatura. permissão. A capacidade de acessar um objeto protegido, como um arquio ou diretório. O número e o significado das permissões de um objeto são definidos pela ACL (lista de controle de acesso). Consulte também lista de controle de acesso. permissão de acesso. ao objeto inteiro O priilégio de acesso aplicado plug-in do seriço de autorização. Uma DLL (dynamically loadable library) ou biblioteca compartilhada que pode ser carregada pelo cliente de 244 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

tempo de execução da API de autorização do Tioli Access Manager na inicialização, a fim de executar operações que estendem uma interface de seriço dentro da API de Autorização. As interfaces de seriço disponíeis atualmente incluem Administração, Autorização Externa, Modificação de credenciais, Qualificações e interfaces de manipulação PAC. Os clientes podem desenoler esses seriços utilizando a ADK de autorização. polling. O processo pelo qual os bancos de dados são interrogados em interalos regulares para determinar se os dados precisam ser transmitidos. POP. Consulte protected object policy POP (protected object policy). Um tipo de critério de segurança que impõe condições adicionais na operação permitida pelo critério ACL para acessar um objeto protegido. É a responsabilidade do gerenciador de recurso reforçar as condições POP. Consulte também lista de controle de acesso, objeto protegido e espaço do objeto protegido. portal. Um Web site integrado que produz dinamicamente uma lista personalizada de recursos da Web, como links, conteúdo ou seriços, disponíeis para um usuário específico, com base nas permissões de acesso desse usuário. priilege attribute certificate. Um documento digital que contém uma autenticação do principal, atributos de autorização e capacidades do principal. Q qualidade de proteção. O níel de segurança dos dados, determinado por uma combinação de condições de autenticação, integridade e priacidade. qualificação. Uma estrutura de dados que contém informações externas de critério de segurança. As qualificações contêm dados de critério ou recursos que são formatados de forma que possa ser entendida por um aplicatio específico. qualificação para negócios. O atributo complementar da credencial de um usuário que descree as condições detalhadas que podem ser utilizadas nos pedidos de autorização dos recursos. R raiz confiáel. No SSL (Secure Sockets Layer), a chae pública e o nome distinto associado de uma CA (autoridade de certificação). registro. O datastore que contém informações de acesso e configuração para usuários, sistemas e software. registro automático. O processo pelo qual um usuário pode digitar os dados necessários e tornar-se um usuário registrado do Tioli Access Manager, sem a participação de um administrador. registro do usuário. Consulte registro. regra. Uma ou mais instruções lógicas que permitem que o seridor de eentos reconheça relacionamentos entre eentos (correlação de eentos) e execute respostas automatizadas como conseqüência. regra de autorização. Consulte regra. réplica. Um seridor que contém uma cópia do diretório ou diretórios de outro seridor. As réplicas fazem backup de seridores a fim de melhorar o desempenho ou os tempos de resposta e garantir a integridade dos dados. S seriço. Trabalho executado por um seridor. Um seriço pode ser um pedido simples de dados a serem eniados ou armazenados (como em seridores de arquios, seridores HTTP, seridores de e-mail e seridores finger) ou pode ser um trabalho mais complexo, como os dos seridores de impressão ou de processos. seriço de administração. Um plug-in de tempo de execução da API de autorização que pode ser utilizado para executar pedidos de administração em um aplicatio gerenciador de recursos do Tioli Access Manager. O seriço de administração responderá a pedidos remotos a partir do comando pdadmin para executar tarefas, como listar os objetos sob um determinado nó na árore de objetos protegida. Os clientes podem desenoler esses seriços utilizando o ADK de autorização. seriço de autorização externa. Um plug-in de tempo de execução da API de autorização que pode ser utilizado para tomar decisões de autorização específicas do aplicatio ou do ambiente, como parte da cadeia de decisões de autorização do Tioli Access Manager. Os clientes podem desenoler esses seriços utilizando a ADK de autorização. seriço de modificação de credenciais. Um plug-in de tempo de execução da API de autorização que pode ser utilizado para modificar a credencial de um Tioli Access Manager. Os seriços de modificação de credenciais desenolidos externamente pelos clientes são limitados à execução de operações para incluir e remoer da lista de atributos de credenciais e somente para os atributos considerados modificáeis. seriço de qualificação. Um plug-in de tempo de execução da API de autorização que pode ser utilizado para retornar qualificações de uma fonte externa para uma condição principal ou um conjunto de condições. Glossário 245

Normalmente, as qualificações são dados específicos do aplicatio, que serão consumidos pelo aplicatio gerenciador de recursos de alguma forma ou que serão incluídos nas credenciais do principal para uso posterior no processo de autorização. Os clientes podem desenoler esses seriços utilizando a ADK de autorização. seriço priilege attribute certificate. Um plug-in do cliente de tempo de execução da API de autorização que conerte um PAC de um formato predeterminado em uma credencial do Tioli Access Manager e ice-ersa. Esses seriços também podem ser utilizados para compactar ou ordenar uma credencial do Tioli Access Manager para transmissão a outros membros do domínio seguro. Os clientes podem desenoler esses seriços utilizando a ADK de autorização. Consulte também priilege attribute certificate. seridor de critérios. O seridor Tioli Access Manager que mantém as informações sobre localização de outros seridores no domínio seguro. símbolo. (1) Em uma rede local, o símbolo de autoridade passado sucessiamente de uma estação de dados para outra, para indicar a estação temporariamente no controle do meio de transmissão. Cada estação de dados tem uma oportunidade de obter e utilizar o símbolo para controlar o meio. Um símbolo é um padrão específico de bit ou mensagem que significa permissão para transmitir. (2) Em LANs (redes locais), uma seqüência de bits passados de um dispositio para outro pelo meio de transmissão. Quando o símbolo tem dados anexados a ele, ele torna-se um quadro. SSL. Consulte Secure Sockets Layer. SSL (secure sockets layer). Um protocolo de segurança que fornece priacidade de comunicação. O SSL permite que os aplicatios cliente /seridor se comuniquem de uma maneira que impeça a escuta clandestina, a iolação e a falsificação de mensagens. O SSL foi desenolido pela Netscape Communications Corp. e pela RSA Data Security, Inc. SSO. Consulte Conexão Simples. SSO (conexão única). A capacidade de um usuário efetuar logon uma ez e acessar ários aplicatios, sem precisar efetuar logon em cada aplicatio separadamente. Consulte também conexão global. sufixo. Um nome distinto que identifica a primeira entrada em uma hierarquia de diretórios contida localmente. Deido ao esquema de nomenclatura relatio utilizado no protocolo LDAP (Lightweight Directory Access Protocol), esse sufixo é aplicado a entradas alternadas dentro dessa hierarquia de diretórios. Um seridor de diretórios pode ter ários sufixos, cada um identificando uma hierarquia de diretórios contida localmente. T tempo de execução. O período de tempo durante o qual um programa de computador é executado. O Runtime Enironment é um ambiente de execução. U URI. Consulte uniform resource identifier. URI (uniform resource identifier). A cadeia de caracteres utilizada para identificar o conteúdo na Internet, incluindo o nome do recurso (um nome do arquio e do diretório), a localização do recurso (o computador onde o nome do arquio e do diretório existem) e como o recurso pode ser acessado (o protocolo, como HTTP). Um exemplo de um URI é um uniform resource locator ou URL. URL. Consulte uniform resource locator. URL (uniform resource locator). Uma seqüência de caracteres que representa recursos de informações em um computador ou em uma rede como a Internet. Essa seqüência de caracteres inclui (a) o nome abreiado do protocolo utilizado para acessar o recurso de informações e (b) as informações utilizadas pelo protocolo para localizar o recurso de informações. Por exemplo, no contexto da Internet, são nomes abreiados de alguns protocolos utilizados para acessar diersos recursos de informações: http, ftp, gopher, telnet e news. Esta é a URL da home page da IBM: http://www.ibm.com. usuário. Qualquer pessoa, organização, processo, dispositio, programa, protocolo ou sistema que utiliza um seriço fornecido por outros. W WebSEAL. Um blade do Tioli Access Manager. O WebSEAL é um seridor da Web de alto desempenho e de múltiplo thread que aplica um critério de segurança a um espaço de objetos protegidos. O WebSEAL pode fornecer soluções de conexão única e incorporar recursos do seridor de aplicatios da Web de backend em seu critério de segurança. WPM. Consulte a seção Web Portal Manager. WPM (Web Portal Manager). Um aplicatio gráfico com base na Web utilizado para gerenciar o critério de segurança do Tioli Access Manager Base e WebSEAL em um domínio seguro. Uma alternatia para a interface da linha de comando pdadmin, essa GUI permite o acesso de administradores remotos e que os administradores criem domínios de usuário delegados e atribua administradores delegados a esses domínios. 246 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Índice Remissio A add-hdr 65 ADI 179 Agentes Proxy de Multiplexação 112 allow-login-retry 166 AMWebARS configurando 184 Apache considerações 18 aplicando o HTTPS não autenticado 133 aplicatios backend mantendo o estado de sessões 173 armazenamento em cache de pedidos HTTP 37 arquitetura 1 atributos de credencial cdsso 156 atributos de credencial ecsso 167 atualização de credenciais 35 auditoria 30 autenticação 42 com a Autenticação Básica 62 com cabeçalhos HTTP 103 com cabeçalhos IV 100 com certificados 68 com cookies de failoer 84 com cookies LTPA 106 com endereços IP 104 com SPNEGO 74 com tokens 70 configuração para hosts irtuais 45 critério POP com base em rede 130 formulários 66 metas de 4 métodos 46 ordem de 46 referência rápida 217 multifatores 128 NTLM 82 parâmetros 197 progressão 125 seridor Web 83 isão geral 4 isão geral da configuração 43 isão geral de configuração 59 Autenticação Básica 55, 62 autenticação com base em failoer 84 biblioteca 86 compatibilidade com ersões anteriores 91 configuração 91 domínio inteiro 90 fazendo upgrade 91 autenticação com base em formulários 66 autenticação com base em multifatores 128 autenticação com base em seridor Web 83 autenticação com base em token 70 autenticação NTLM 82 Authorization Serer configuração 11 B backup 187 banco de dados de cache 30 C Cabeçalhos P3P 27 cabeçalhos BA codificação UTF-8 68 manipulando 63 cabeçalhos HTTP 57 autenticação 103 conexão única 136 cabeçalhos i 59 cabeçalhos IV 136 autenticação 100 codificação UTF-8 102 Cabeçalhos Platform for Priacy 27 cache definições do banco de dados 34 cache de sessão 53 cache-definitions 112 cache-refresh-interal 112 caracteres especiais 235 CDSSO 153 atiando 155 cdsso_key_gen 94 certificados 68 Chaes de Domínio ecsso 166 comandos 225 ajuda 61 alteração de senha 61 logout 61 componentes 1 comutação de usuários atiando 21 configuração 20 fluxo do processo 21 impactos 25 conexão única com o uso de SPNEGO 74 com o WebSEAL 139 com proxy 139 conceitos 135 e-community 159 entre domínios 153 formulários 144 GSO 141 SPNEGO 144 utilizando cabeçalhos HTTP 136 utilizando cookies de failoer 140 utilizando cookies LTPA 137 Windows 76 conexão única do e-community configuração 164 cookie 161 criptografando o token de garantia 163 exemplo 168 exemplo de configuração 168 Copyright IBM Corp. 2000, 2003 247

conexão única do e-community (continuação) fluxo do processo 160 recursos e requisitos 159 isão geral 159 Conexão única global - GSO 141 configuração armazenamento em cache de pedidos HTTP 37 atualização de credenciais 35 auditoria 32 autenticação 43 métodos 46 Autenticação Básica para autenticação 62 Autenticação Básica para sessões 55 autenticação com base em certificados 68 autenticação com base em seridor Web 83 autenticação NTLM 82 autenticação para hosts irtuais 45 Authorization Serer 11 banco de dados de cache 30 cabeçalhos HTTP para autenticação 103 cabeçalhos HTTP para sessões 57 cabeçalhos IV para autenticação 100 cabeçalhos i para sessões 59 cache 34 cache de sessão/credenciais 53 comutação de usuários 22 conexão única do e-community 164 cookies de failoer para autenticação 84 cookies de sessão para sessões 56 cookies LTPA para autenticação 106 de pdwebpimgr.conf 9 endereço IP para autenticação 104 endereço IP para sessões 58 específica para cada seridor 16 failoer para LDAP 26 formulários para autenticação 66 hosts irtuais 13 ID da sessão SSL para sessões 55 Kerberos 77 logs 30 logs de auditoria 30 métodos de autenticação 61 P3P 28 padrão 60 páginas de resposta de tokens 73 para Web Serers 16 parâmetros API de autorização 209 autenticação 197 específicos para um seridor Web 211 geral 193 LDAP 208 proxy 208 sessões 207 pdwebpi.conf 8 plug-in 8 pós-autorização 51 redirecionamento de login 106 seriço da API 35 SPNEGO para autenticação 74 sub-rotinas 193 tokens para autenticação 70 alor de marcação para pós-autorização 107, 111 isão geral da autenticação 59 configuração de auditoria 32 configuração de módulos 43 configurando páginas de erro 12 Cookie de failoer conexão única 140 cookies de failoer 84, 87, 89 atiar cookies para o domínio inteiro 98 configurar a duração do cookie 94 criptografando/decriptografando dados do cookie 94 cookies de sessão 56 cookies LTPA 106, 137 create-ba-hdr 67 cred-ext-attrs 111 credencial aquisição 5 criando um Cabeçalho BA 67 critério ACL 117, 119 controlando usuários não autenticados 133 endereços IP 130 logon 120 POP de autenticação com base em rede 130 POP de intensificação da autenticação 125 POP de qualidade de proteção 132 progressão 125 reautenticação 129 condições 129 criando e aplicando 129 senha 122 usuário e global 124 critério ACL padrão 119 critério de logon 120 critério de segurança 3 critério de senha 122 critério POP algoritmo 132 autenticação com base em rede 130 intensificação da autenticação - progressão 125 qualidade de proteção 132 reautenticação 129 critério POP de autenticação com base em rede 130 critério POP de qualidade de proteção 132 critérios ACL 117 D detecção de problemas Kerberos 80 SPNEGO 80 diretório de instalação 7 diretório raiz 7 doc-root 16 dynurl 176 E e-community-name 164 enable-failoer-cookie-for-domain 98 encadeamentos subordinados, configurando 11 endereços IP 58, 104 entre domínios conexão única 153 EPAC 5 erros, personalizando para o IIS 10 erros do IIS personalizando 10 248 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

estado de sessões com a Autenticação Básica 55 com cabeçalhos HTTP 57 com cabeçalhos i 59 com cookies de sessão 56 com endereços IP 58 com o ID da sessão SSL 55 gerenciando 52 manutenção 173 explicação das ramificações de hosts irtuais 15 expressões comuns 235 Extended Priilege Attribute Certificate (EPAC) 5 F failoer-cdsso 93 failoer-certificate 93 failoer-cookie-lifetime 94 failoer-cookies-keyfile 94 failoer-http-request 93 failoer para LDAP 26 failoer-password 93 failoer-token-card 93 faixas e endereços IP 130 finalizando sessões de usuário 175 fluxo do processo do plug-in 1 formulários conexão única 144 formulários de resposta HTML 67 G garantia criptografia de tokens 163 pedido e resposta 162 token 163 GSO 141 H hosts irtuais configuração da autenticação 45 configurando 13 suporte para 2 HTTPS não autenticado 133 I ID da sessão SSL 55 identificação da sessão 41 idiomas suporte para 37 ihs configuração específica 16 IHS considerações 18 iis configuração específica 16 IIS considerações 18 informação sobre decisões de autorização configurando a recuperação 183 recuperando 180 isão geral 179 iniciando o plug-in 9 iplanet, consulte Sun ONE 16 is-master-authn-serer 164 i-creds 101 i-groups 101 i-remote-address 101 i-user 101 i-user-l 101 K Kerberos 76 L LDAP atributos estendidos 107, 111 configurando o failoer 26 LDAP, parâmetros de configuração 208 libfailoerauthn shared library 93 listas de objetos 19 log-file 16 login-form 67 login-redirect 106 login-uri 67 logon forçando 133 LTPA processamento pós-autorização 106 ltpa-keyfile 106 ltpa-password 106 ltpa-stash-file 106 M master-authn-serer 165 master-http-port 165 master-https-port 165 max-session-lifetime 12 mecanismo de autenticação Autenticações Básicas 63 cabeçalho HTTP 104 certificados 69 com cabeçalhos IV 102 com endereços IP 105 comutação de usuários 23 formulários 66 tokens 73 mecanismos de autenticação 60 mensagens de erro 9 mensagens de erro HTTP 9 métodos de autenticação 61 módulos 43 referência rápida 217 módulos de autenticação referência rápida 217 motios de falha fornecendo 182 MPAs 112 N nome da região, definindo 63 Índice Remissio 249

P P3P 27 configurando 28 páginas de erro configurando 12 páginas de resposta de tokens 73 parâmetro accept 102 parâmetro acct-locked-page 12 parâmetro auditcfg 32 parâmetro auditlog 32 parâmetro branch 14 parâmetro cache-refresh-interal 34 parâmetro cert-cdas 60 parâmetro cert-ssl 59 parâmetro cleanup-interal 12 parâmetro db-file 34 parâmetro error-page 12 parâmetro generate 102 parâmetro http-request 59 parâmetro id 11, 14 parâmetro listen-flags 34 parâmetro logaudit 32 parâmetro logflush 32 parâmetro login-success 12 parâmetro logsize 32 parâmetro max-entries 53 parâmetro max-session-lifetime 12 parâmetro number-of-workers 11 parâmetro passwd-cdas 60 parâmetro passwd-ldap 59 parâmetro protocols 14 parâmetro retry-limit-reached-page 12 parâmetro timeout 12 parâmetro token-cdas 60 parâmetro unprotected-irtual-host 13 parâmetro irtual-host 13 parâmetro worker-size 11 parâmetros de autenticação do CDAS 60 parâmetros de autenticação locais 59 parando o plug-in 9 pdbackup 187 pdwebpi 228 pdwebpi.conf 8 pdwebpi_start 226 pdwebpimgr.conf 9 pdwpi-ersion 229 pdwpicfg -action config 230 pdwpicfg -action unconfig 233 permissões ACL 119 WebDAV 119 permissões de ACL 119 permissões WebDAV 119 pkmshelp 62 pkmslogout 61 pkmspasswd 62 plug-in autenticação 4 configuração 11 critério de segurança 3 diretório de instalação 7 iniciando e parando 9 mensagens de erro HTTP 9 recursos 3 suporte para macros 10 tratamento de pedidos 41 POP de intensificação da autenticação endereço IP para sessões 125 pós-autorização com alor de marcação 107, 111 redirecionamento de login 106 processamento de clientes anônimos 132 processamento pós-autorização 42, 51 processamento pré-autorização 42 processo de autenticação 43 processo de autorização 42 processo de tratamento de pedidos isão geral 41 processo de upgrade de autenticação 42 progressão 125 atiando 126 desatiando por endereço IP 131 limitações 127 publicações relacionadas xii Q query-contents 16 query-log-file 16 R rastreio 33 comandos pdadmin 33 reautenticação 129 reauth-grace-period 54 reauth-lifetime-reset 54 recuperação dinâmica da ADI 183 recursos 3 redefinição de reautenticação de sessões 54 redirecionamento após o logon 106 registro 30 registros de auditoria 31 S seriço da API 35 solicitação de autenticação fluxo do processo 51 SPNEGO 74, 144 atiando 79 conexão única 74 strip-hdr 64 sub-rotina authentication-leels 46 sub-rotina common-modules 43 sub-rotina ldap-ext-cred-tags 111 sub-rotina modules 43 sub-rotina pdweb-plugin 13 sub-rotina pdweb-plugins 16 sub-rotina proxy-if 11, 12 sub-rotina sessions 53 sub-rotinas, arquio de configuração 193 Sun ONE configuração específica 16 suporte a ários idiomas 37 suporte para macros 10 supply-password 65 supply-username 65 250 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

T tempo limite inatiidade do cache 55 tempo limite de inatiidade do cache 55 tempo limite de sessões 54 tipos de cabeçalhos especificando 103 tokens 70 tratamento de respostas 43 U URLs dinâmicos controle de acesso 176 use-utf8 166 usuários não autenticados 132 controlando com critério 133 utilitários pdwebpi 228 pdwebpi_start 226 pdwpi-ersion 229 pdwpicfg -action config 230 pdwpicfg -action unconfig 233 V alor de marcação 107, 111 f-argument 165 f-token-lifetime 165 f-url 165 isão geral processo de tratamento de pedidos 41 W WebSEAL conexão única com 139 Índice Remissio 251

252 IBM Tioli Access Manager para e-business: Plug-in para Web Serers: Guia de Integração

Impresso em Brazil S517-7933-00