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.

La seguridad declarativa de los portlets se define mediante la información sobre las restricciones de seguridad del archivo portlet.xml. Esta información es parecida a la información sobre las restricciones de seguridad utilizadas para los servlets del archivo web.xml pero con las siguientes diferencias:
  • 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.

Atención: No puede tener un servlet o JSP con el mismo nombre que un portlet para que la seguridad de WebSphere Application Server funcione con ese 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

En el siguiente ejemplo, la información sobre las restricciones de seguridad se encuentra en portlet.xml:
      <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.

.
Tabla 1. Restricciones de seguridad aplicables a los portlets individuales. La siguiente tabla enumera las restricciones de seguridad que se aplican a los portlets individualmente.
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

En el siguiente ejemplo, la información sobre las restricciones de seguridad que se corresponde con el portlet se encuentra en web.xml. El archivo portlet.xml es el mismo que se muestra en el ejemplo anterior.
<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>
La información de restricción de seguridad contenida en el archivo web.xml de este ejemplo indica que la autenticación de usuario debe realizarse al acceder a cualquier elemento que estén por debajo de los portlets MyPortlet1 y MyPortlet2. Cuando intente acceder a estos portlets directamente utilizando los URL, y no existe información de autenticación disponible, se le solicitará que especifique las credenciales. Después de la autenticación, se realiza la comprobación de autorización para ver si aparece enumerado en el rol Employee. La correlación de usuario/grupo con roles se asigna durante el despliegue de aplicaciones de portlet. En el archivo web.xml enumerado anteriormente, tenga en cuenta lo siguiente:
  • 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.
Tabla 2. Restricciones de seguridad aplicables a los portlets individuales. La siguiente tabla enumera las nuevas restricciones de seguridad que se aplican a los portlets individualmente.
URL Protección de transporte Autenticación de usuario Autorización basada en rol
MyPortlet1/* HTTPS Sí (Employee)
MyPortlet2/* Ninguno 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.

En el ejemplo siguiente, la información sobre las restricciones de seguridad se encuentra en el archivo web.xml que se corresponde con el portlet. El archivo portlet.xml es el mismo que se muestra en el primer ejemplo.
<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.

Tabla 3. Restricciones de seguridad aplicables a los portlets individuales. La tabla siguiente enumera las nuevas restricciones de seguridad que se aplican a los puertos individuales con esta configuración.
URL Protección de transporte Autenticación de usuario Autorización basada en rol
MyPortlet1/* HTTPS Ninguno Ninguno
MyPortlet2/* Ninguno Sí (Manager)
MyPortlet3/* HTTPS Ninguno Ninguno
MyPortlet4/* Ninguno Sí (Manager)
En el ejemplo anterior, si también debe proteger un portlet contenido en el archivo portlet.xml (por ejemplo, MyPortlet1), el archivo web.xml debe contener una entrada security-constraint explicita además de /*, como se muestra en el ejemplo siguiente:
<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.

Tabla 4. Restricciones de seguridad aplicables a los portlets individuales. La siguiente tabla muestra el efecto de este cambio.
URL Protección de transporte Autenticación de usuario Autorización basada en rol
MyPortlet1/* HTTPS Sí (Manager)
MyPortlet2/* Ninguno Sí (Manager)
MyPortlet3/* HTTPS Ninguno Ninguno
MyPortlet4/* Ninguno Sí (Manager)

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_portlet_url_sec
File name: csec_portlet_url_sec.html