Autorização com Base na Função

Utilize informações de autorização para determinar se o responsável por uma chamada tem os privilégios necessários para pedir um serviço.

A figura a seguir ilustra o processo utilizado durante a autorização.

O acesso ao recurso da Web a partir de um Web client é tratado por um colaborador da Web. O acesso ao recurso do Enterprise JavaBeans (EJB) a partir de um cliente Java, seja um enterprise bean ou um servlet, é tratado por um colaborador de EJB. O colaborador de EJB e o colaborador da Web extraem as credenciais do cliente a partir do objeto object request broker (ORB) atual. As credenciais do cliente são definidas durante o processo de autenticação como credenciais recebidas no objeto ORB atual. O recurso e as credenciais recebidas são apresentadas ao gerenciador de acesso WSAccessManager para verificar se o acesso é permitido ao cliente para acessar o recurso solicitado.

Acesso de recurso da Web a partir de um Web client é tratado por um colaborador da Web. O acesso ao recurso EJB (Enterprise JavaBeans) a partir de um cliente Java™, seja um enterprise bean ou um servlet, é tratado por um colaborador de EJB. O colaborador EJB e o colaborador da Web extraem as credenciais de cliente do objeto object request broker (ORB) atual. As credenciais do cliente são definidas durante o processo de autenticação como credenciais recebidas no objeto ORB atual. O recurso e as credenciais recebidas são apresentados ao gerenciador de acesso WSAccessManager para verificar se o acesso é permitido ao cliente para acessar o recurso solicitado.

O módulo do gerenciador de acesso contém dois módulos principais:
  • O módulo de permissão de recurso ajuda a determinar as funções requeridas por um determinado recurso. Este módulo utiliza uma tabela de mapeamento de recurso para funções construída pelo tempo de execução de segurança durante a inicialização do aplicativo. Para construir a tabela de mapeamento de recursos para funções, o tempo de execução de segurança lê o descritor de implementação dos enterprise beans ou o módulo da Web (arquivo ejb-jar.xml ou arquivo web.xml)
  • O módulo da tabela de autorizações consulta uma tabela de função para usuário ou grupo para determinar se um cliente receberá uma das funções requeridas. A tabela de função para usuário ou mapeamento de grupos, também conhecida como a tabela de autorizações, é criada pelo tempo de execução de segurança durante a inicialização do aplicativo.

    Para criar a tabela de autorização, o tempo de execução de segurança lê o arquivo de ligação de aplicativos, o arquivo ibm-application-bnd.xmi ou o arquivo ibm-application-bnd.xml, conforme for apropriado.

    [z/OS]A tabela de autorizações também pode ser construída ao acessar os perfis EJBROLE no momento da autorização usando o Security Access Facility (tal como RACF).

    Configurações suportadas Configurações suportadas: Para arquivos de extensão e de ligação IBM®, a extensão do nome do arquivo .xmi ou .xml é diferente dependendo de você estar utilizando um aplicativo pré-Java EE 5 ou um módulo ou um aplicativo ou módulo Java EE 5 ou posterior. Um arquivo de extensão ou de ligação IBM é denominado ibm-*-ext.xmi ou ibm-*-bnd.xmi em que * é o tipo de arquivo de extensão ou de ligação como app, aplicativo, ejb-jar ou web. As seguintes condições se aplicam:
    • Para um aplicativo ou módulo que usa um Java EE versão anterior à versão 5, a extensão do arquivo deverá ser .xmi.
    • Para um aplicativo ou módulo que usa Java EE 5 ou posterior, a extensão do arquivo deve ser .xml. Se os arquivos .xmi forem incluídos no aplicativo ou módulo, o produto ignorará os arquivos .xmi.

    No entanto, um módulo Java EE 5 ou posterior pode existir dentro de um aplicativo que inclui arquivos pré-Java EE 5 e usa a extensão do nome do arquivo .xmi.

    Os arquivos ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, e ibm-portlet-ext.xmi continuam a usar as extensões de arquivo .xmi.

    sptcfg

Utilize informações de autorização para determinar se o responsável pela chamada tem o privilégio necessário para pedir um serviço. É possível armazenar informações de autorização de muitas maneiras. Por exemplo, com cada recurso, é possível armazenar uma lista de controle de acesso, que contém uma lista de usuários e privilégios de usuários. Outra maneira de armazenar as informações é associar uma lista de recursos e os privilégios correspondentes a cada usuário. Esta lista é chamada de lista de recursos.

O WebSphere Application Server utiliza o modelo de autorização do J2EE (Java 2 Platform, Enterprise Edition). Nesse modelo, as informações de autorização são organizadas da seguinte maneira:

Durante a montagem de um aplicativo, a permissão para chamar métodos é concedida a uma ou mais funções. Uma função é um conjunto de permissões; por exemplo, em um aplicativo bancário, as funções podem incluir caixa, supervisor, atendente e outras posições relacionadas à indústria. A função caixa de banco é associada a permissões para executar métodos relacionados ao gerenciamento de dinheiro em uma conta, como os métodos de retirada e de depósito. A função de caixa não tem permissão para fechar contas; esta permissão é concedida à função de supervisor. O assembler de aplicativos define uma lista de permissões de métodos para cada função. Esta lista é armazenada no descritor de implementação para o aplicativo. Com o Java EE7 e posterior, um nome da função especial "**" é introduzido. Essa função indica que o acesso é concedido quando um usuário é autenticado.

Três assuntos especiais não são definidos pelo modelo J2EE: AllAuthenticatedUsers, AllAuthenticatedInTrustedRealms e Everyone. Um objeto especial é a entidade definida pelo produto que é definida fora do registro do usuário. Esta entidade é utilizada genericamente para representar uma classe de usuários ou grupos no registro.

Evitar Problemas Evitar Problemas: Quando o WebSphere Application Server é configurado utilizando o SAF, os objetos especiais (AllAuthenticatedUSers e Everyone) serão ignorados. Estas funções estão disponíveis no SAF. As funções são simuladas pela definição do ID do usuário não autenticado no RACF com uma propriedade RESTRICTED. Se um perfil EJBROLE for criado com UACC (Universal Access) READ, todos os usuários autenticados terão acesso, com exceção do ID do usuário não autenticado.gotcha

Durante a implementação de um aplicativo, os usuários reais ou grupos de usuários são atribuídos às funções. Quando um usuário é atribuído a uma função, ele obtém todas as permissões de métodos que são concedidas a essa função.

[z/OS]Dependendo do seu ambiente, algumas restrições podem existir. Por exemplo, quando se utiliza SAF, as verificações são sempre em relação ao banco de dados do SAF. Se a autenticação não é feita antes de uma verificação de acesso em uma determinada função, será utilizada a identidade do SAF padrão para a verificação. A menos que um ID do usuário padrão válido tenha sido configurado na propriedade com.ibm.SAF.authorization, o acesso não será concedido.

[AIX Solaris HP-UX Linux Windows][IBM i]O implementador do aplicativo não precisa entender os métodos individuais. Atribuindo funções a métodos, o montador do aplicativo simplifica o trabalho do implementador do aplicativo. Em vez de trabalhar com um conjunto de métodos, o implementador trabalha com as funções, que representam agrupamentos semânticos dos métodos.

[z/OS]O administrador é responsável por gerenciar estas funções.

Os usuários podem ser designados a mais de uma função; as permissões concedidas ao usuário são a união das permissões concedidas a cada função. Além disso, se o mecanismo de autenticação suportar o agrupamento de usuários, estes grupos poderão ser atribuídos a funções. A atribuição de um grupo a uma função tem o mesmo efeito que atribuir cada usuário individual à função.

[AIX Solaris HP-UX Linux Windows][IBM i]A boa prática durante a implementação é designar grupos em vez de usuários individuais para funções, devido aos seguintes motivos:
  • Melhora o desempenho durante a verificação de autorização. Em geral, existem muito menos grupos que usuários.
  • Oferece maior flexibilidade pelo uso da participação em grupos para controlar o acesso a recursos.
  • Suporta a adição e exclusão de usuários de grupos fora do ambiente do produto. Esta ação é a preferida para incluir e removê-los de funções do WebSphere Application Server. Pare e reinicie o aplicativo corporativo para que estas mudanças sejam efetivadas. Esta ação pode causar muita perturbação em um ambiente de produção.

[z/OS]A boa prática durante a implementação é designar grupos em vez de usuários individuais a funções. Se você estiver utilizando ligações em vez de EJBROLES de SAF para autorização e precisar alterar o valor da ligação, será preciso reiniciar o servidor para captar novos valores. Se você estiver utilizando EJBROLES de SAF, o servidor de aplicativos detectará automaticamente as mudanças. Para obter informações adicionais, consulte System Authorization Facility para autorização baseada em funções

No tempo de execução, o WebSphere Application Server autoriza pedidos que chegam com base nas informações de identificação do usuário e no mapeamento do usuário para funções. Se o usuário pertencer a qualquer função que tenha permissão para executar um método, o pedido será autorizado. Se o usuário não pertencer a nenhuma função que tenha permissão, o pedido será negado.

A abordagem de J2EE representa uma abordagem declarativa à autorização, mas também reconhece que não é possível lidar com todas as situações de forma declarativa. Para estas situações, são fornecidos métodos para determinar as informações de usuários e funções de forma programática. Para enterprise beans, os dois métodos a seguir são suportados pelo WebSphere Application Server:
  • getCallerPrincipal: Este método recupera as informações de identificação do usuário.
  • isCallerInRole: Este método verifica as informações de identificação do usuário em relação a uma função específica.
Para servlets, os seguintes métodos são suportados peloWebSphere Application Server:
  • getRemoteUser
  • isUserInRole
  • getUserPrincipal

Estes métodos correspondem em finalidade aos métodos de enterprise bean.

Para obter informações adicionais sobre o modelo de autorização de segurança do J2EE, consulte o seguinte website: http://java.sun.com


Í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=csec_rolebased
Nome do arquivo: csec_rolebased.html