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.

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 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.
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: 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:
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.
- El sujeto AllAuthenticatedUsers permite que todos los usuarios autenticados puedan acceder a los métodos protegidos. Siempre que el usuario se autentique de forme correcta puede acceder al recurso protegido.
- El sujeto AllAuthenticatedInTrustedRealms permite a todos los usuarios foráneos autenticados (aquellos que están enlazados a otros reinos) acceder a los métodos protegidos. Siempre que el usuario se autentique de forme correcta puede acceder al recurso protegido.
- El sujeto Everyone permite el acceso no restringido a un recurso protegido. Los usuarios no se han de autenticar para obtener acceso; este sujeto especial proporciona acceso a los métodos protegidos como si los recursos no fueran protegidos.

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