For z/OS platforms

Acceso a los recursos de seguridad de z/OS mediante WZSSAD

El WLP z/OS System Security Access Domain (WZSSAD) hace referencia a los permisos otorgados al servidor Liberty. Estos permisos controlan qué perfiles de dominios de la aplicación SAF (System Authorization Facility) y perfiles de recursos pueden consultar el servidor cuando autentica y autoriza a los usuarios.

Por ejemplo, si desea configurar dos instancias de servidor de Libertyy, una para producción y otra para prueba y desea que su acceso de rol sea distinto entre producción y prueba, puede configurar dos dominios de acceso de seguridad del sistema distintos.

El servidor de Liberty es un programa no autorizado que pueden ejecutar y configurar los usuarios que no son administradores ni tienen privilegios, por lo tanto, es importante para fines de seguridad e integridad del sistema que el usuario no pueda beneficiarse del servidor para ejecutar operaciones de seguridad para las que no tiene concedido ningún permiso de forma explícita.

Nota: El WZSSAD está activo sólo cuando el servidor está utilizando los servicios SAF autorizados para la autenticación y la autorización. Esto significa que se está ejecutando el proceso ángel y que el servidor tiene permiso para utilizar las rutinas de servicios autorizadas de SAFCRED.
Existen tres operaciones SAF protegidas por el WZSSAD:
  • Autenticación de usuarios
  • Autorización de un sujeto a un rol Java™ EE
  • Autorización de un sujeto a otros recursos SAF
De forma predeterminada, el WZSSAD no está configurado, lo que significa que el servidor no tiene permiso para autenticar ni autorizar nada. Por ejemplo, el servidor de Liberty no puede utilizar los servicios SAF autorizados para la autenticación o autorización hasta que un administrador le otorga permiso para realizar algunas o todas las operaciones.

Autenticación de usuarios

El servidor autentica a los usuarios para un dominio SAF determinado que se configura definiendo un recurso, al que se hace referencia como el APPLID de la clase APPL. Para autenticar a un usuario para el dominio, el usuario debe tener acceso de lectura al recurso APPLID de la clase APPL. Además, siempre que la clase APPL esté activa, el ID de usuario no autenticado (que es WSGUEST de forma predeterminada) también requiere acceso READ al recurso APPLID de la clase APPL.

El nombre de recurso APPLID utilizado por el servidor se especifica mediante el atributo profilePrefix en el elemento de configuración <safCredentials>. Si no especifica este elemento, se utiliza el profilePrefix predeterminado de BBGZDFLT.

En el ejemplo siguiente se muestra cómo configurar un profilePrefix de BBGZDFLT en el archivo server.xml:
<safCredentials profilePrefix="BBGZDFLT"/>
El ejemplo siguiente muestra cómo utilizar los mandatos de RACF para configurar el APPLID como BBGZDFLT:
// Definir el APPLID de BBGZDFLT en RACF.
RDEFINE APPL BBGZDFLT UACC(NONE)

// Activar la clase APPL. 
//Si no está activo, el dominio no está restringido, lo que significa que alguien puede autenticarlo.
SETROPTS CLASSACT(APPL)

//Todos los usuarios que el servidor va a autenticar deben tener acceso de lectura para el APPLID de la clase APPL:
PERMIT BBGZDFLT CLASS(APPL) ACCESS(READ) ID(UserID)

//El ID de usuario no autenticado requiere acceso READ a la APPLID en la clase APPL:
PERMIT BBGZDFLT CLASS(APPL) ACCESS(READ) ID(WSGUEST)
Además, se debe conceder permiso a WZSSAD para que realice llamadas de autenticación en el dominio APPLID dado. Esto impide que un usuario no autorizado se beneficie de los servicios SAF autorizados que utiliza el servidor para obtener información sobre qué APPLID pueden estar o no estar autenticados. Para otorgar el permiso de servidor para autenticar en un dominio APPLID determinado, el ID de tarea iniciada del servidor de Liberty debe tener otorgado acceso de lectura para el perfil BBG.SECPFX.<APPLID> en la clase SERVER:
RDEFINE SERVER BBG.SECPFX.BBGZDFLT UACC(NONE)
PERMIT BBG.SECPFX.BBGZDFLT CLASS(SERVER) ACCESS(READ) ID(serverUserId)

Autorización de un sujeto a un rol Java EE

El servidor autoriza a un sujeto con un nombre de rol de seguridad de aplicación Java EE comprobando si el sujeto está autorizado para un perfil de recurso SAF definido en la clase EJBROLE. El nombre de perfil del recurso SAF se correlaciona a partir del nombre de rol de la aplicación mediante el correlacionador de roles de SAF. El correlacionador de roles de SAF genera un nombre de perfil SAF para un nombre de rol de aplicación determinado y un nombre de recurso de aplicación. De forma predeterminada, se genera el nombre de perfil SAF utilizando el patrón {profilePrefix}.{resource}.{role}. Por ejemplo:
profilePrefix="BBGZDFLT"

Application resource name = "MYAPP"

Application role name = "ADMIN"

Mapped profile name = "BBGZDFLT.MYAPP.ADMIN"

Para obtener más información, consulte Liberty: Controlar cómo se correlacionan los roles con los perfiles SAF

WZSSAD restringe para qué perfiles SAF de la clase EJBROLE el servidor puede realizar la autorización. Esto impide que un usuario no autorizado se beneficie de los servicios SAF autorizados que utiliza el servidor para obtener información sobre qué perfiles EJBROLE pueden o no pueden estar autorizados. El servidor debe tener permiso para ejecutar las comprobaciones de autorización sobre el HLQ del nombre de perfil EJBROLE. El HLQ del nombre de perfil es el primer segmento del nombre de perfil hasta el primer '.', sin incluirlo. Por ejemplo:
EJBROLE profile name = "BBGZDFLT.ADMIN" 
HLQ = "BBGZDFLT"
Para conceder permiso al servidor para que ejecute las comprobaciones de autorización en el perfil HLQ, el usuario asociado con el proceso de servidor debe tener acceso de lectura para el perfil BBG.SECPFX.<HLQ> de la clase SERVER:
RDEFINE SERVER BBG.SECPFX.BBGZDFLT UACC(NONE)
PERMIT BBG.SECPFX.BBGZDFLT CLASS(SERVER) ACCESS(READ) ID(serverUserId)
En el ejemplo, debido a que el correlacionador de roles de SAF establece el HLQ del perfil correlacionado en profilePrefix, el mismo perfil BBG.SECPFX.BBGZDFLT rige los permiso de autenticación de APPLID y los permisos de autorización de perfil de EJBROLE.

Autorización de un sujeto a otros recursos SAF

Las aplicaciones Java EE pueden realizar comprobaciones de control de acceso con otras clases de SAF que no sean EJBROLE. WZSSAD restringe qué clases SAF externas a EJBROLE puede autorizar el servidor. Esto impide que un usuario no autorizado o una aplicación se beneficie de los servicios SAF autorizados que utiliza el servidor para obtener información acerca de los perfiles de recursos de las clases SAF que no son EJBROLE para los que está o no está autorizado el usuario o la aplicación.

Para conceder al servidor permiso para realizar las comprobaciones de autorización en las clases SAF que no son EJBROLE, el usuario asociado con el proceso de servidor debe tener acceso READ para el perfil BBG.SECCLASS.<SAF-CLASS> de la clase SERVER. Por ejemplo, para autorizar a un perfil en la clase FACILITY:
RDEFINE SERVER BBG.SECCLASS.FACILITY UACC(NONE)
PERMIT BBG.SECCLASS.FACILITY CLASS(SERVER) ACCESS(READ) ID(serverUserId)
Nota: No hay restricciones sobre los perfiles de recursos incluidos en la clase que no es EJBROLE en los que el servidor puede basar la autenticación. Si el servidor tiene permiso para realizar las comprobaciones de autorización sobre una clase que no es EJBROLE, entonces puede autorizar cualquier perfil de dicha clase.

Icono que indica el tipo de tema Tema de referencia

Nombre de archivo: rwlp_WZSSAD_zos.html