Autorización basada en roles

Utilice la información sobre autorizaciones para determinar si el interlocutor tiene los privilegios necesarios para solicitar un servicio.

La siguiente figura ilustra el proceso que se utiliza durante la autorización.

El acceso de recurso Web desde un cliente web lo maneja un colaborador web. El acceso de recurso EJB (Enterprise JavaBeans) desde un cliente Java, ya sea un enterprise bean ya sea un servlet, lo maneja un colaborador EJB. El colaborador EJB y el colaborador web extraen las credenciales de cliente del objeto actual de intermediario de solicitud de objetos (ORB). Las credenciales de cliente se establecen durante el proceso de autenticación como credenciales recibidas en el objeto actual ORB. El recurso y las credenciales recibidas se presentan en el gestor de acceso WSAccessManager para comprobar si al cliente se le permite el acceso al recurso solicitado.

Un colaborador web controla el acceso de los recursos web desde un cliente web. Un colaborador EJB (Enterprise JavaBeans) controla el acceso de los recursos EJB desde un cliente Java™, ya sea un enterprise bean o un servlet. El colaborador EJB y el colaborador web extraen las credenciales del cliente desde el objeto ORB (Object Request Broker) actual. Las credenciales del cliente se establecen durante el proceso de autenticación como credenciales recibidas en el objeto ORB actual. El recurso y las credenciales recibidas se presentan al gestor de acceso WSAccessManager para comprobar si se permite el acceso del cliente al recurso solicitado.

El módulo del gestor de acceso contiene dos módulos principales:
  • El módulo de permiso de recurso permite determinar los roles necesarios para un recurso determinado. Este módulo utiliza la tabla de correlación de recursos con roles que crea el tiempo de ejecución de seguridad durante el inicio de la aplicación. Para crear la tabla de correlación de recursos con roles, el tiempo de ejecución de seguridad lee el descriptor de despliegue de los enterprise beans o del módulo web (archivo ejb-jar.xml o archivo web.xml)
  • El módulo de la tabla de autorizaciones consulta una tabla de rol con usuario o grupo para determinar si se ha otorgado al cliente uno de los roles necesarios. La tabla de correlación de roles con usuarios o grupos, también conocida como tabla de autorizaciones la crea el tiempo de ejecución de seguridad durante el arranque de la aplicación.

    Para crear la tabla de autorizaciones, el tiempo de ejecución de seguridad lee el archivo de enlaces de aplicación, el archivo ibm-application-bnd.xmi o el archivo ibm-application-bnd.xml, según corresponda.

    [z/OS]La tabla de autorizaciones también puede crearse al acceder a los perfiles EJBROLE al realizar la autorización mediante Security Access Facility (por ejemplo, RACF).

    Supported configurations Supported configurations: Para los archivos de enlace y extensión de IBM®, la extensión del nombre de archivo .xmi o .xml es diferente en función de si se utiliza una aplicación o módulo previo a Java EE 5 o una aplicación o módulo Java EE 5 o posterior. Un archivo de enlace o extensión de IBM se denomina ibm-*-ext.xmi o ibm-*-bnd.xmi donde * es el tipo de archivo de extensión o enlace como app, application, ejb-jar o web. Se aplican las condiciones siguientes:
    • En el caso de una aplicación o módulo que utilice una Java EE anterior a la versión 5, la extensión del archivo debe ser .xmi.
    • En el caso de una aplicación que utilice Java EE versión 5 o posterior, la extensión del archivo debe ser .xml. Si los archivos .xmi se incluyen con la aplicación o el módulo, el producto ignora los archivos .xmi.

    No obstante, puede existir un módulo de Java EE 5 o posterior dentro de una aplicación que incluya archivos previos a Java EE 5 y que utilice la extensión de nombre de archivo .xmi.

    Los archivos ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi, y ibm-portlet-ext.xmi siguen utilizando la extensión de archivo .xmi.

    sptcfg

Utilice la información sobre autorizaciones para determinar si el interlocutor tiene el privilegio necesario para solicitar un servicio. Puede almacenar información de autorización de varias formas. Por ejemplo, con cada recurso, puede almacenar una lista de control de acceso, que contiene una lista de los usuarios y los privilegios de usuario. Otro modo de almacenar la información es asociar a cada usuario una lista de los recursos y de los privilegios correspondientes. Esta lista se denomina una lista de posibilidades.

WebSphere Application Server utiliza el modelo de autorización J2EE (Java 2 Platform, Enterprise Edition). En este modelo, la información de autorización se organiza del modo siguiente:

Durante el ensamblaje de una aplicación, el permiso para invocar métodos se otorga a uno o varios roles. Un rol es un conjunto de permisos, por ejemplo, en una aplicación de banca, los roles pueden ser cajero, supervisor, administrativo y otros puestos relacionados con el sector. El rol de cajero está asociado a los permisos para ejecutar métodos relacionados con la gestión del dinero de una cuenta como, por ejemplo, los métodos de ingresos y reintegros. El rol de cajero no tiene permiso para cerrar cuentas. Este permiso se concede al rol de supervisor. El ensamblador de aplicaciones define una lista de permisos de métodos para cada rol. Esta lista se almacena en el descriptor de despliegue de la aplicación. Con Java EE7 y posteriores, se introduce un nombre de rol especial "**". Este rol indica que el acceso se otorga cuando un usuario está autenticado.

Hay tres sujetos especiales que no están definidos en el modelo J2EE: AllAuthenticatedUsers, AllAuthenticatedInTrustedRealms y Everyone. Un sujeto especial es una entidad definida por el producto y que se define fuera del registro de usuarios. Esta entidad se utiliza para representar de forma genérica una clase de usuarios o grupos del registro.

Avoid trouble Avoid trouble: Cuando se configura WebSphere Application Server utilizando SAF, los sujetos especiales se ignoran. Estas funciones están disponibles en SAF. La definición del ID de usuario no autenticado en RACF con una propiedad RESTRICTED simula estas funciones. Si se crea un perfil EJBROLE con UACC (Universal Access) igual a READ, todos los usuarios autenticados tendrán acceso excepto el ID de usuario no autenticado.gotcha

Durante el despliegue de una aplicación, se asignan roles a los usuarios o grupos reales de usuarios. Cuando se asigna un rol a un usuario, el usuario obtiene todos los permisos de método que se otorgan a dicho rol.

[z/OS]En función del entorno, es posible que existan algunas restricciones. Por ejemplo, cuando se utiliza SAF, se realizan siempre comprobaciones en la base de datos de SAF. Si no se realiza la autenticación antes de que se inicie una comprobación de acceso para un rol determinado, se utiliza una identidad de SAF predeterminada para la comprobación. A menos que se configure un ID de usuario predeterminado válido en la propiedad com.ibm.SAF.authorization, no se otorga ningún acceso.

[AIX Solaris HP-UX Linux Windows][IBM i]No es necesario que el desplegador de aplicaciones comprenda los métodos individuales. Al asignar roles a los métodos, el ensamblador de aplicaciones simplifica el trabajo del desplegador de aplicaciones. En lugar de trabajar con un conjunto de métodos, el desplegador trabaja con los roles que representan agrupaciones semánticas de los métodos.

[z/OS]El administrador es responsable de la gestión de estos roles.

Se puede asignar a los usuarios más de un rol. Los permisos que se conceden a un usuario son la unión de los permisos concedidos a cada rol. Adicionalmente, si el mecanismo de autenticación da soporte a la agrupación de usuarios, se puede asignar roles a estos grupos. Asignar un grupo a un rol tiene el mismo efecto que asignar un usuario individual al rol.

[AIX Solaris HP-UX Linux Windows][IBM i]Un procedimiento recomendado para el despliegue es asignar grupos a los roles, en lugar de usuarios individuales, por los motivos siguientes.
  • Mejora el rendimiento durante la comprobación de autorización. Generalmente, existen menos grupos que usuarios.
  • Proporciona una mayor flexibilidad, ya que utiliza los miembros de grupos para controlar el acceso a recursos.
  • Da soporte a la adición y supresión de usuarios de los grupos fuera del entorno del producto. Esta acción es preferible a añadir y suprimir usuarios de los roles de WebSphere Application Server. Detenga y reinicie la aplicación de empresa para que las modificaciones entren en vigor. Esta acción puede dar muchos problemas en un entorno de producción.

[z/OS]Un procedimiento recomendado para el despliegue es asignar grupos a los roles, en lugar de usuarios individuales. Si utiliza enlaces en lugar de SAF EJBROLES para la autorización y necesita cambiar el valor del enlace, deberá reiniciar el servidor para elegir nuevos valores. Si utiliza SAF EJBROLES, el servidor de aplicaciones detecta automáticamente los cambios. Para obtener más información, consulte System Authorization Facility para autorización basada en roles

Durante la ejecución, WebSphere Application Server autoriza las solicitudes de entrada basándose en la información de identificación del usuario y en la correlación del usuario con los roles. Si el usuario perteneces a cualquier rol que tenga permiso para ejecutar un método, la solicitud se autorizará. Si el usuario no pertenece a ningún rol que tenga permiso, la solicitud se denegará.

El método de J2EE representa un método declarativo para la autorización, pero también reconoce que no se pueden tratar todas las situaciones de forma declarativa. Para estas situaciones, se proporcionan métodos para determinar de forma programada la información sobre roles y usuarios. Para los enterprise beans, WebSphere Application Server da soporte a los dos métodos siguientes:
  • getCallerPrincipal: este método recupera la información de identificación del usuario.
  • isCallerInRole: este método comprueba la información de identificación del usuario para un rol específico.
Para servlets, WebSphere Application Server da soporte a los métodos siguientes:
  • getRemoteUser
  • isUserInRole
  • getUserPrincipal

Estos métodos tienen la misma finalidad que los métodos de enterprise beans.

Para obtener información sobre el modelo de autorización de seguridad de J2EE, consulte el sitio web siguiente: http://java.sun.com


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_rolebased
File name: csec_rolebased.html