[z/OS]

Clases y perfiles de System Authorization Facility

Cuando se utiliza RACF (Resource Access Control Facility) o SAF (System Authorization Facility), considere la posibilidad de:
  1. Utilizar roles de enterprise beans y aplicaciones web, y servlets
  2. Utilizar perfiles de clase RACF
    1. Utilizar CBIND para acceder a los servidores y los objetos en los servidores
    2. Utilizar SERVER para acceder a los controladores utilizando regiones sirviente
    3. Utilizar STARTED para asociar ID de usuario y grupos con procedimientos iniciados
    4. Utilizar APPL para limitar el acceso de usuarios autenticados a las aplicaciones del servidor
    5. Utilizar FACILITY para establecer el permiso para habilitar Permiso de sincronización con la hebra de OS y permitir la correlación de identidades distribuidas con identidades SAF mediante el uso de módulos de inicio de sesión de correlación JAAS.
    6. Utilizar SURROGAT para establecer el permiso opcionalmente para habilitar Permiso de sincronización con la hebra de OS
  3. Crear varias configuraciones de seguridad en un sysplex
  4. Generar nuevos ID de usuario y perfiles para un nuevo servidor
  5. Utilizar perfiles minimalistas

Roles de Enterprise JavaBeans y aplicaciones web, y servlets

Los roles están asociados con aplicaciones Java™ Platform, Enterprise Edition (Java EE). Los módulos dentro de las aplicaciones hacen referencia a los roles utilizando la referencia de rol que apunta al rol de aplicación. El acceso a las aplicaciones web, los servlets o los métodos EJB se basa en el usuario o el llamante. Los roles se asocian con las aplicaciones web, los servlets o los enterprise beans en el momento del ensamblaje. El rol necesario para utilizar un servlet o un método EJB se denomina en los descriptores de despliegue de la aplicación.

Qué usuarios y grupos tienen determinados roles se determina utilizando perfiles RACF en la clase EJBROLE (si se selecciona la autorización SAF). Si un usuario está en la lista de acceso de un perfil EJBROLE, el usuario tiene ese rol. Si un grupo está en la lista de acceso de un perfil EJBROLE, los usuarios de ese grupo tienen ese rol. Si el perfil EJBROLE tiene ACCESS(READ), todos los usuarios tienen ese rol.

El prefijo del perfil SAF (anteriormente referido como dominio de seguridad z/OS), si se especifica, se convierte en un prefijo que utilizan WebSphere Application Server para z/OS y RACF cuando se comprueban perfiles EJBROLE. Esto proporciona granularidad de roles a nivel de prefijo del perfil SAF de WebSphere.

Por ejemplo:
Prueba
La célula tiene el dominio de seguridad=TEST
La célula de producción tiene el dominio de seguridad=PROD

Por ejemplo, una aplicación que utiliza el rol Clerk se despliega en ambas células. En la célula de prueba, los usuarios necesitan acceso READ al perfil EJBROLE TEST.Clerk. En la célula de producción, los usuarios necesitan acceso READ al perfil EJBROLE PROD.Clerk.

Los perfiles siguientes se definen en la clase EFBROLE de RACF para la autorización administrativa: administrador, configurador, supervisor, operador, desplegador, gestor de seguridad administrativa (adminsecuritymanager) y auditor.

Consulte System Authorization Facility para autorización basada en roles para obtener más información sobre cómo se puede utilizar SAF para la autenticación de roles basada en Java EE.

Utilización de los perfiles RACF

Es importante entender los mecanismos de seguridad que se utilizan para proteger los recursos de servidor que utilizan las clases CBIND, SERVER y STARTED en RACF (o el producto de seguridad equivalente de que se trate). También debe conocer las técnicas para gestionar el entorno de seguridad.

Los perfiles RACF que protegen los recursos de WebSphere Application Server para z/OS utilizan las siguientes clases:
  1. CBIND: utilice esta clase para acceder a los servidores y acceder a los objetos en los servidores
  2. SERVER: utilice esta clase para acceder a los controladores por regiones de servant
  3. STARTED: utilice esta clase para asociar ID de usuario y grupos con procedimientos iniciados
  4. APPL: utilice esta clase para limitar el acceso de usuarios autenticados a las aplicaciones que se ejecutan en el servidor
  5. FACILITY: utilice esta clase para:
    • asociar los ID de usuario y los grupos con la opción Permiso de sincronización con la hebra de OS
    • Controlar qué configuraciones de seguridad están autorizados a correlacionar identidades distribuidas con identidades SAF mediante los módulos de inicio de sesión de correlación JAAS
  6. SURROGAT: utilice esta clase opcional para asociar ID de usuario y grupos a la opción Permiso de sincronización con la hebra de OS
Consulte Consideraciones de SAF (System Authorization Facility) para los niveles de sistema operativo y aplicación para obtener más información.

Puede encontrar información básica sobre los perfiles RACF utilizados por WebSphere Application Server para z/OS en la Autorización basada en SAF. Esta sección añade algunos detalles adicionales acerca de los perfiles de clase CBIND, SERVER, FACILITY, SURROGAT y STARTED.

ID de usuario e ID de grupo

Al crear un perfil para un servidor de aplicaciones, el trabajo BBOCBRAK genera los mandatos RACF. Al crear un perfil para un célula, el gestor de despliegue, el gestor de trabajos o el agente administrativo, el nombre del trabajo será BBODBRAJ. Al crear un perfil para un nodo personalizado, el nombre del trabajo será BBOMBRAJ. Entre la siguiente información:
CR = Controller Region SR = Servant
Región CFG = Servidor de configuración (grupo) = clúster de nombre abreviado de servidor = genérico
nombre abreviado de servidor (también llamado nombre de transición del clúster) 
Seis usuarios y seis grupos, definidos como se indica a continuación, se muestran simbólicamente para ilustrar cómo se utilizan posteriormente en los distintos permisos:
<CR_userid> <CR_groupid>, <CFG_groupid> <SR_userid> <SR_groupid>, <CFG_groupid> <demn_userid> <demn_groupid>, 
<CFG_groupid> <admin_userid> <CFG_groupid> <client_userid> <client_groupid> <ctracewtr_userid> <ctracewtr_groupid> 

A continuación, se muestran los distintos perfiles utilizados para proteger los recursos de WebSphere Application Server for z/OS, junto con los permisos y los niveles de acceso.

Utilización de perfiles de clases CBIND

Hay dos formatos y niveles de los perfiles de la clase CBIND para proteger el acceso a los servidores de aplicaciones y a los objetos en dichos servidores:
CBIND Perfiles de clase - acceso a servidores genéricos CB.BIND.<cluster> UACC(READ); PERMIT <CR_group> ACC(CONTROL)
Perfiles de la clase CBIND - acceso a objetos en servidores
CB.<cluster> UACC(READ) PERMIT <CR_group> ACC(CONTROL)
Si utiliza el “Prefijo de perfil SAF”, los perfiles CBIND se cualifican mediante el “profilePrefix” del modo siguiente:
Perfiles de la clase CBIND - acceso a servidores genéricos CB.BIND.<profilePrefix>.<cluster> UACC(READ)
Perfiles de la clase CBIND - acceso a objetos en servidores
CB.<profilePrefix>.<cluster> 	UACC(READ) 
Los perfiles CBIND controlan el acceso a los servidores de WebSphere Application Server para z/OS, incluidos los servidores web que ejecutan el plug-in de WebSphere Application Server, y a los objetos en los servidores, desde los clientes de aplicaciones Java a otros servidores WebSphere Application Server. Para acceder a los servidores, entre:
CB.CBIND.<cluster>
CB.CBIND.<SAF profile prefix>.<cluster> 
Para acceder a los objetos en los servidores, entre:
CB.<cluster> CB.<SAF profile prefix>.<cluster> 

Utilización de perfiles de clases SERVER

Actualmente hay dos formatos de los perfiles de la clase SERVER para proteger el acceso a los controladores de servidor.
SERVER
perfiles de clase: acceso a controladores utilizando los entornos de aplicaciones estáticas
 CB.<server>.<cluster>   	UACC(NONE) PERMIT <SR_userid> ACC(READ)
             Perfiles de la clase SERVER: acceso a controladores utilizando entornos de aplicación dinámicos
Environments  CB.<server>.<cluster>.<cell> 	UACC(NONE) PERMIT <SR_userid>
ACC(READ) 
Al utilizar la herramienta de gestión de perfiles WebSphere z/OS o el mandato zpmt, ambos formatos están predefinidos, y uno de ellos es necesario en el tiempo de ejecución. El tiempo de ejecución de WebSphere Application Server para z/OS determina dinámicamente el formato necesario según la disponibilidad del soporte DAE (Dynamic Application Environment). El siguiente mandato proporciona acceso a los controladores utilizando Entornos de aplicación estáticos:
RDEFINE
CB.&<server<cluster> UACC(NONE); PERMIT &<SR_userid> ACCESS(READ) 
Para este ejemplo, server = nombre del servidor, cluster = nombre del clúster o nombre de transición del clúster si todavía no se ha creado un clúster, y SR es el ID de usuario de MVS de la región de servidor.
El siguiente mandato proporciona acceso a los controladores utilizando Entornos de aplicación dinámicos:
CB.& <server>.&<cluster>.<cell>
UACC(NONE); PERMIT &<SR_userid> ACC(READ) 
Para este ejemplo, servidor = nombre del servidor, clúster = nombre del clúster o nombre de transición del clúster si todavía no se ha creado un clúster, célula = nombre abreviado de la célula, y SR es el ID de usuario de MVS de la región de servidor.

Los perfiles de clase SERVER controlan si un servant puede llamar a rutinas autorizadas en el controlador asociado.

Para acceder al controlador utilizando el Entorno de aplicación estático, entre:
CB.<server>.<cluster>
CB.<SAF profile prefix>.<server>.<cluster> 
Para acceder al controlador utilizando el Entorno de aplicación dinámico, entre:
CB.<server>.<cluster>.<cell>
22 

Utilización de perfiles de clases STARTED

Existen tres formatos de perfiles de la clase STARTED que se utilizan para asignar ID de usuario e ID de grupo a los controladores:
Perfiles de la clase STARTED - (MGCRE) - para regiones de control, daemons y agentes de nodo
<<CR_proc>.<CR_jobname> STDATA(USER(CR_userid) GROUP(CFG_groupid))
<demn_proc>.* STDATA(USER(demn_userid) GROUP(CFG_groupid))

Perfiles de la clase STARTED - (ASCRE) - para regiones sirviente y adjuntos
<SR_jobname>.<SR_jobname> STDATA(USER(SR_userid) GROUP(CFG_groupid))

Perfiles de la clase STARTED para IJP - (MGCRE)
<MQ_ssname>.* STDATA(USER(IJP_userid) GROUP(CFG_groupid)) - Estos IJP no existen en WAS 6.1
 
Los perfiles de la clase STARTED se generan para asignar ID de usuario a las distintas regiones de WebSphere Application Server para z/OS. Estas regiones son:
  • Daemon
  • Gestor de despliegue (controlador y servant)
  • Agente de nodo
  • Servidores de aplicaciones (controlador, servant y adjunto)
  • Agentes administrativos (controlador y servant)
  • Gestores de trabajos (controlador y servant)

Utilización de perfiles de clases APPL

Un perfil de la clase APPL controla si un usuario autenticado puede utilizar cualquier aplicación de la célula. Si se especifica un prefijo de perfil SAP, el nombre del perfil de la clase APPL será el nombre del dominio de seguridad. Si no se especifica un prefijo de perfil SAF, el nombre del perfil de la clase APPL será CBS390. Consulte el apartado Consideraciones de SAF (System Authorization Facility) para los niveles de sistema operativo y aplicación.

El perfil de la clase APPL sólo entre en vigor cuando la clase APPL está activa en RACF y cuando la opción de utilizar el perfil APPL está habilitada en WebSphere. La opción WebSphere se puede habilitar o inhabilitar desde la consola administrativa, yendo al panel de opciones de la autorización SAF y estableciendo el recuadro de selección Utilizar el perfil APPL para limitar el acceso al servidor. Para obtener más información sobre este valor, consulte el apartado Autorización SAF (System Authorization Facility) de z/OS.

Crear varias configuraciones de seguridad en una célula

Puede necesitar distintos conjuntos de perfiles dentro de una determinada célula para separar dominios de seguridad de WebSphere lógicos en la empresa, (por ejemplo, los usuarios de prueba y los de producción).

Puede definir un prefijo de perfil SAF durante la personalización mediante la herramienta de gestión de perfiles z/OS, el mandato zpmt o desde el panel de opciones de autorización de SAF de la consola administrativa.

Utilice la consola administrativa de WebSphere Application Server for z/OS para establecer un prefijo de perfil de SAF en Seguridad > Seguridad global > Proveedor de autorización externo > Autorización SAF (System Authorization Facility) > Configurar > Prefijo de perfil SAF, que crea la siguiente propiedad en el archivo security.xml.

xmi:id="Property_47" name="com.ibm.security.SAF.profilePrefix"
value="<profile_prefix>"  required="false"/> 
Cuando se establece un identificador de prefijo de perfil SAF, se ven afectadas las siguientes definiciones de perfil y comprobaciones:
Tabla 1. Definiciones y comprobaciones de perfil afectadas cuando se establece el identificador de prefijo SAF..

Esta tabla muestra las definiciones y comprobaciones de perfil afectadas cuando el identificador de prefijo de perfil SAF está establecido.

Clase Sin prefijo de perfil SAF Con un prefijo de perfil SAF
CBIND
  • CB.nombreclúster
  • CB.BIND.nombreclúster
  • CB.<profilePrefix>.clustername
  • CB.BIND.<profilePrefix>.clustername
EJBROLE ApplicationRoleName <profilePrefix>.ApplicationRoleName
APPL CBS390 <profilePrefix>

Generar nuevos ID de usuario y perfiles para un nuevo servidor

Si desea utilizar ID de usuario únicos para cada nuevo servidor de aplicaciones, debe definir esos usuarios, grupos y perfiles en la base de datos RACF.

Mediante la herramienta de gestión de perfiles WebSphere z/OS o el mandato zpmt, deberá editar una copia del conjunto de datos particionados .DATA del destino del trabajo del miembro BBOWBRAK (o BBODBRAK en función del tipo de perfil) y cambiar las entradas siguientes con los valores de los nuevos usuarios, grupos y perfiles de nombre New_server y New_cluster exclusivos:
  • Si desea unos ID de usuario exclusivos para los nuevos servidores, defina tres nuevos usuarios y conéctelos a los siguientes grupos:
    • <New_CR_userid> <CR_groupid>, <CFG_groupid>
    • <New_SR_userid> <<SR_groupid>, <CFG_groupid>
    • <New_ADJUNCT_userid> <<ADJUNCT_groupid>, <CFG_groupid>
    • <New_client_userid> <client_groupid>
  • Perfiles de la clase CBIND para el nuevo clúster (nombre abreviado del servidor genérico):
    • CB.BIND.<New_cluster>
    • CB.<New_cluster>
  • Perfiles de la clase SERVER para el nuevo servidor y clúster:
    • CB.<New_server>.<New_cluster>
    • CB.<New_server>.<New_cluster>.<cell>
  • Perfiles de la clase STARTED para las nuevas regiones de servant y controlador del servidor:
    • <CR_proc>.<New_CR_jobname> STDATA(USER(New_CR_userid) GROUP(CFG_groupid))
    • <New_SR_jobname>.* STDATA(USER(New_SR_userid) GROUP(CFG_groupid))
    • <New_ADJUNCT_jobname>.* STDATA(USER(New_ADJUNCT_userid) GROUP(CFG_groupid))

Utilizar los perfiles de clase FACILITY y SURROGAT (opción Permiso de sincronización con la hebra de OS y la opción de identidad de hebra RunAs del gestor de conexiones)

Los perfiles de clase FACILITY y SURROGAT proporcionan al administrador RACF el control sobre el uso de Permiso de sincronización con la hebra de OS y la opción de identidad de hebra Run-As del gestor de conexiones.
Atención: Si estos perfiles no están definidos en RACF, no existirá el permiso de sincronización con la hebra y el administrador RACF utilizará el ID de servidor.
  • Perfil de la clase FACILTY BBO.SYNC.<nombre_abreviado_célula>.<nombre_abreviado_clúster>
    • Si el controlador de WebSphere no tiene acceso al perfil, se inhabilitará Permiso de sincronización con la hebra de OS.
    • Si el controlador de WebSphere tiene acceso READ al perfil. Se puede utilizar Permiso de sincronización con la hebra de OS, pero se limita a los entornos de seguridad que representan a ciertos usuarios. El perfil de clase SURROGATE debe definirse.
    • El controlador de WebSphere tiene acceso CONTROL al perfil. Se puede utilizar Permiso de sincronización con la hebra de OS para crear entornos de seguridad para representar a cualquier usuario. No se comprobará el perfil de clase SURROGATE.
  • Perfil de la clase SURROGAT BBO.SYNC.<ID_usuario>
    • Si el controlador de WebSphere solo tiene acceso READ al perfil de clase FACILITY de BBO.SYNC.<nombre_abreviado_célula>.<nombre_abreviado_clúster> que habilita Permiso de sincronización con la hebra de OS, se utiliza la comprobación del perfil de clase SURROGAT para verificar que el servant de WebSphere esté autorizado para establecer un entorno de seguridad para el usuario de destino.
    • Las comprobaciones de perfil de clase son coherentes con otros productos que realizan funciones similares.
Los formatos y usos de los perfiles de clase FACILITY y SURROGAT son los siguientes:
RDEF FACILITY BBO.SYNC.<cell short name>.<cluster short name> UACC(NONE) 
PE BBO.SYNC.<nombre abreviado célula>.<nombre abreviado clúster> CLASS(FACILITY)ID(<ID de usuario CR >) ACC(READ o CONTROL)
RDEF SURROGAT BBO.SYNC.<ID de usuario Run-As> UACC(NONE)
PE BBO.SYNC.<Run-As user ID> CLASS(SURROGAT) ID(<SR user ID>) ACC(READ)
Nota: El nombre breve de clúster es el nombre breve genérico de servidor si no se define ningún clúster. Asimismo, el perfil de clase SURROGAT debe colocarse en un tabla de memoria (RACLISTed) para mejorar el rendimiento de las comprobaciones de acceso.
Si se otorga <ID de usuario CR> a CONTROL, cualquier ID de usuario individual que solicite Permiso de sincronización con la hebra de OS podrá sincronizarse. Si se otorga acceso READ al <CR user ID>, cualquier ID de usuario individual que solicita Permiso de sincronización con la hebra de OS debe tener definido un perfil de clase SURROGAT y la región de servicio (SR) debe tener también acceso READ. Por ejemplo, supongamos un sistema con el nombre abreviado de célula de SY1, un nombre abreviado de clúster (el nombre abreviado genérico de servidor) de BBOC001, CR user ID de CBSYMCR, SR user ID de CBSYMSR y una aplicación que se ejecute bajo el Run-As user ID de JavaEEID. Los siguientes mandatos se utilizarían para establecer el control Permiso de sincronización con la hebra de OS.
RDEF FACILITY BBO.SYNC.SY1.BBOC001 UACC(NONE) 
PE BBO.SYNC.SY1.BBOC001 CLASS(FACILITY) ID(CBSYMCR) ACC(READ) 
RDEF SURROGAT BBO.SYNC.J2EEID UACC(NONE) 
PE BBO.SYNC.J2EEID CLASS(SURROGAT) ID(CBSYMSR) ACC(READ)

Utilizar perfiles de clase FACILITY (Habilitación de aplicaciones de confianza)

El perfil de clase FACILITY proporciona al administrador RACF el control para habilitar las aplicaciones de confianza. Para habilitar las aplicaciones de confianza, debe definir el siguiente perfil de clase FACILITY y proporcionar acceso de READ a dicho perfil al ID de usuario de región de controlador.
RDEF FACILITY BBO.TRUSTEDAPPS.<nombre abreviado célula
nombre abreviado>.<nombre abreviado de clúster> UACC NONE PE
BBO.TRUSTEDAPPS.<nombre abreviado de célula>.<cluster
nombre abreviado> CLASS(FACILITY) ID(ID de usuario CR) ACC(READ)
El ejemplo genérico siguiente se puede utilizar para todos los servidores:
RDEFINE FACILITY BBO.TRUSTEDAPPS.mycell01.**UACC(NONE)
PERMIT BBO.TRUSTEDAPPS.mycell01.**  CLASS(FACILITY) ID(MYCBGROUP) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
El ejemplo siguiente es para un servidor específico, esto es, un sistema con un nombre abreviado de célula de SY1, un nombre abreviado de clúster (el nombre abreviado genérico del servidor) de BBOC001 y un ID de usuario de regiones de controlador de CBSYMCR:
RDEF FACILITY BBO.TRUSTEDAPPS.SY1.BBOC001 UACC
NONE PE BBO.TRUSTEDAPPS.SY1.BBOC001 CLASS(FACILITY) ID(CBSYMCR) ACC(READ)

Utilizar perfiles minimalistas

Para minimizar el número de usuarios, grupos y perfiles en el conjunto de datos RACF, puede utilizar un ID de usuario, un ID de grupo y muchos perfiles genéricos que conviertan múltiples servidores en la misma célula. Esta técnica también puede utilizarse con configuraciones IJP (Integral Java Message Service Provider) y WebSphere Application Server, Network Deployment.

Las ventajas de utilizar perfiles minimalistas incluyen tener menos:
  • Definiciones de perfiles que definir
  • Certificados digitales que considerar para la comunicación SSL (Secure Sockets Layer) entre procesos
Una desventaja es que debe supervisar más atentamente las aplicaciones, ya que si se ejecutan varios servidores con los mismos ID de usuario o grupos, una aplicación puede dar problemas en un servidor y llegar a dañar la configuración de su propio servidor (por ejemplo, desactivando la seguridad) así como la de otros servidores.

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_safclasses
File name: csec_safclasses.html