Protección del entorno de proceso por lotes de Liberty

La infraestructura por lotes de Liberty permite configurar el acceso basado en roles a todas las operaciones de gestión de proceso por lotes, así como ver los metadatos y los registros asociados con los trabajos por lotes.

Antes de empezar

El contenedor de proceso por lotes define los roles de proceso por lotes. Un usuario individual puede tener más de un rol por lotes.
batchAdmin
Un batchAdmin tiene acceso no restringido a todas las operaciones por lotes. Esto incluye permiso para enviar nuevos trabajos; detener y reiniciar trabajos de cualquier usuario; ver los metadatos de los trabajos y los registros de los trabajos que envía cualquier usuario en el dominio del proceso por lotes; y purgar trabajos. Un batchAdmin no tiene por qué ser un administrador de WebSphere Application Server necesariamente.
[18.0.0.1 and later]batchGroupAdmin
[18.0.0.1 and later]Si un usuario tiene el rol batchGroupAdmin y es miembro del grupo de operaciones donde están asignados los trabajos, podrá acceder a todas las operaciones por lotes de dichos trabajos. Los usuarios con el rol batchGroupAdmin pueden parar, repetir, reiniciar y ver cualquier trabajo, pero no pueden enviar nuevos trabajos a menos que también tienen el rol batchSubmitter. Un usuario batchGroupAdmin puede ver metadatos de trabajo y registros cronológicos de trabajo, así como los trabajos de purgado que otros usuarios del mismo grupo de operaciones han enviado. Un usuario batchGroupAdmin no tiene por qué ser un administrador de WebSphere Application Server necesariamente.
batchSubmitter
Un batchSubmitter tiene permiso para enviar nuevos trabajos y sólo puede realizar operaciones por lotes como, por ejemplo, detener, reiniciar o purgar sus propios trabajos. Un batchSubmitter no puede ver ni modificar los trabajos de otro usuario. Por ejemplo, si user1 y user2 se definen como batchSubmitters, y user1 envía un trabajo, user2 no puede ver los datos de la instancia de trabajo asociados con el trabajo de user1.
batchMonitor
Los usuarios con el rol de batchMonitor tienen permisos de sólo lectura para todos los trabajos. Los usuarios con este rol pueden ver todas las instancias de trabajo y las ejecuciones, y tener acceso a todos los registros de trabajo. Los usuarios con el rol de batchMonitor no pueden enviar sus propios trabajos, o detener, reiniciar o purgar trabajos.
[18.0.0.1 and later]batchGroupMonitor
[18.0.0.1 and later]Un usuario con el rol batchGroupMonitor tiene permisos de solo lectura en todos los trabajos asociados al grupo de operaciones al que pertenece dicho usuario. Los usuarios con este rol pueden ver todas las instancias y ejecuciones de trabajo, y tienen acceso a todos los registros cronológicos de los trabajos dentro del ámbito de su grupo de operaciones. Un batchGroupMonitor no puede enviar, parar, reiniciar ni purgar trabajos.
Nota: Una vez que se ha habilitado la seguridad del proceso por lotes, el método de la API JobOperator o la operación REST que devuelve una lista se filtra basándose en los roles del proceso por lotes que se han otorgado al usuario actual. Por ejemplo, cuando un usuario con solo permisos batchSubmitter solicita una lista de todas las instancias de trabajo, solo se devuelven las instancias de trabajo enviadas por el usuario actual.

Procedimiento

  1. De forma predeterminada, la característica batch-1.0 no habilita ninguna seguridad. Los métodos JobOperator se dejan abiertos para todos los usuarios tanto si están autenticados como si no. Los métodos se dejan abiertos a efectos de desarrollo y no requieren ninguna configuración de seguridad. La característica batchManagement-1.0 habilita la API REST por lotes. La API REST siempre requiere que se autentique un usuario, aunque la característica appSecurity-2.0 no está habilitada, pero todos los usuarios se tratan como administradores de proceso por lotes y pueden realizar todas las operaciones de proceso por lotes en cualquier instancia de trabajo. Una vez habilitada appSecurity-2.0, se realiza la autorización de seguridad basada en el rol del proceso por lotes y los usuarios están restringidos a operaciones de proceso por lotes definidas por sus roles de proceso por lotes.
    1. Habilite la seguridad basada en el rol de proceso por lotes a través de la API JobOperator.
      <featureManager>
      	<feature>batch-1.0</feature>
      	<feature>appSecurity-2.0</feature>
      </featureManager>
    2. Habilite la seguridad basada en roles por lotes mediante la API REST.
      Nota: La característica batchManagement-1.0 incluye la característica batch-1.0.
      <featureManager>
      	<feature>batchManagement-1.0</feature>
      	<feature>appSecurity-2.0</feature>
      </featureManager>
  2. Configure el archivo server.xml para dar soporte a la seguridad basada en roles. En el siguiente ejemplo, se muestra un registro de usuarios básico que define una lista de usuarios. Las configuraciones de seguridad basadas en el rol de proceso por lotes de muestra utilizan este registro:
    <basicRegistry id="basic" realm="ibm/api">
    	<user name="alice" password="alicepwd" />
    	<user name="bob" password="bobpwd" />
    	<user name="jane" password="janepwd" />
    	<user name="joe" password="joepwd" />
    	<user name="phyllis" password="phyllispwd" /> 
    	<user name="kai" password="kaipwd" />
    </basicRegistry>

    En este ejemplo, un usuario ocupa varios roles.

    <authorization-roles id="com.ibm.ws.batch">
    	<security-role name="batchAdmin" >	
    		<user name="alice" />	
    	</security-role>
    	<security-role name="batchSubmitter" >
    		<user name="jane" />
    		<user name="phyllis" />
    		<user name="bob"/>
    	</security-role>
    	<security-role name="batchMonitor" >
    		<user name="joe" />
    		<user name="bob"/>
    	</security-role>
    </authorization-roles>
    En este ejemplo, un usuario ocupa varios roles. Todos los usuarios tienen el rol batchSubmitter.
    <authorization-roles id="com.ibm.ws.batch">
    	<security-role name="batchAdmin" >	
    		<user name="alice" />	
    	</security-role>
    	<security-role name="batchSubmitter" >
    		<special-subject type="ALL_AUTHENTICATED_USERS"/>
    	</security-role>
    	<security-role name="batchMonitor" >
    		<user name="joe" />
    		<user name="bob"/>
    	</security-role>
    </authorization-roles>
    En este ejemplo, un usuario ocupa varios roles. Todos los usuarios, incluidos los usuarios que no estén autenticados, están autorizados para tener el rol batchMonitor.
    <authorization-roles id="com.ibm.ws.batch">
    	<security-role name="batchAdmin" >	
    		<user name="alice" />	
    	</security-role>
    	<security-role name="batchSubmitter" >
    		<user name="joe" />
    		<user name="bob"/>
    	</security-role>
    	<security-role name="batchMonitor" >
    		<special-subject type="EVERYONE"/>
    	</security-role>
    </authorization-roles>

Icono que indica el tipo de tema Tema de tarea

Nombre de archivo: twlp_batch_securing.html