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:

Tabla 1. Roles administrativos que están disponibles a través de la consola administrativa y wsadmin.

En esta tabla se listan los roles administrativos que están disponibles a través de la consola administrativa y wsadmin.

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:
  • Ver la configuración de WebSphere Application Server.
  • Ver el estado actual del Application Server.
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:
  • Crear un recurso.
  • Correlacionar un servidor de aplicaciones.
  • Instalar y desinstalar una aplicación.
  • Desplegar una aplicación.
  • Asignar correlaciones de usuarios y grupos con roles para las aplicaciones.
  • Configurar los permisos de seguridad de Java 2 para las aplicaciones.
  • Personalizar las configuraciones de CSIv2 (Common Secure Interoperability Versión 2), SAS (Secure Authentication Service) y SSL (Secure Sockets Layer).
    Importante: z/SAS sólo está soportado entre servidores de la versión 6.0.x y anteriores que se hayan federado en una célula de la Versión 6.1.
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:
  • Detener e iniciar el servidor.
  • Supervisar el estado del servidor en la consola de administración.
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:
  • Modificar el ID de usuario y la contraseña del servidor.
  • Configurar mecanismos de autenticación y autorización.
  • Habilitar o inhabilitar seguridad administrativa.
    Nota: En releases anteriores de WebSphere Application Server, la opción Habilitar seguridad administrativa se conocía como Habilitar seguridad global.
  • 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 de LTPA (Lightweight Third Party Authentication) y generar claves.
  • Crear, actualizar o suprimir usuarios en la configuración de repositorios federados.
  • Crear, actualizar o suprimir grupos en la configuración de repositorios federados.
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:
  • Habilitar e inhabilitar el subsistema de auditoría de seguridad.
  • Seleccionar la implementación de fábrica de sucesos que desea utilizar con el punto de plug-in de fábrica de sucesos.
  • Seleccionar y configurar el proveedor de servicios o emisor, También que ambos se utilicen para el punto de conector del proveedor de servicios.
  • Establecer la política de auditoría que describe el comportamiento del servidor de aplicaciones en el supuesto de un error con el subsistema de auditoría de seguridad.
  • Definir qué sucesos de seguridad se van a auditar.
El rol de auditor incluye el rol de supervisor. Esto permite al auditor ver, aunque no modificar, el resto de la configuración de seguridad.
Tabla 2. Rol administrativo adicional que está disponible a través de la consola administrativa.

En esta tabla se lista un rol administrativo adicional que está disponible a través de la consola administrativa.

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:
  • Crear, actualizar o suprimir usuarios en la configuración de repositorios federados.
  • Crear, actualizar o suprimir grupos en la configuración de repositorios federados.
Tabla 3. Rol administrativo adicional que está disponible a través de wsadmin.

En esta tabla se lista un rol administrativo adicional que está disponible a través de la consola administrativa.

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.

[z/OS]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] El valor de com.ibm.security.SAF.authorization controla si se utilizan los perfiles SAF EJBROLE o los valores de la consola para controlar el acceso a los perfiles de administración, en lugar de los usuarios de consola. Cuando la propiedad com.ibm.security.SAF.authorization está establecida en true, se selecciona la autorización SAF y se utilizan los perfiles EJBROLE de SAF para controlar el acceso a los roles administrativos.
Nota: Con la autorización SAF (System Authorization Facility), se ignoran los valores en los usuarios de consola y los grupos de consola.
[z/OS] Si se utiliza la autorización de WebSphere Application Server, en lugar de la autorización SAF para restringir el acceso a los roles de Java EE (Java Platform, Enterprise Edition, automáticamente WebSphere Application Server para z/OS correlaciona la identidad del servidor que se especifica cuando se habilita seguridad administrativa en el rol administrativo. Cuando se habilita seguridad administrativa, los WebSphere Application Servers para z/OS se ejecutan con la identidad de servidor definida en la configuración del 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 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.

[AIX Solaris HP-UX Linux Windows][IBM i]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][IBM i]
  • 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
El release de la Versión 6.1 de WebSphere Application Server y los releases subsiguientes requieren:
  • 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.

Se introducen cuatro roles de seguridad:
  • CosNamingRead
  • CosNamingWrite
  • CosNamingCreate
  • CosNamingDelete
Los roles tienen los niveles de autorización de inferior a superior:
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.

[z/OS]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[z/OS]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.


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_adminconsole
File name: csec_adminconsole.html