Seguridad administrativa de precisión
En releases anteriores de WebSphere Application Server versión 6.1, los roles administrativos otorgados por los usuarios podían administrar todos los recursos de la célula. Ahora WebSphere Application Server es mucho más preciso, lo que significa que se puede otorgar el acceso a cada usuario por recurso.
Para obtener esta seguridad basada en instancias o seguridad de precisión, los recursos que requieren los mismos privilegios se colocan en un grupo denominado grupo de autorización administrativa o grupo de autorización. Se puede otorgar a los usuarios el acceso al grupo de autorización asignándoles el rol administrativo necesario.
La seguridad administrativa de precisión también se utiliza en entornos de un único servidor. Aplicaciones distintas de un sólo servidor se pueden agrupar y colocar en diferentes grupos de autorización. Por tanto, existen distintas restricciones de autorización para las distintas aplicaciones. Tenga en cuenta que el servidor por sí mismo no puede formar parte de ningún grupo de autorización en un entorno de un solo servidor.
Puede asignar usuarios y grupos al rol adminsecuritymanager en el nivel de célula mediante scripts wsadmin y la consola administrativa. Mediante el rol adminsecuritymanager, puede asignar usuarios y grupos a los roles de usuario administrativo y grupo administrativo.
Cuando se utiliza una seguridad de administración precisa, los usuarios a los que se otorga el rol adminsecuritymanager pueden gestionar grupos de autorización. Consulte Roles administrativos y autorización de servicios de nombres para obtener una explicación detallada de todos los roles administrativos.
Un administrador no puede asignar usuarios y grupos a los roles de usuario administrativo y grupo administrativo, incluido el rol adminsecuritymanager. Consulte Roles administrativos para obtener más detalles.
- Crear un nuevo grupo de autorización:
$AdminTask createAuthorizationGroup {-authorizationGroupName authGroup1}
- Suprimir un grupo de autorización:
$AdminTask deleteAuthorizationGroup {-authorizationGroupName groupName}
- Añadir recursos a un grupo de autorización:
$AdminTask addResourceToAuthorizationGroup {-authorizationGroupName groupName -resourceName Application=app1}
- Eliminar recursos de un grupo de autorización:
$AdminTask removeResourceFromAuthorizationGroup {-authorizationGroupName groupName -resourceName Application=app1}
- Añadir los ID de usuario a los roles de un grupo de
autorización:
$AdminTask mapUsersToAdminRole {-authorizationGroupName groupName -roleName administrator -userids user1}
- Añadir los ID de grupo a los roles de un grupo de autorización:
$AdminTask mapGroupsToAdminRole {-authorizationGroupName groupName -roleName administrator -groupids group1}
- Eliminar los ID de usuario de los roles de un grupo de autorización:
AdminTask removeUsersFromAdminRole {-authorizationGroupName groupName -roleName administrator -userids user1}
- Eliminar los ID de grupo de los roles de un grupo de autorización:
$AdminTask removeGroupsFromAdminRole {-authorizationGroupName groupName -roleName administrator -groupids group1}
Recursos que pueden añadirse a un grupo de autorización
- Cell
- Nodo
- ServerCluster
- Servidor
- Application
- NodeGroup
Si un recurso no es uno de los tipos listados anteriormente, se utilizará el recurso padre.
Un recurso sólo puede pertenecer a un grupo de autorización. Sin embargo, existe una relación de contención entre los recursos. Si un recurso padre pertenece a un grupo de autorización distinto que el del recurso hijo, el recurso hijo implícitamente pertenecerá a varios grupos de autorización. No puede añadir el mismo recurso a más de un grupo de autorización.
El siguiente diagrama muestra la relación de contención entre los recursos:
- El grupo de autorización del recurso administrativo. Si a un usuario se le otorga el acceso a un grupo de autorización, se incluirán todos los recursos de dicho grupo.
- La relación de contención del recurso. Si a un usuario se le otorga el acceso a un recurso padre, se incluirán todos los recursos hijos.
La gestión de almacén de claves requiere que un usuario tenga privilegios administrativos a nivel de célula porque se crean y se gestionan a nivel de célula. El acceso de seguridad preciso a un recurso específico no permite la gestión de los almacenes de claves asociados.
Recurso | Acción | Roles necesarios |
---|---|---|
Servidor | Operaciones de tiempo de ejecución, de inicio y de detención | Operador de servidor, operador de nodo, operador de célula |
Servidor | Nueva, suprimir | Configurador de nodo, configurador de célula |
Servidor | Editar configuración | Configurador de servidor, configurador de nodo, configurador de célula |
Servidor | Ver configuración, estado de tiempo de ejecución | Supervisor de servidor, supervisor de nodo, supervisor de célula |
Nodo | Reiniciar, detener o sincronizar | Operador de nodo, operador de célula |
Nodo | Añadir, suprimir | Configurador de célula |
Nodo | Editar configuración | Configurador de nodo, configurador de célula |
Nodo | Ver configuración, estado de tiempo de ejecución | Supervisor de nodo, supervisor de célula |
Clúster | Operaciones de tiempo de ejecución, de inicio y de detención | Operador de clúster, operador de célula |
Clúster | Nueva, suprimir | Configurador de célula |
Clúster | Editar configuración | Configurador de clúster, configurador de célula |
Clúster | Ver configuración, estado de tiempo de ejecución | Supervisor de clúster, supervisor de célula |
Miembro de clúster | Operaciones de tiempo de ejecución, de inicio y de detención | Operador de servidor, operador de clúster, operador de nodo, operador de célula |
Miembro de clúster | Nueva, suprimir | Configurador de nodo, configurador de célula |
Miembro de clúster | Editar configuración | Configurador de servidor, configurador de clúster, configurador de nodo, configurador de célula |
Miembro de clúster | Ver configuración, estado de tiempo de ejecución | Supervisor de servidor, supervisor de clúster, supervisor de nodo, supervisor de célula |
Application | Todas las operaciones | Consulte la sección "Roles de desplegador" en Roles administrativos. |
Nodo, Clúster | Añadir, suprimir | Configurador de célula |
Este rol de operador de servidor es el rol de operador del grupo de autorización del que forma parte la instancia de servidor. De modo parecido, el rol de operador de nodo es el rol de operador del grupo de autorización del que forma parte la instancia de nodo.
Para utilizar la seguridad administrativa de precisión en la consola administrativa, se debe otorgar a un usuario un rol de supervisor a nivel de célula como mínimo. No obstante, para iniciar la sesión mediante wsadmin, se le debe otorgar a un usuario un rol de supervisor para cualquier grupo de autorización.
Ejemplo: uso de seguridad de alta precisión
Los escenarios siguientes describen cómo utilizar la seguridad administrativa de alta precisión, especialmente el nuevo rol de despliegue.
Escenario de rol de despliegue 1.En el escenario siguiente, hay cuatro aplicaciones configuradas en el servidor S1, como se muestra en la tabla siguiente. Cada aplicación se debe aislar de modo que el administrador de una aplicación no pueda modificar otra aplicación. Presuponga que sólo user1 puede gestionar la aplicación A1, user2 puede gestionar las aplicaciones A2 y A3 y sólo user3 puede gestionar la aplicación A4.
Un ejemplo de un ASP (Application Service Provider), en el que un único servidor de aplicaciones puede tener varias aplicaciones de proveedores. En esta instancia, el administrador del servidor es el responsable de instalar todas las aplicaciones de proveedores. Una vez instaladas las aplicaciones, cada proveedor puede gestionar su propia aplicación sin interferir con las aplicaciones de otros proveedores.
Application | Servidor | Nodo |
---|---|---|
A1 | S1 | N1 |
A2 | S1 | N1 |
A3 | S1 | N1 |
A4 | S1 | N1 |
Puede configurar los grupos de autorización como se muestra en el diagrama siguiente:

En el diagrama, la aplicación A1 está en el grupo de autorización G1, las aplicaciones A2 y A3 están en el grupo de autorización G2 y la aplicación A4 es un grupo de autorización G3.
Se asigna user1 un rol de desplegador del grupo de autorización G1, a user2 del grupo de autorización G2 y a user3 del grupo de autorización G3.
Por consiguiente, user1 puede realizar todas las operaciones en la aplicación A1, user2 en las aplicaciones A2 y A3, y user3 en la aplicación A4. Dado que todas las aplicaciones comparten el mismo servidor, no se puede poner el mismo servidor en todos los grupos de autorización. Sólo un administrador a nivel de célula puede instalar una aplicación. Una vez completada la instalación de una aplicación, el desplegador de cada aplicación puede modificar las suyas propias. Para iniciar y detener el servidor, es necesaria la autorización administrativa a nivel de célula. Este tipo de escenario resulta útil en un entorno ASP.
Escenario de rol de despliegue 2En el escenario siguiente, un grupo de aplicaciones requiere los mismos roles administrativos en un servidor. En este ejemplo, las aplicaciones A1 y A2 son aplicaciones relacionadas y las puede administrar un conjunto de administradores. Se ejecutan en el mismo servidor (S1). Las aplicaciones A3 y A4 requieren un conjunto de administradores diferente y se ejecutan en los servidores S2 y S3 respectivamente.
Aplicación | Servidor | Nodo |
---|---|---|
A1 | S1 | N1 |
A2 | S1 | N1 |
A3 | S2 | N2 |
A4 | S3 | N3 |

Cada desarrollador debe poder modificar la configuración para su servidor y debe poder instalar su aplicación en dicho servidor. También debe poder iniciar y detener el servidor al igual que la aplicación en el servidor.
Los desarrolladores también deben poder configurar el servidor, de modo que puedan depurar los problemas que se encuentren. Deben tener la posibilidad de actualizar o modificar la aplicación que se está desarrollando. El grupo de autorizaciones administrativas para este desarrollador incluye al menos un servidor y cualquier aplicación que el desarrollador instala en dicho servidor.

En el ejemplo siguiente, los desarrolladores del grupo de autorización G1 tienen una aplicación nueva (A11). Pueden instalar y destinar dicha aplicación nueva únicamente en los servidor del grupo de autorización G1. Asimismo, pueden colocar la aplicación nueva en el grupo de autorización (G1).

En este escenario, el cliente es un ASP. Tienen sus propios clientes a los que proporcionan la función de servicio de aplicaciones. Desean que los clientes puedan administrar y supervisar las aplicaciones pero que no puedan ver ni administrar las aplicaciones de clientes diferentes. No obstante, en este ejemplo, el ASP tiene administradores de personal internos cuyo trabajo es mantener los servidores.
Este administrador de personal ASP interno ha de mover una aplicación de un servidor a otro para asegurarse de que una aplicación permanece disponible. El administrador del personal ASP interno debe poder detener e iniciar los servidores y modificar su configuración.
Por el contrario, el administrador del cliente ASP no debe poder detener ni iniciar los servidores. No obstante, el administrador del cliente ASP debe poder actualizar las aplicaciones que se ejecutan en dichos servidores. El grupo de autorización administrativa para el administrador ASP interno puede ser la célula completa o puede incluir un subconjunto de servidores, nodos, clústeres y aplicaciones. El grupo de autorización administrativa para el administrador de cliente sólo incluye las aplicaciones a las que este ASP debe dar servicio y que el cliente ha pagado.
Cuando actualice el repositorio de configuración, ejecute los scripts de administración desde el gestor de despliegue para que las reglas de seguridad de administración precisa se apliquen cuando se ejecuten los scripts de administración desde el lado del gestor de despliegue.
El diagrama siguiente contiene un escenario en el que dos clientes diferentes tienen dos tipos de aplicaciones diferentes y puede gestionar sus propias aplicaciones. No obstante, los servidores y nodos en los que se ejecutan las aplicaciones se aíslan de sus clientes. Los servidores y nodos sólo los pueden mantener los administradores internos. Asimismo, los clientes no pueden destinar sus aplicaciones a un servidor diferente. Esto sólo puede realizarlo el administrador interno o los desplegadores internos.

En este escenario, el cliente es una empresa global de gran tamaño. Los nodos y los servidores de la empresa se organizan de modo que dan servicio a las aplicaciones a regiones diferentes (o alternativamente, diferentes líneas de empresa). Desean que los representantes de las diferentes áreas regionales puedan supervisar y administrar los nodos y servidores asociados a dicha región. No obstante, no desean que el administrador regional pueda afectar cualquier nodo y servidor asociado a una región diferente.
El grupo de autorización administrativa para cada representante regional incluye los nodos, servidores, clústeres y aplicaciones asociados a dicha región.
Por ejemplo, presuponga que se trata de una empresa que proporciona varios servicios como, por ejemplo, una institución financiera que proporciona servicios como, cuentas de tarjetas de crédito, cuentas de negocio, cuentas bancarias o cuentas de viaje. Cada uno de estos servicios pueden ser aplicaciones diferentes y el administrador de cada una de estas aplicaciones también debe ser diferente. La figura siguiente muestra un modo de configurar un sistema de este tipo:

La figura siguiente muestra cómo se pueden agrupar los recursos de un sistema de este tipo para aislar a los administradores entre sí:

Tenga en cuenta que los nodos no forman parte de ningún grupo de autorización. Por lo tanto, un administrador de aplicaciones de comercio no puede detener un servidor de cualquiera de los nodos y no puede detener una aplicación de viajes.
El mismo sistema se puede configurar de otro modo como se muestra a continuación:

La figura siguiente muestra cómo se pueden agrupar los recursos de un sistema de este tipo para aislar a los administradores entre sí:
