Roles administrativos y autorización de servicios de nombres
WebSphere Application Server amplía el control de acceso basado en roles de seguridad de Java™ Platform, Enterprise Edition (Java EE) para proteger los subsistemas de nombres y administrativo del producto.
Roles administrativos
Se definen varios roles de administración para proporcionar los niveles de autorización que se necesitan para realizar determinadas funciones de administración de WebSphere Application Server desde la consola administrativa o desde la interfaz de scripts de gestión del sistema denominada wsadmin. La política de autorización sólo se aplica cuando se habilita la seguridad global. La tabla siguiente describe los roles administrativos:
Rol | Descripción |
---|---|
Supervisor | Una persona o grupo que utiliza el rol de
supervisor tiene la mínima cantidad de privilegios. Un supervisor puede realizar las siguientes tareas:
|
Configurador | Una persona o grupo que utiliza el rol de configurador tiene el privilegio de
monitor con la posibilidad de cambiar la configuración de WebSphere Application Server. El configurador puede realizar todas
las tareas de configuración diarias. Por ejemplo, un configurador puede realizar las
siguientes tareas:
|
Operador | Una persona o grupo que utiliza el rol de operador tiene los privilegios de
supervisor con la posibilidad de cambiar el estado del tiempo de ejecución. Por ejemplo, un operador puede realizar las siguientes
tareas:
|
Administrador | Una persona o grupo que utiliza el rol de administrador tiene los privilegios de
operador y configurador, además de los privilegios adicionales que se otorgan
exclusivamente al rol de administrador. Por
ejemplo, un administrador puede realizar las siguientes tareas:
Nota:
Un administrador no puede correlacionar usuarios y grupos con roles de administrador Para obtener información sobre cómo asignar derechos de gestión de repositorio federado a los usuarios que tienen asignado el rol de administrador de WebSphere Application Server, consulte el tema, Correlación de usuarios y grupos a roles para asignar derechos de gestión de repositorios federados en el tema, Provisión de seguridad. |
Adminsecuritymanager | Sólo los usuarios a los que se otorga este rol pueden correlacionar usuarios con roles administrativos. Asimismo, cuando se utiliza una seguridad de administración precisa, sólo los usuarios a los que se otorga este rol pueden gestionar grupos de autorización. Para obtener más información, consulte el apartado Roles administrativos. |
Desplegador | Los usuarios a los que se otorga este rol pueden ejecutar acciones de configuración y operaciones de tiempo de ejecución en las aplicaciones. |
Auditor | Los usuarios a los que se les concede este
rol pueden ver y modificar los valores de configuración del subsistema de auditoría de
seguridad. Por ejemplo, un usuario con el rol de auditor puede realizar las tareas
siguientes:
|
Rol | Descripción |
---|---|
iscadmins | Este rol sólo está disponible para los
usuarios de la consola administrativa, no para usuarios wsadmin. Los usuarios con este rol tienen privilegios de administrador para gestionar usuarios y
grupos en repositorios federados. Por ejemplo, un
usuario del rol iscadmins puede realizar las tareas siguientes:
|
Rol | Descripción |
---|---|
Desplegador | Este rol sólo está disponible para los usuarios de wsadmin, no para usuarios de la consola administrativa. Los usuarios a los que se otorga este rol pueden ejecutar acciones de configuración y operaciones de tiempo de ejecución en las aplicaciones. |
Cuando se habilita la seguridad administrativa, se pone en ejecución el control de acceso basado en roles del subsistema administrativo. El subsistema administrativo incluye el servidor de seguridad, la consola administrativa, la herramienta de scripts de wsadmin y todos los MBeans JMX (Java Management Extensions). Cuando se habilita la seguridad administrativa, la consola administrativa y la herramienta de scripts de administración necesitan que los usuarios proporcionen los datos de autenticación necesarios. Además, la consola administrativa está diseñada de manera que las funciones de control que se muestran en las páginas se ajustan, según los roles de seguridad que tiene un usuario. Por ejemplo, un usuario que tenga sólo el rol de supervisor puede ver sólo datos que no sean sensibles a la configuración. Un usuario con el rol de operador puede cambiar el estado del sistema.
Al cambiar de registro (por ejemplo, de un repositorio federado a LDAP), asegúrese de eliminar la información que pertenece a un registro configurado anteriormente para los usuarios y grupos de la consola.
Los diálogos de personalización de seguridad de WebSphere Application
Server para z/OS preparan el subsistema administrativo para aceptar las identidades MVS
de todas las tareas iniciadas del sistema WebSphere Application Server (por ejemplo, controladores, sirvientes, etc.) como administradores de WebSphere y la identidad del administrador configurada.
Si se especifica un repositorio federado, un registro LDAP (Lightweight Directory Access Protocol) autónomo o
un registro personalizado autónomo, se utilizan las identidades del servidor configuradas para el trabajo
ejecutado por el sistema en lugar del trabajo ejecutado por las identidades de la tarea iniciada.
![[z/OS]](../images/ngzos.gif)
![[z/OS]](../images/ngzos.gif)
- El código de tiempo de ejecución de WebSphere Application Server, que se ejecuta con la identidad del servidor, necesita autorización para algunas operaciones de tiempo de ejecución. Puede especificar la identidad y la contraseña del servidor explícitamente o la identidad puede generarse automáticamente. En el primer caso, la identidad del servidor es un usuario válido del registro. En el segundo caso, utilice la característica internalServerId para generar una identidad del servidor automáticamente. El panel de configuración de cada registro de usuario le permite elegir esta opción. Para un internalServerId, especifique el ID de administrador o adminID en el campo Nombre de usuario administrativo primario. Este adminID es un usuario válido del registro y la contraseña para este ID no es necesaria y no se guarda en la configuración. Consulte "ID de servidor interno" en la siguiente sección.
- Si no se han asignado roles de administración a ningún usuario o grupo
explícito, puede iniciar la sesión en la consola administrativa o en la
herramienta de scripts de wsadmin utilizando la identidad del servidor o
adminID para realizar operaciones administrativas, así como para asignar
roles de administración a otros usuarios o grupos. Esto es posible porque
la identidad del servidor (o adminID) se asigna automáticamente al rol
adminsecuritymanager. Sólo los usuarios/grupos asociados con
adminsecuritymanager pueden gestionar la asignación de los usuarios/grupos
con todos los roles administrativos. Una vez que ha iniciado la sesión utilizando la
identidad del servidor (o adminID), la política de seguridad
administrativa le permite realizar las siguientes operaciones:
- Cambiar el ID y la contraseña de servidor
- Habilitar o inhabilitar la seguridad administrativa de WebSphere Application Server
- Aplicar la seguridad de Java 2 utilizando la opción Utilizar la seguridad de Java 2 para restringir a las aplicaciones el acceso a los recursos locales.
- Cambiar la contraseña LTPA o generar claves
- Cuando se habilita la seguridad administrativa para su uso administrativo, no es necesaria ninguna configuración especial para habilitar la identidad del servidor como se ha especificado, ya que la identidad del servidor se correlaciona automáticamente con el rol del administrador. Puede añadir o suprimir usuarios y grupos en los roles de administración desde la consola administrativa de WebSphere Application Server. No obstante, debe reiniciar el servidor para que los cambios entren en vigor. Un método recomendado es correlacionar un grupo, en lugar de usuarios específicos, con los roles de administración ya que este enfoque resulta más fácil y flexible de administrar. Al correlacionar un grupo con un rol de administración, los usuarios se añaden o suprimen del grupo fuera de WebSphere Application Server, y no es necesario reiniciar el servidor para que el cambio entre en vigor.
Cuando se habilita la
seguridad administrativa, los servidores
WebSphere Application Server se ejecutan con la identidad de servidor
definida en la configuración de registro de usuarios activo. Aunque no se muestra en la consola administrativa ni en otras herramientas, se
correlaciona un sujeto especial Server con el rol del administrador. El
código de tiempo de ejecución de WebSphere Application Server, que se
ejecuta con la identidad del servidor, necesita autorización para las
operaciones de tiempo de ejecución. Si
no se han asignado roles de administración a ningún otro usuario, puede iniciar la
sesión en la consola administrativa o en la herramienta de scripts de wsadmin
utilizando la identidad del servidor para realizar operaciones administrativas, así
como para asignar roles de administración a otros usuarios o grupos. Como la identidad del servidor se asigna por
omisión al rol de administración, la política de seguridad de administración necesita el rol
de administración para ejecutar las siguientes operaciones:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Cambiar el ID y la contraseña de servidor
- Habilitar o inhabilitar la seguridad administrativa de WebSphere Application Server
- Aplicar la seguridad de Java 2 utilizando la opción Utilizar la seguridad de Java 2 para restringir a las aplicaciones el acceso a los recursos locales.
- Cambiar la contraseña LTPA o generar claves
- Asignar roles administrativos a usuarios y grupos
- Un usuario administrativo, con una identidad de usuario del servidor distinta, para mejorar las funciones de auditoría de las acciones administrativas. El nombre de usuario especifica un usuario con privilegios administrativos definido en el sistema operativo local.
- Distinguir la identidad del servidor de la identidad de usuario administrativo para mejorar las funciones de auditoría. La identidad del usuario del servidor se utiliza para autenticar las comunicaciones de servidor a servidor.
- El ID de servidor interno permite generar automáticamente la identidad del usuario para la autenticación de servidor a servidor. La generación automática de la identidad del servidor da soporte a una mejor auditoría de las células únicamente para los nodos de la Versión 6.1 o posteriores. En la versión 6.1 de WebSphere Application Server Versión, puede guardar
el ID de servidor generador internamente porque el modelo de seguridad
WCCMM (WebSphere Common Configuration Model) contiene un código nuevo,
internalServerId. No tiene que especificar un ID de usuario y una contraseña de servidor durante la configuración de seguridad, excepto en el entorno de células combinadas. Un ID de servidor generado internamente añade un nivel adicional de
protección al entorno del servidor ya que la contraseña de servidor no
está expuesta como en el caso de releases anteriores a la versión 6.1. No
obstante, para obtener la compatibilidad con versiones anteriores, debe
especificar el ID de usuario de servidor si utiliza versiones anteriores
de WebSphere Application Server.
Cuando se habilita la seguridad, se pueden asignar roles de nombres a uno o varios usuarios y grupos. Para obtener más información, consulte Asignación de usuarios a roles de nombres. No obstante, antes de asignar los usuarios a los roles de nombres, configure el registro de usuarios activo. La validación del usuario y el grupo dependerá del registro de usuarios activo. Para obtener más información, consulte Configuración de registros de usuarios.
- Capacidad de correlacionar un sujeto especial con los roles administrativos. Un sujeto especial es una generalización de una clase de usuarios determinada. Los sujetos especiales AllAuthenticated o AllAuhenticatedInTrustedRealms (cuando está implicado el reino cruzado) implican que la comprobación de accesos del rol administrativo garantiza que el usuario que realiza la solicitud está al menos autenticado. El sujeto especial Everyone indica que cualquiera, autenticado o no, puede realizar la acción como si la seguridad no estuviera habilitada.
Autorización de servicios de nombres
La seguridad CosNaming ofrece una mayor granularidad del control de seguridad sobre las funciones CosNaming. Las funciones CosNaming están disponibles en los servidores CosNaming como, por ejemplo, WebSphere Application Server. Estas funciones afectan el contenido del espacio de nombres de WebSphere Application Server. Generalmente, hay dos formas en las que los programas de cliente dan como resultado llamadas CosNaming. La primera es mediante la llamada de JNDI (Java Naming and Directory Interface). La segunda es con clientes CORBA (Common Object Request Broker Architecture) que invocan métodos CosNaming directamente.
- CosNamingRead
- CosNamingWrite
- CosNamingCreate
- CosNamingDelete
- CosNamingRead
- Se puede consultar el espacio de nombres de WebSphere Application Server utilizando, por ejemplo, el método de búsqueda JNDI. El sujeto especial Everyone es la política por omisión para este rol.
- CosNamingWrite
- Se pueden realizar operaciones de escritura como, por ejemplo, de enlace, reenlace o fin de enlace de JNDI, y operaciones de CosNamingRead. Como política por omisión,los sujetos no se asignan a este rol.
- CosNamingCreate
- Se pueden crear nuevos objetos en el espacio de nombres, mediante operaciones como createSubcontext y CosNamingWrite de JNDI. Como política por omisión,los sujetos no se asignan a este rol.
- CosNamingDelete
- Se pueden destruir objetos en el mismo espacio de nombres, por ejemplo, utilizando el método destroySubcontext y las operaciones CosNamingCreate de JNDI. Como política por omisión, no se asigna este rol a los sujetos.
Cuando se configura un registro del sistema operativo local con WebSphere Application Server para z/OS, se
deben considerar otros factores.
Consulte Selección de un registro o repositorio y Configuración de registros del sistema operativo local para obtener más
información.
Si especifica repositorios federados, un registro LDAP autónomo o un registro personalizado autónomo, debe
eliminar la personalización del sistema operativo local. Para ello, suprima la identidad de administrador y
de grupo de configuración de
WebSphere Application
Server preconfigurada de los usuarios de consola y el grupo de consola.
De manera por omisión, se asigna un sujeto especial Server a los cuatro roles CosNaming. El sujeto especial Server proporciona un proceso de WebSphere Application Server, que se ejecuta con la identidad del servidor, para acceder a todas las operaciones de CosNaming. El sujeto especial Server no aparece y no se puede modificar en la consola administrativa o en otras herramientas administrativas.
Cuando se habilita la seguridad administrativa para su uso administrativo, no es necesaria ninguna configuración especial para habilitar la identidad del servidor como se ha especificado, ya que la identidad del servidor se correlaciona automáticamente con el rol del administrador.
En cualquier momento se pueden añadir o eliminar usuarios,
grupos, o los sujetos especiales AllAuthenticated y Everyone, de los roles
de nombres de la consola administrativa de WebSphere Application Server. No obstante, se necesita reiniciar el servidor para que los cambios entren en vigor.
Cuando se habilita la seguridad administrativa
para su uso administrativo, no es necesaria ninguna configuración para
habilitar la identidad del servidor (como se ha especificado), ya que la
identidad del servidor se correlaciona automáticamente con el rol del
administrador. En cualquier momento se pueden añadir o eliminar usuarios,
grupos, o los sujetos especiales AllAuthenticated y Everyone, de los roles
de nombres de la consola administrativa de WebSphere Application Server. No obstante, se necesita reiniciar el servidor para que los cambios entren en vigor. Cuando se elige la autorización SAF, no es necesario reiniciar ningún
servidor para autorizar usuarios o grupos adicionales.
Un método recomendado es correlacionar grupos o uno de los sujetos especiales, en lugar de usuarios específicos, con los roles de nombres ya que de este modo la administración resulta más fácil y flexible a largo plazo. Al correlacionar un grupo con un rol de nombres, los usuarios se añaden o suprimen del grupo fuera de WebSphere Application Server, y no es necesario reiniciar el servidor para que el cambio entre en vigor.
La política de autorización CosNaming sólo se aplica cuando se ha habilitado la seguridad administrativa. Cuando se habilita la seguridad administrativa, los intentos de realizar operaciones CosNaming sin la asignación de roles adecuada dan como resultado una excepción org.omg.CORBA.NO_PERMISSION del servidor CosNaming.
Cada función CosNaming se asigna a un solo rol. Por lo tanto, los usuarios a los que se asigna un rol CosNamingCreate no
pueden consultar el espacio de nombres a menos que también se les haya asignado CosNamingRead. Y, en la mayor parte de los casos, es necesario asignar tres roles a un creador: CosNamingRead,
CosNamingWrite y CosNamingCreate.
La asignación de los roles CosNamingRead y CosNamingWrite
para el ejemplo de creador se incluye en el rol CosNamingCreate. En la mayor parte de los
casos, los administradores de WebSphere Application Server no tienen que modificar la
asignación de roles para cada usuario o grupo cuando pasan a este release desde uno anterior.
Aunque se puede limitar mucho más el acceso al espacio de nombres cambiando la política por omisión, se pueden generar excepciones org.omg.CORBA.NO_PERMISSION imprevistas durante el tiempo de ejecución. Generalmente, las aplicaciones Java EE acceden al espacio de nombres y la identidad que utilizan es la del usuario que se autentica ante WebSphere Application Server cuando se accede a la aplicación Java EE. A menos que el proveedor de la aplicación Java EE comunique claramente los roles de nombres que se esperan, tenga cuidado cuando se modifique la política de autorización de nombres por omisión.