La infraestructura por lotes del perfil 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 tres roles 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 depurar trabajos. Un batchAdmin no es necesariamente un administrador de WebSphere Application Server.
- batchSubmitter
- Un batchSubmitter tiene permiso para enviar nuevos trabajos y sólo puede realizar operaciones por lotes como, por ejemplo, detener, reiniciar o depurar 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
- Un batchMonitor tiene 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. Un batchMonitor no puede enviar sus propios trabajos, ni detener, reiniciar o depurar ningún trabajo.
Nota: Una vez habilitada la seguridad por lotes, todo método de la API JobOperator u operación REST que devuelva una lista se filtrará basándose en los roles por lotes otorgados al usuario actual. Por ejemplo, cuando un usuario con sólo permisos batchSubmitter solicita una lista de todas las instancias de trabajo, sólo se devolverán las instancias de trabajo enviadas por el usuario actual.
Procedimiento
- 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 tratarán como administradores por lotes y podrán realizar todas las operaciones por lotes en cualquier instancia de trabajo. Una vez habilitado appSecurity-2.0, se ejecutará la autorización de seguridad basada en roles por lotes y los usuarios estarán restringidos a las operaciones por lotes definidas por sus roles por lotes específicos.
- Habilite la seguridad basada en roles por lotes mediante la API JobOperator.
<featureManager>
<feature>batch-1.0</feature>
<feature>appSecurity-2.0</feature>
</featureManager>
- 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>
- 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. Este registro se utiliza en las siguientes configuraciones de seguridad basadas en roles por lotes de ejemplo.
<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>