Segurança da URL do Portlet
O WebSphere Application Server permite acesso direto às URLs (Localizadores Uniformes de Recursos), exatamente como os servlets. Esta seção descreve considerações de segurança ao acessar portlets utilizando URLs.
Por motivos de segurança, os portlets são tratados de forma semelhante aos servlets. A maior parte da segurança do portlet utiliza o mecanismo de segurança de base do servlet. No entanto, as informações de segurança do portlet residem no arquivo portlet.xml, enquanto que os arquivos de servlet e JavaServer Pages residem no arquivo web.xml. Além disso, quando você toma decisões de acesso para os portlets, as informações de segurança no arquivo web.xml, se houver, serão combinadas com as informações de segurança no arquivo portlet.xml.
A segurança do portlet deve suportar a segurança programática, que é isUserInRole, e a segurança declarativa. A segurança programática é exatamente a mesma utilizada para os servlets. No entanto, para portlets, o método isUserInRole utiliza as informações do elemento security-role-ref em portlet.xml. Os outros dois métodos utilizados pela segurança programática, getRemoteUser e getUserPrincipal, comportam-se da mesma maneira usual ao acessar um servlet. Esses dois métodos retornam as informações do usuário autenticado ao acessar o portlet.
- O elemento auth-constraint, que lista os nomes das funções que podem acessar os recursos, não existe no arquivo portlet.xml. O arquivo portlet.xml contém apenas o elemento user-data-constraint, que indica o tipo de segurança da camada de transporte (HTTP ou HTTPS) requerido para acessar o portlet.
- As informações de security-constraint no arquivo portlet.xml contêm o elemento portlet-collection, enquanto que o arquivo web.xml contém o elemento web-resource-collection. O elemento portlet-collection contém apenas uma lista de nomes simples de portlet, enquanto o web-resource-collection contém os url-patterns e os métodos HTTP que precisam de proteção.
O contêiner do portlet não lida com a autenticação de usuários diretamente. Por exemplo, ele não solicita a coleta de informações de credenciais. O contêiner do portlet deve, em vez disso, utilizar o contêiner de base do servlet para o mecanismo de autenticação do usuário. Como resultado, não há elemento auth-constraint nas informações de security-constraint no arquivo portlet.xml.
No WebSphere Application Server, quando um portlet é acessado utilizando uma URL, a autenticação do usuário é processada com base nas informações de restrições de segurança para esse portlet no arquivo web.xml. Isto significa que, para autenticar um usuário para um portlet, o arquivo web.xml deve conter as informações de restrição de segurança para esse portlet com as restrições de autenticação relevantes contidas nele. Se uma restrição de autenticação correspondente para o portlet não existir no arquivo web.xml, isto indica que o portlet não precisa ter autenticação. Nesse caso, o acesso sem autenticação é permitido do mesmo jeito que uma URL padrão para um servlet que não contém nenhum auth-constraint no arquivo web.xml. É possível especificar um auth-constraint para um portlet diretamente utilizando o nome do portlet no elemento url-pattern, ou indiretamente, por um url-pattern que contenha o portlet.
Os exemplos a seguir demonstram como as informações de security-constraint contidas nos arquivos portlet.xml e web.xml em um aplicativo de portlet são utilizadas para se tomar decisões de segurança para portlets. O elemento security-role-ref, que é utilizado para chamadas isUserInRole, não é discutido aqui porque é utilizado da mesma forma para servlets.
Nos exemplos posteriores desta seção (a menos que seja observado de outra forma), há quatro portlets (MyPortlet1, MyPortlet2, MyPortlet3, MyPortlet4) definidos em portlet.xml. Os portlets serão protegidos pela combinação de informações, se houver, no arquivo web.xml ao serem acessados diretamente por meio de URLs.
Todos os exemplos mostram o conteúdo dos arquivos web.xml e portlet.xml. Utilize as ferramentas corretas ao criar esses arquivos do descritor de implementação como faria normalmente ao montar um aplicativo de portlet.
Exemplo 1: O arquivo web.xml não contém nenhum dado de security-constraint
<security-constraint>
<display-name>Secure Portlets</display-name>
<portlet-collection>
<portlet-name>MyPortlet1</portlet-name>
<portlet-name>MyPortlet3</portlet-name>
</portlet-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Nesse exemplo, quando você acessa qualquer coisa sob MyPortlet1 e MyPortlet3 e esses portlets são acessados utilizando o protocolo HTTP não seguro, você é redirecionado por meio do protocolo HTTPS seguro. O transport-guarantee é definido para utilizar conexões seguras. Para MyPortlet2 e MyPortlet4, o acesso (HTTP) não seguro é permitido porque o transport-guarantee não está definido. Não há informações correspondentes de restrição de segurança para todos os quatro portlets no arquivo web.xml. Portanto, todos os portlets podem ser acessados sem nenhuma autenticação do usuário e autorização de função. A única segurança envolvida nesta instância é a segurança de transport-layer utilizando o SSL (Secure Sockets Layer) para MyPortlet1 e MyPortlet3.
URL | Proteção de Transporte | Autenticação do Usuário | Autorização Baseada na Função |
---|---|---|---|
/MyPortlet1/* | HTTPS | Nenhuma | Nenhuma |
/MyPortlet2/* | Nenhuma | Nenhuma | Nenhuma |
/MyPortlet3/* | HTTPS | Nenhuma | Nenhuma |
/MyPortlet4/* | Nenhuma | Nenhuma | Nenhuma |
Exemplo 2: O arquivo web.xml contém dados de security-constraint específicos do portlet
<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/MyPortlet1/*</url-pattern>
<url-pattern>/MyPortlet2/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Funcionário</role-name>
</auth-constraint>
</security-constraint>
- Como o arquivo web.xml utiliza url-pattern, os nomes do portlet foram um pouco modificados. MyPortlet1 é agora /MyPortlet1/*, que indica que tudo sob a URL MyPortlet1 está protegido. Isso corresponde às informações no arquivo portlet.xml porque o código de tempo de execução de segurança converte o elemento portlet-name no arquivo portlet.xml em url-pattern (por exemplo, MyPortlet1 em /MyPortlet1/*), até mesmo para o transport-guarantee.
- O elemento http-method no arquivo web.xml não é utilizado no exemplo porque todos os métodos HTTP devem ser protegidos.
URL | Proteção de Transporte | Autenticação do Usuário | Autorização Baseada na Função |
---|---|---|---|
MyPortlet1/* | HTTPS | Sim | Sim (Funcionário) |
MyPortlet2/* | Nenhuma | Sim | Sim (Funcionário) |
MyPortlet3/* | HTTPS | Nenhuma | Nenhuma |
MyPortlet4/* | Nenhuma | Nenhuma | Nenhuma |
Exemplo 3: O arquivo web.xml contém dados do security-constraint genéricos contendo todos os portlets.
<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Gerenciador</role-name>
</auth-constraint>
</security-constraint>
Neste exemplo, /* significa que todos os recursos que não contêm suas próprias security-constraints explícitas, devem ser protegidos pela função de Gerenciador de acordo com as regras de correspondência de padrões da URL. Como o arquivo portlet.xml contém informações explícitas de restrição de segurança para MyPortlet1 e MyPortlet3, esses dois portlets não são protegidos pela função Gerenciador, apenas pelo transporte HTTPS. Como o arquivo portlet.xml não pode conter as informações de auth-constraint, nenhum portlet que contenha restrições de segurança será apresentado sem proteção quando uma URL implícita (/* por exemplo) for listada no arquivo web.xml por causa das regras de correspondência da URL.
No caso anterior, ambos MyPortlet1 e MyPortlet3 podem ser acessados sem usar autenticação. Porém, como MyPortlet2 e MyPortlet4 não têm restrições de segurança no arquivo portlet.xml, o padrão /* será utilizado para corresponder a esses portlets e serão protegidos pela função Gerenciador, que requer autenticação do usuário.
URL | Proteção de Transporte | Autenticação do Usuário | Autorização Baseada na Função |
---|---|---|---|
MyPortlet1/* | HTTPS | Nenhuma | Nenhuma |
MyPortlet2/* | Nenhuma | Sim | Sim (Gerenciador) |
MyPortlet3/* | HTTPS | Nenhuma | Nenhuma |
MyPortlet4/* | Nenhuma | Sim | Sim (Gerenciador) |
<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Gerenciador</role-name>
</auth-constraint>
</security-constraint>
<security-constraint id="SecurityConstraint_2">
<web-resource-collection id="WebResourceCollection_2">
<web-resource-name>Protection for MyPortlet1</web-resource-name>
<url-pattern>/MyPortlet1/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Gerenciador</role-name>
</auth-constraint>
</security-constraint>
Nesse caso, MyPortlet1 está protegido pela função de Gerenciador e requer autenticação. A restrição de dados de CONFIDENTIAL também é aplicada a ele porque as informações no arquivo web.xml e no arquivo portlet.xml são combinadas. Como MyPortlet3 não está explicitamente listado no arquivo web.xml, ele ainda não é protegido pela função Gerenciador e não requer autenticação do usuário.
URL | Proteção de Transporte | Autenticação do Usuário | Autorização Baseada na Função |
---|---|---|---|
MyPortlet1/* | HTTPS | Sim | Sim (Gerenciador) |
MyPortlet2/* | Nenhuma | Sim | Sim (Gerenciador) |
MyPortlet3/* | HTTPS | Nenhuma | Nenhuma |
MyPortlet4/* | Nenhuma | Sim | Sim (Gerenciador) |