Seguridad de URL de portlet
WebSphere Application Server permite el acceso directo a los URL (Uniform Resource Locators) de portlet del mismo modo que a los servlets. Esta sección describe las consideraciones de seguridad que hay que tener en cuenta al acceder a los portlets mediante URL.
Por razones de seguridad, los portlets se tratan de modo parecido a los servlets. En su mayor parte, la seguridad de portlet utiliza el mecanismo subyacente de la seguridad de servlet. No obstante, la información de seguridad de portlet reside en el archivo portlet.xml, mientras que el servlet y los archivos JSP (JavaServer Pages) residen en el archivo web.xml. Asimismo, cuando se toman decisiones de acceso para los portlets, la información de seguridad (si existe) del archivo web.xml se combina con la información de seguridad del archivo portlet.xml.
La seguridad de portlet debe dar soporte a la seguridad programática, que es isUserInRole, y a la seguridad declarativa. La seguridad programática es exactamente la misma que para los servlets. No obstante, para los portlets, el método isUserInRole utiliza la información del elemento security-role-ref de portlet.xml. Los otros dos métodos utilizados por la seguridad programática, getRemoteUser y getUserPrincipal, se comportan del mismo modo que cuando acceden a un servlet. Ambos métodos devuelven la información de usuario autenticada de acceso al portlet.
- El elemento auth-constraint, que enumera los nombres de los roles que pueden acceder a los recursos, no existe en el archivo portlet.xml. El archivo portlet.xml sólo contiene el elemento user-data-constraint que indica qué tipo de seguridad de la capa de transporte (HTTP o HTTPS) es necesaria para acceder al portlet.
- La información sobre las restricciones de seguridad del archivo portlet.xml contiene el elemento portlet-collection, mientras que el archivo web.xml contiene el elemento web-resource-collection. El elemento portlet-collection sólo contiene una lista de nombres de portlet sencillos, mientras que el elemento web-resource-collection contiene los patrones de URL además de los métodos HTTP que requieren protección.
El contenedor de portlets no se ocupa directamente de la autenticación de usuario. Por ejemplo, no le solicitará que recopile la información de credenciales. En su lugar, el contenedor de portlets debe utilizar el contenedor de servlets subyacente para el mecanismo de autenticación de usuarios. Como resultado, el elemento auth-constraint no existe en la información sobre las restricciones de seguridad del archivo portlet.xml.
En WebSphere Application Server, cuando se accede a un portlet mediante un URL, la autenticación de usuario se procesa basándose en la información sobre las restricciones de seguridad para ese portlet del archivo web.xml. Esto implica que para autenticar un usuario para un portlet, el archivo web.xml debe contener la información sobre las restricciones de seguridad para ese portlet con las restricciones de autorización relevantes incluidas en ella. Si un elemento auth-constraint correspondiente para el portlet no existe en el archivo web.xml, esto indica que el portlet no es necesario para la autenticación. En este caso, se permite el acceso no autenticado como en el caso de un patrón de URL para un servlet que no contenga ninguna restricción de autorización en el archivo web.xml. Una restricción de autorización para un portlet puede especificarse utilizando directamente el nombre de portlet del elemento url-pattern o indirectamente mediante un patrón de portlet que implique al portlet.
Los siguientes ejemplos demuestran cómo la información sobre las restricciones de seguridad contenida en los archivo portlet.xml y web.xml de una aplicación de portlet se utilizan para tomar decisión de seguridad relacionadas con los portlets. El elemento security-role-ref, que se utiliza para las llamadas a isUserInRole, no se describe aquí porque se utiliza del mismo modo que los servlets.
En los ejemplos siguientes (a menos que se indique lo contrario), existen cuatro portlets (MyPortlet1, MyPortlet2, MyPortlet3, MyPortlet4) definidos en portlet.xml. Los portlets se protegen combinando la información (si existe) del archivo web.xml cuando se accede a ellos directamente a través de los URL.
Todos los ejemplos muestran el contenido de los archivos web.xml y portlet.xml. Utilice las herramientas correctas al crear estos archivos de descriptor de despliegue del mismo modo que lo haría al ensamblar una aplicación de portlet.
Ejemplo 1: el archivo web.xml no contiene ningún dato sobre las restricciones de seguridad
<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>
En este ejemplo, cuando se acceda a cualquier elemento por debajo de MyPortlet1 y MyPortlet3, y se accede a estos mediante el protocolo HTTP no seguro, se le redirigirá a través del protocolo HTTPS seguro. La garantía de transporte está establecida para utilizar conexiones seguras. Para MyPortlet2 y MyPortlet4, se permite el acceso (HTTP) no seguro porque la garantía de transporte no está establecida. No existe la correspondiente información sobre restricciones de seguridad para los cuatro portlets de web.xml. Por lo tanto, se puede a acceder a todos los portlets sin ninguna autenticación de usuario ni autorización de rol. La única seguridad utilizada en esta instancia es la seguridad de la capa de transporte utilizando SSL (Secure Sockets Layer) para MyPortlet1 y MyPortlet3.
URL | Protección de transporte | Autenticación de usuario | Autorización basada en rol |
---|---|---|---|
/MyPortlet1/* | HTTPS | Ninguno | Ninguno |
/MyPortlet2/* | Ninguno | Ninguno | Ninguno |
/MyPortlet3/* | HTTPS | Ninguno | Ninguno |
/MyPortlet4/* | Ninguno | Ninguno | Ninguno |
Ejemplo 2: el archivo web.xml contiene datos sobre las restricciones de seguridad específicas de 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>Employee</role-name>
</auth-constraint>
</security-constraint>
- Como el archivo web.xml utiliza el elemento url-pattern, los nombres de portlet se han modificado ligeramente. MyPortlet1 es ahora /MyPortlet1/*, que indica que todo lo que aparezca por debajo del URL de MyPortlet1 está protegido. Esto coincide con la información del archivo portlet.xml porque el código de tiempo de ejecución de seguridad convierte el elemento portlet-name del archivo portlet.xml en el elemento url-pattern (por ejemplo, MyPortlet1 en /MyPortlet1/*), incluso para el elemento transport-guarantee.
- El elemento http-method del archivo web.xml no se utiliza en el ejemplo porque todos los métodos HTTP deben estar protegidos.
URL | Protección de transporte | Autenticación de usuario | Autorización basada en rol |
---|---|---|---|
MyPortlet1/* | HTTPS | Sí | Sí (Employee) |
MyPortlet2/* | Ninguno | Sí | Sí (Employee) |
MyPortlet3/* | HTTPS | Ninguno | Ninguno |
MyPortlet4/* | Ninguno | Ninguno | Ninguno |
Ejemplo 3: el archivo web.xml contiene datos genéricos sobre las restricciones de seguridad que afectan a todos los 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>Manager</role-name>
</auth-constraint>
</security-constraint>
En este ejemplo, /* implica que todos los recursos que no contienen las restricciones de seguridad explícitas deben estar protegidos por el rol Manager según las reglas de coincidencia de patrones URL. Como el archivo portlet.xml contiene información de restricciones de seguridad explícitas para MyPortlet1 y MyPortlet3, estos dos portlets no están protegidos por el rol Manager, sólo por el transporte HTTPS. Como el archivo portlet.xml no puede contener la información de restricción de autorización, cualquier portlet que contenga las restricciones de seguridad se representa como no protegido cuando un URL con alguna implicación (/* por ejemplo) aparezca enumerado en el archivo web.xml debido a la reglas de coincidencia de URL.
En el caso anterior, se puede acceder tanto a MyPortlet1 como MyPortlet3 sin la autenticación de usuario. No obstante, como MyPortlet2 y MyPortlet4 no tienen restricciones de seguridad en el archivo portlet.xml, se utiliza el patrón /* para hacer que estos portlets coincidan y queden protegidos por el rol Manager, que requiere la autenticación de usuario.
URL | Protección de transporte | Autenticación de usuario | Autorización basada en rol |
---|---|---|---|
MyPortlet1/* | HTTPS | Ninguno | Ninguno |
MyPortlet2/* | Ninguno | Sí | Sí (Manager) |
MyPortlet3/* | HTTPS | Ninguno | Ninguno |
MyPortlet4/* | Ninguno | Sí | Sí (Manager) |
<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>Manager</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>Manager</role-name>
</auth-constraint>
</security-constraint>
En este caso, MyPortlet1 está protegido por el rol Manager y requiere la autenticación. También se aplica la restricción de datos de CONFIDENCIAL ya que se combina la información de los archivos web.xml e portlet.xml. Como MyPortlet3 no está enumerado explícitamente en el archivo web.xml, no está protegido todavía por el rol Manager y no requiere la autenticación de usuario.
URL | Protección de transporte | Autenticación de usuario | Autorización basada en rol |
---|---|---|---|
MyPortlet1/* | HTTPS | Sí | Sí (Manager) |
MyPortlet2/* | Ninguno | Sí | Sí (Manager) |
MyPortlet3/* | HTTPS | Ninguno | Ninguno |
MyPortlet4/* | Ninguno | Sí | Sí (Manager) |