Segurança

As informações a seguir fornecem uma visão geral da segurança no WebSphere Application Server.

O IBM® WebSphere Application Server fornece infraestrutura de segurança e mecanismos para proteger recursos e recursos administrativos sensíveis do Java™ 2 Platform, Enterprise Edition (J2EE). Ele também trata de requisitos de segurança de ponta a ponta da empresa com relação a:
  • Autenticação
  • Controle de acesso de recurso
  • Integridade de dados
  • Confidencialidade
  • Privacidade
  • Interoperabilidade segura
A segurança do IBM WebSphere Application Server é baseada em Padrões de mercado e tem uma arquitetura aberta que garante conectividade e interoperabilidade seguras com Enterprise Information Systems (EIS) incluindo:
  • Database 2 (DB2)
  • CICS
  • [AIX Solaris HP-UX Linux Windows][z/OS]Information Management System (IMS)
  • MQ Series
  • Lotus Domino
  • IBM Directory
O WebSphere Application Server também suporta outros provedores de segurança, incluindo:
  • [z/OS]Qualquer servidor de segurança compatível com SAF (System Authorization Facility), incluindo o IBM z/OS Security Server Resource Access Control Facility (RACF)
  • Servidor Proxy Seguro Reverso Incluindo WebSEAL

[z/OS]Gerenciamento de identificação:

[z/OS]Para WebSphere Application Server Versão 7.x e liberações anteriores:

[z/OS]Para aproveitar os recursos de Segurança do SAF, os usuários devem identificar-se usando um ID de usuário baseado no z/OS. É possível utilizar os principais módulos de mapeamento para mapear uma identidade J2EE para o ID do usuário baseado em plataforma (neste caso, um ID do usuário RACF). Um mapeamento principal deve ser criado a partir do ID de usuário LDAP para o ID de usuário RACF para que as verificações SAF EJBROLE sejam realizadas. Isto significa que um módulo de login de mapeamento deve estar disponível para derivar um ID do usuário do z/OS do usuário configurado no registro LDAP. (A auditoria do SMF (utilizando SAF) pode ser utilizada para rastrear estas mudanças).

[z/OS]Novo para o WebSphere Application Server Versão 8.0 e mais recente:

[z/OS]Agora você possui duas opções para o mapeamento de identidade distribuída:
  • Usar o módulo de mapeamento JAAS para mapear a identidade J2EE para uma identidade SAF.
  • Usar o recurso de mapeamento de identidade distribuída no SAF, que requer uma determinada versão do SAF. Nenhum módulo de mapeamento JAAS deve ser configurado no WebSphere. Neste caso, os usuários se identificam usando sua identidade de usuário distribuída, por exemplo, a identidade de usuário no registro LDAP. O mapeamento é tratado pelo administrador de segurança do z/OS usando os perfis RACMAP SAF. Esta opção melhora a auditoria SMF permitindo que a identidade de usuário distribuída e a identidade SAF sejam registradas no registro de auditoria. Leia sobre o Mapeamento de Identidade Distribuída Usando SAF para obter informações adicionais.

Baseado em Padrões de Mercado

O IBM WebSphere Application Server fornece um modelo unificado, baseado em política e em permissões para proteger recursos da Web, terminais de serviço da Web e JavaBeans corporativos de acordo com as especificações J2EE. Especificamente, o WebSphere Application Server está em conformidade com a especificação do Java EE 6 e passou no Conjunto de Testes de Compatibilidade do J2EE.

A segurança do WebSphere Application Server é uma arquitetura em camadas construída em uma plataforma de sistema operacional, em uma Java virtual machine (JVM) e na segurança Java 2. Esse modelo de segurança implementa um rico conjunto de tecnologias de segurança, incluindo:
  • Modelo de segurança Java 2, que proporciona controle de acesso baseado em políticas, com baixa granularidade e baseado em permissões para recursos do sistema.
  • O protocolo de segurança CSIv2 (Common Secure Interoperability Version 2), além do protocolo de segurança SAS (Secure Authentication Services). Ambos os protocolos são suportados por liberações anteriores do WebSphere Application Server. O CSIv2 é parte integral da especificação J2EE 1.4 e é essencial para a interoperabilidade entre servidores de aplicativos de diferentes fornecedores e com serviços corporativos CORBA.
    [AIX Solaris HP-UX Linux Windows][IBM i][z/OS]Importante: SAS é suportado apenas entre servidores Versão 6.0.x e de versões anteriores que foram federados em uma célula Versão 6.1.
  • O modelo de programação JAAS (Java Authentication and Authorization Service) para aplicativos Java, servlets e enterprise beans.
  • A arquitetura J2EE Connector para conectar adaptadores de recursos que suportam acesso aos Enterprise Information Systems.

Os modelos de segurança e as interfaces padrão que suportam comunicação de soquete seguro, criptografia de mensagem e criptografia de dados são JSSE (Java Secure Socket Extension) e JCE (Java Cryptographic Extension).

Paradigma da Arquitetura Aberta

O servidor de aplicativos representa uma parte integral na estrutura de computação corporativa em várias camadas. O IBM WebSphere Application Server adota o paradigma de arquitetura aberta e fornece muitos pontos de plug-in para integrar aos componentes de software corporativo. Os pontos de plug-in são baseados nas especificações J2EE padrão sempre que aplicável.

Paradigma de arquitetura aberta

O plano de fundo sombreado em azul escuro indica o limite entre o WebSphere Application ServerVersão 9.0 e outros componentes de aplicativo de negócios.

[AIX Solaris HP-UX Linux Windows][IBM i]O WebSphere Application Server fornece Simple WebSphere Authentication Mechanism (SWAM), Lightweight Third Party Authentication (LTPA) e Kerberos como os mecanismos de autenticação. Exatamente uma implementação de registro do usuário pode ser configurada como o registro do usuário ativo do domínio de segurança WebSphere Application Server. O WebSphere Application Server fornece as seguintes implementações de registro do usuário: o S.O. local UNIX, Windows e IBM i e o Lightweight Directory Access Protocol (LDAP). Ele também fornece implementações de referência de registro do usuário baseada em arquivo e em JDBC (Java Database Connectivity). Suporta uma combinação flexível de mecanismos de autenticação e registros de usuários. O SWAM é fácil de configurar e é útil para um ambiente com um único servidor de aplicativos. É possível utilizar o SWAM em um ambiente distribuído se a asserção de identidade estiver ativada. O recurso de asserção de identidade está disponível apenas no protocolo de segurança CSIv2.
Nota: SWAM foi descontinuado na liberação anterior do WebSphere Application Server e será removido em uma liberação futura.

[AIX Solaris HP-UX Linux Windows][IBM i]O mecanismo de autenticação LTPA é projetado para segurança de todas as plataformas. Os servidores de recebimento de dados podem validar o token de segurança. Ele também suporta a configuração de um relacionamento de associação de confiança com servidores de proxy seguro reverso e SSO (Conexão Única), que é discutido posteriormente. Além da combinação de LTPA e LDAP ou interface de registro do usuário Customizada, a Versão 6.x ou superior suporta LTPA com uma interface de registro do usuário LocalOS. A nova configuração é principalmente útil para um único nó com vários servidores de aplicativos. Ela poderá funcionar em um ambiente distribuído se a implementação de registro do usuário do S.O. local for um registro do usuário centralizado, como Windows Domain Controller, ou poderá ser mantida em um estado consistente em vários nós.

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]O WebSphere Application Server suporta a arquitetura J2EE Connector e oferece a autenticação gerenciada por contêiner. Ele fornece um módulo de mapeamento de proprietário e de credencial de Java 2 Connector (J2C) padrão que mapeia todas as credenciais de usuários autenticados para uma credencial de senha para o domínio de segurança dos EIS (Enterprise Information Systems) especificado. O módulo de mapeamento é um módulo de login JAAS especial projetado de acordo com as especificações Java 2 Connector e JAAS. Outros módulos de login do mapeamento podem ser conectados.

[z/OS]

Registros de Usuários e Controle de Acesso

As informações sobre usuários e grupos residem em um registro de usuários. No WebSphere Application Server, um registro do usuário autentica um usuário e recupera informações sobre usuários e grupos para executar funções relacionadas à segurança, incluindo autenticação e autorização.

O WebSphere Application Server fornece as seguintes implementações de registro do usuário:
  • S.O. Local (com base no SAF)
  • LDAP
  • Repositórios federados

Além do S.O. Local, LDAP e registros do repositório federado, o WebSphere Application Server também fornece um plug-in para suportar qualquer registro usando o recurso de Registro Customizado (também referido como Registro de Usuário Customizado).

Quando a implementação de registro do S.O. Local do WebSphere Application Server é escolhida, ela permite integrar a funcionalidade do z/OS Security Server, como Resource Access Control Facility (RACF), usando o Security Access Facility (SAF) no ambiente WebSphere diretamente. Se você configurar um registro diferente do S.O. Local, também é possível tirar proveito dos recursos do z/OS Security Server com duas opções. É possível configurar um módulo de mapeamento JAAS conectável (seguido por um WebSphere Application Server para módulo de login JAAS fornecido pelo z/OS) nas configurações de login apropriadas do sistema. No WebSphere Application Server Versão 8.5, como alternativa, é possível usar o recurso de mapeamento de identidade distribuída.

Para obter informações adicionais, consulte Selecionando um Registro ou Repositório.

Configurações do WebSphere Application Server: Com o WebSphere Application ServerVersão 9.0 para z/OS, é possível integrar os aplicativos não z/OS existentes com recursos específicos do z/OS, como o System Authorization Facility (SAF) e o RACF. Isso permite unificar os registros para WebSphere Application Server para plataformas z/OS e não z/OS. Exemplo

Tabela 1. Configurações de Registro de Exemplo do WebSphere Application Server.

Esta tabela mostra um exemplo de configurações de registro do WebSphere Application Server

Configuração do Servidor de Aplicativos Tipo de Registro Método de Autorização Vantagem
WebSphere Application Server LDAP Ligações e provedores de segurança externos do WebSphere, como o Tivoli Access Manager Registros Compartilhados (em uma plataforma heterogênea)
WebSphere Application Server para z/OS RACF Ligações do WebSphere e EJBROLEs do RACF Acesso centralizado e capacidade de auditoria (pode incluir servidores executando a Versão 4.0)
Ambiente Misto do WebSphere Application Server LDAP ou Customizado Ligações do WebSphere, provedores de segurança externos, e EJBROLEs do RACF Registros compartilhados, acesso centralizado e capacidade de auditoria
Aqui estão algumas figuras para mostrar o que está descrito na tabela anterior.
  • Configuração de registro de rede do WebSphere Application Server Configuração de registro de rede
  • WebSphere Application Server para configuração do registro de rede do z/OS:Configuração do registro de rede do z/OS
  • Registro de rede do WebSphere Application Server com extensões de segurança z/OS registro de rede com extensões de segurança z/OS

Mecanismos de Autenticação

No WebSphere Application Server, os seguintes mecanismos de autenticação são suportados:
  • LTPA (Lightweight Third Party Authentication)

    O Lightweight Third Party Authentication gera um token de segurança para usuários autenticados, que podem ser utilizados para representar esse usuário autenticado em chamadas subseqüentes para o mesmo ou outros servidores em um domínio SSO (Conexão Única).

  • Kerberos

    O suporte de segurança para Kerberos como o mecanismo de autenticação foi incluído para esta liberação do WebSphere Application Server. Kerberos é um protocolo de autenticação de rede desenvolvido, flexível, aberto e muito seguro. O Kerberos inclui os recursos de autenticação, de autenticação mútua, de integridade da mensagem e de sigilo e delegação.

  • Simple WebSphere Authentication Mechanism (SWAM)
    O SWAM é fácil de configurar e é útil para um ambiente com um único servidor de aplicativos, mas exige uma autenticação de ID do usuário e senha para cada pedido.
    Nota: SWAM foi descontinuado na liberação anterior do WebSphere Application Server e será removido em uma liberação futura.

Protocolos de Autenticação IIOP

O protocolo de Autenticação IIOP se refere aos mecanismos usados para autenticar as solicitações de um Java Client para um WebSphere Application Server para z/OS ou entre J2EE Application Servers. O Common Secure Interoperability Versão 2 (CSIv2) é implementado no WebSphere Application Server para z/OS Versão 6.x ou mais recente e é considerado o protocolo estratégico.

[z/OS]

Segurança do WebSphere Application Server para z/OS Connector

O WebSphere Application Server suporta a arquitetura J2EE Connector e oferece a autenticação gerenciada por contêiner. Ele fornece um módulo de mapeamento de proprietário e de credencial de J2C padrão que mapeia todas as credenciais de usuários autenticados para uma credencial de senha para o domínio de segurança dos EIS (Enterprise Information Systems). Conectores específicos do z/OS também são suportados quando o sistema EIS está no mesmo domínio de segurança que o WebSphere Application Server. Nesse caso, senhas não são requeridas, porque as credenciais autenticadas utilizadas para pedidos J2EE podem ser utilizadas como credenciais de EIS.

Web Services Security

O WebSphere Application Server permite proteger os serviços da Web baseados na especificação da Versão 1.1 de Web Services Security do Organization for the Advancement of Structured Information Standards (OASIS). Esses padrões respondem à necessidade de fornecer proteção para mensagens trocadas em um ambiente de serviços da Web. A especificação define os recursos principais para proteger a integridade e a confidencialidade de uma mensagem, e fornece mecanismos para associar pedidos relacionados à segurança com a mensagem.

Associações Confiáveis

A associação de confiança permite integrar servidores de segurança de terceiros com a segurança do IBM WebSphere Application Server. Mais especificamente, um servidor proxy reverso pode agir como um servidor de autenticação de front-end enquanto o WebSphere Application Server aplica sua própria política de autorização às credenciais resultantes passadas pelo servidor proxy. O servidor proxy reverso aplica suas políticas de autenticação em cada solicitação da Web despachado para o WebSphere Application Server. Os produtos que implementam o TAI (Trust Association Interceptors) incluem:
  • IBM Tivoli Access Manager para e-business
  • WebSEAL
  • Caching Proxy
Para obter informações adicionais sobre como utilizar a associação confiável, consulte Associações Confiáveis.

Propagação de Atributo de Segurança

A propagação do atributo de segurança permite que o WebSphere Application Server transporte atributos de segurança de um servidor para outro na configuração. Os atributos de segurança incluem conteúdo de assunto autenticado e informações de contexto de segurança. O WebSphere Application Server pode obter esses atributos de segurança a partir de:
  • Um registro do usuário corporativo que consulta atributos estáticos
  • Um módulo de login customizado que pode consultar atributos estáticos ou dinâmicos
A propagação do atributo de segurança fornece serviços de propagação utilizando a serialização Java para quaisquer objetos que estejam contidos no assunto. Para obter informações adicionais sobre como utilizar a propagação de atributos de segurança, consulte Propagação de Atributo de Segurança.

Modo de Interoperabilidade de Conexão Única

No WebSphere Application Server, a opção do modo de interoperabilidade permite Conexões Únicas (SSO) entre o WebSphere Application Server versão 6.1.x ou posterior para interoperar com versões anteriores do servidor de aplicativos. Quando você seleciona essa opção, o WebSphere Application Server inclui o LtpaToken de estilo antigo na resposta, para que ele possa ser enviado a outros servidores que funcionam apenas com esse tipo de token. Esta opção se aplica apenas quando a opção de propagação do atributo de segurança de entrada da Web está ativada. Para obter informações adicionais sobre conexão única, consulte Implementando a Conexão Única para Minimizar as Autenticações do Usuário da Web

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]

Segurança para Recursos J2EE Usando Contêineres da Web e Contêineres EJB

Cada contêiner fornece dois tipos de segurança: segurança declarativa e segurança programática. Na segurança declarativa, a estrutura da segurança de um aplicativo, incluindo integridade e confidencialidade dos dados, requisitos de autenticação, funções de segurança e controle de acesso, é expressada em um formato externo ao aplicativo. Na verdade o descritor de implementação é o principal veículo da segurança declarativa na plataforma J2EE. O WebSphere Application Server mantém uma política de segurança do J2EE, incluindo informações derivadas do descritor de implementação e especificadas por implementadores e administradores em um conjunto de arquivos de descritor XML. No tempo de execução, o contêiner utiliza o critério de segurança definido nos arquivos do descritor de XML para utilizar restrições e controle de acesso a dados. Quando a segurança declarativa em si não for suficiente para expressar o modelo de segurança de um aplicativo, o código do aplicativo pode utilizar a segurança programática para tomar decisões de acesso. A API (interface de programação de aplicativos) para segurança programática consiste em dois métodos da interface EJBContext do EJB (Enterprise JavaBeans)(isCallerInRole, getCallerPrincipal) e em três métodos da interface HttpServletrequest do servlet (isUserInRole, getUserPrincipal, getRemoteUser).

[AIX Solaris HP-UX Linux Windows][z/OS]

Segurança do Java 2

O WebSphere Application Server suporta o Modelo de Segurança Java 2. Códigos do sistema, tais como o subsistema administrativo, o contêiner da Web e o contêiner EJB, estão em execução no domínio de segurança do WebSphere Application Server, que na implementação presente recebem AllPermission e podem acessar todos os recursos do sistema. O código do aplicativo em execução no domínio de segurança do aplicativo, que, por padrão, recebe permissões de acordo com especificações J2EE, pode acessar apenas um conjunto restrito de recursos do sistema. As classes de tempo de execução do WebSphere Application Server são protegidas pelo carregador de classes do WebSphere Application Server e são mantidas invisíveis para o código do aplicativo.

[AIX Solaris HP-UX Linux Windows][z/OS]

Segurança do Java 2 Platform, Enterprise Edition Connector

O WebSphere Application Server suporta a arquitetura J2EE Connector e oferece a autenticação gerenciada por contêiner. Ele fornece um módulo de mapeamento de proprietário e de credencial de J2C padrão que mapeia todas as credenciais de usuários autenticados para uma credencial de senha para o domínio de segurança dos EIS (Enterprise Information Systems).

[z/OS]Conectores específicos do z/OS também são suportados quando o sistema EIS está no mesmo domínio de segurança que o WebSphere Application Server. Nesse caso, senhas não são requeridas, porque as credenciais autenticadas utilizadas para pedidos J2EE podem ser utilizadas como credenciais de EIS.

[z/OS]Para obter informações adicionais, consulte Identidade do Encadeamento de Conexão.

[z/OS]Processo do WebSphere Application Server

Todos os processos do servidor de aplicativos, por padrão, compartilham uma configuração de segurança comum, que é definida em um documento XML de segurança de nível de célula. A configuração de segurança determina se a segurança do WebSphere Application Server é forçada, se a segurança do Java 2 é forçada, o mecanismo de autenticação e a configuração de registro do usuário, configurações de protocolo de segurança, configurações de login do JAAS e configurações de Secure Sockets Layer. Os aplicativos podem ter seus próprios requisitos de segurança exclusivos. Cada processo do servidor de aplicativos pode criar uma configuração de segurança por servidor para tratar de seus próprio requisito de segurança ou ser mapeado para um domínio de segurança do WebSphere. Nem todas as configurações de segurança podem ser modificadas no nível do servidor de aplicativos. Algumas configurações de segurança que podem ser modificadas no nível do servidor de aplicativos incluem se a segurança do aplicativo deve ser forçada, se a segurança do Java 2 deve ser forçada e as configurações de protocolo de segurança. Os domínios de segurança do WebSphere permitem mais controle sobre a configuração de segurança e podem ser mapeados para servidores individuais. Leia sobre Vários Domínios de Segurança para obter informações adicionais.

[z/OS]Para obter informações adicionais gerais, consulte Estados de Segurança com Suporte à Identidade de Encadeamento.

A configuração da segurança do subsistema administrativo sempre é determinada pelo documento de segurança no nível da célula. A configuração de segurança do contêiner da Web e do contêiner EJB é determinada pelo documento de segurança opcional por nível de servidor, que tem precedência sobre o documento de segurança no nível de célula.

A configuração de segurança no nível de célula e no nível do servidor de aplicativos é gerenciada pelo aplicativo do console administrativo baseado na Web ou pelo aplicativo de script adequado.

[z/OS]Nota: Não é possível alterar mecanismos de autenticação no nível do servidor.

Segurança da Web

Quando uma política de segurança é especificada para um recurso da Web e a segurança do IBM WebSphere Application Server é forçada, o contêiner da Web executa o controle de acesso quando o recurso é solicitado por um Web client. O contêiner da Web solicita ao Web client os dados de autenticação se nenhum estiver presente de acordo com o método de autenticação especificado, assegura que as restrições de dados sejam atendidas e determina se o usuário autenticado tem a função de segurança necessária. O WebSphere Application Server suporta os seguintes métodos de login:
  • Autenticação Básica HTTP
  • Autenticação de cliente HTTPS
  • Login baseado em formulário
  • Token Simple and Protected GSS-API Negotiation (SPNEGO)
O mapeamento de um certificado cliente para uma credencial de segurança do WebSphere Application Server usa a implementação UserRegistry para executar o mapeamento.

[AIX Solaris HP-UX Linux Windows][IBM i]No WebSphere Application Server, o registro do usuário de S.O. local não suporta a função de mapeamento.

[AIX Solaris HP-UX Linux Windows][IBM i]Quando o mecanismo de autenticação LTPA é configurado e o SSO (Conexão Única) é ativado, um cliente autenticado recebe um cookie de segurança, que pode representar o usuário no domínio de segurança especificado.

É recomendado utilizar o SSL (Secure Sockets Layer) para proteger o cookie de segurança ou as informações de Autenticação Básica da interceptação e reprodução. Quando uma associação de confiança é configurada, o WebSphere Application Server pode mapear uma identidade de usuário autenticado para credenciais de segurança baseadas na relação de confiança estabelecida com o servidor proxy reverso seguro.

Segurança da Web

Ao considerar os colaboradores de segurança da Web e os colaboradores de segurança EJB:
  1. O colaborador de segurança da Web aplica o controle de acesso com base em função usando uma implementação de gerenciador de acesso. Um gerenciador de acesso toma decisões de autorização baseadas no critério de segurança derivado do descritor de implementação. Um proprietário de usuário autenticado poderá acessar o Servlet ou o arquivo JSP solicitado se o proprietário de usuário tiver uma das funções de segurança requeridas. Os servlets e os arquivos JSP podem utilizar os métodos HttpServletRequest: isUserInRole, getUserPrincipal e getRemoteUser. Como exemplo, o console administrativo utiliza o método isUserInRole para determinar o conjunto apropriado de funcionalidade administrativa para expor a um proprietário de usuário.
  2. O colaborador de segurança EJB utiliza o controle de acesso baseado em função utilizando uma implementação do gerenciador de acesso. Um gerenciador de acesso toma decisões de autorização baseadas no critério de segurança derivado do descritor de implementação. Um usuário autenticado principal pode acessar o método EJB solicitado se tiver uma das funções de segurança requeridas. O código EJB pode utilizar os métodos EJBContext isCallerInRole e getCallerPrincipal. O código EJB também pode utilizar o modelo de programação JAAS para executar o login JAAS e os métodos WSSubject doAs e doAsPrivileged. O código no bloco doAs e doAsPrivileged PrivilegedAction é executado na identidade Subject. Caso contrário, o método EJB é executado na identidade RunAs ou na identidade do responsável pela chamada, dependendo da configuração RunAs.

Segurança EJB

Quando a segurança é ativada o contêiner EJB utiliza o controle de acesso na chamada do método EJB. A autenticação ocorre, independente se a permissão de um método está definida para o método EJB específico.

Um aplicativo cliente Java pode fornecer os dados de autenticação de diversas maneiras. Utilizando o arquivo sas.client.props, um cliente Java pode especificar se deve utilizar um ID do usuário e uma senha para autenticar ou utilizar um certificado cliente SSL para autenticar. O certificado do cliente é armazenado no arquivo de chaves ou na placa criptográfica do hardware, conforme definição do arquivo sas.client.props. O ID do usuário e senha podem ser opcionalmente definidos no arquivo sas.client.props.

Em tempo de execução, o cliente Java pode executar um login programático ou executar uma autenticação lenta.

Na autenticação tardia, quando o cliente Java está acessando um enterprise bean protegido pela primeira vez, o tempo de execução de segurança tenta obter os dados de autenticação necessários. Dependendo da definição da configuração no arquivo sas.client.props, o tempo de execução da segurança consulta os dados de autenticação nesse arquivo ou solicita ao usuário. Alternativamente, um cliente Java pode utilizar login programático. O WebSphere Application Server suporta o modelo de programação JAAS e o login JAAS (LoginContext) é a maneira recomendada de login programático. A função auxiliar login_helper request_login foi reprovada na Versão 6.x e Versão 9.0. Os clientes Java programados para o APT login_helper podem ser executados nesta versão.

O colaborador de segurança EJB utiliza o controle de acesso baseado em função utilizando uma implementação do gerenciador de acesso.

Um gerenciador de acesso toma decisões de autorização baseadas no critério de segurança derivado do descritor de implementação. Um usuário autenticado principal pode acessar o método EJB solicitado se tiver uma das funções de segurança requeridas. O código EJB pode utilizar os métodos isCallerInRole e getCallerPrincipal do EJBContext. O código EJB também pode utilizar o modelo de programação JAAS para executar o login JAAS e os métodos doAs e doAsPrivileged do WSSubject. O código no doAs e doAsPrivileged do bloco PrivilegedAction é executado sob a identidade Subject. Caso contrário, o método EJB é executado sob a identidade Executar Como ou a identidade do responsável pela chamada, dependendo da configuração de Executar Como. A especificação Executar Como do J2EE está no nível do bean corporativo. Quando a identidade Executar Como for especificada, ela será aplicada a todos os métodos bean. A extensão RunAs da IBM do nível de método introduzida na Versão 4.0 ainda é suportada nessa versão.

[z/OS]Nota: Após realizar a autorização, a identidade RunAs será utilizada para recebimento de dados. Geralmente, esta é a identidade do responsável pela chamada, mas também pode ser uma identidade delegada.

Aprovado pelos Federal Information Processing Standards

FIPS (Federal Information Processing Standards) são padrões e diretrizes emitidos pelo NIST (National Institute of Standards and Technology) para sistemas federais de computadores. Os FIPS são desenvolvidos quando existem requisitos do governo federal obrigatórios para padrões, como para segurança e interoperabilidade, porém soluções ou padrões de mercado aceitáveis não existem.

O WebSphere Application Server integra módulos criptográficos, incluindo Java Secure Socket Extension (JSSE) e Java Cryptography Extension (JCE), que foram submetidos à certificação FIPS 140-2.

[AIX Solaris HP-UX Linux Windows][IBM i][z/OS]Para obter informações adicionais, consulte Configurando Arquivos Java Secure Socket Extension do Federal Information Processing Standard.

O módulo IBMJCEFIPS suporta os seguintes conjuntos de criptografia simétricos:
  • AES (FIPS 197)
  • TripleDES (FIPS 46-3)
  • Algoritmo de Compilação de Mensagens SHA1 (FIPS 180-1)
O módulo IBMJCEFIPS suporta os seguintes algoritmos:
  • Algoritmos de Assinatura Digital DSA e RSA (FIPS 186-2)
  • ANSI X 9.31 (FIPS 186-2)
  • IBM Random Number Generator

O módulo criptográfico IBMJCEFIPS contém os algoritmos que são aprovados por FIPS, que formam um subconjunto adequado desses algoritmos nos módulos IBM JCE.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=welc_security
Nome do arquivo: welc_security.html