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.

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 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.
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: 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:
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.
- O objeto AllAuthenticatedUsers permite que todos os usuários autenticados acessem os métodos protegidos. Desde que o usuário possa se autenticar com êxito, seu acesso ao recurso protegido é permitido.
- O objeto AllAuthenticatedInTrustedRealms permite que todos os usuários estrangeiros autenticados (aqueles que estão ligados a outras regiões) acessem métodos protegidos. Desde que o usuário possa se autenticar com êxito, seu acesso ao recurso protegido é permitido.
- O objeto Everyone permite acesso irrestrito a um recurso protegido. Os usuários não precisam autenticar para obter acesso; este assunto especial fornece acesso a métodos protegidos como se os recursos estivessem desprotegidos.

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.
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.
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.
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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- 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.
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.
- 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.
- 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