Configuración de la autorización para aplicaciones en Liberty

La configuración de la autorización para su aplicación es verificar si un usuario o grupo pertenece a un rol especificado y si este rol tiene el privilegio para acceder a un recurso.

Acerca de esta tarea

El servidor Liberty extrae información de correlación de usuarios y grupos de un registro de usuarios y, después, consulte la configuración de autorización para la aplicación para determinar si un usuario o un grupo está asignado a uno de los roles necesarios. A continuación, el servidor lee el descriptor de despliegue de la aplicación para determinar si el usuario o grupo tiene el privilegio para acceder al recurso.

Cuando se utiliza la autorización SAF (System Authorization Facility), los roles se correlacionan con perfiles de recursos EJBROLE utilizando el correlacionador de roles SAF. El servidor de consultas SAF para determinar si el usuario tiene el acceso READ necesario para el perfil de recursos EJBROLE.

Procedimiento

  1. Habilite la característica appSecurity-2.0 Liberty en el archivo server.xml.
    Por ejemplo:
        <featureManager>
            <feature>appSecurity-2.0</feature>
        </featureManager>
    Nota:
    • Si está utilizando el proveedor de autorización SAF, incluya la característica zosSecurity-1.0 y defina un elemento de configuración safAuthorization en el archivo server.xml. Por ejemplo:
       <featureManager>
           <feature>appSecurity-2.0</feature>
           <feature>zosSecurity-1.0</feature>
       </featureManager> 
      
       <safAuthorization id="saf" />
  2. Configure un registro de usuarios para la autenticación en el servidor Liberty.

    Consulte Autenticación de usuarios en Liberty.

    Si está utilizando el proveedor de autorización SAF, debe utilizar el registro SAF y el servidor debe tener autorización para utilizar los servicios de autorización SAF. Consulte Activación y configuración del registro SAF en z/OS.

  3. Asegúrese de que el descriptor de despliegue de la aplicación incluye restricciones de seguridad y demás información relacionada con la seguridad.
    Nota: También puede utilizar una herramienta como Rational Application Developer para crear el descriptor de despliegue.
  4. Configure la información de autorización como, por ejemplo, la correlación de usuarios y grupos con roles.
    Puede configurar la tabla de autorizaciones de las siguientes maneras:
    • Si tiene un archivo EAR, puede añadir la definición de configuración de autorización al archivo ibm-application-bnd.xml o ibm-application-bnd.xmi.
    • Si tiene archivos WAR autónomos, puede añadir las definiciones de tabla de autorizaciones al archivo server.xml debajo del elemento de aplicación correspondiente. Para ello, puede utilizar WebSphere Application Server Developer Tools for Eclipse.
    Notas:
    • Si tiene un archivo EAR, es posible que ya exista la configuración de autorización. En los archivos EAR que están escritos según la especificación actual, esta información se almacena en un archivo ibm-application-bnd.xml; en archivos EAR antiguos, esta información se almacena en un archivo ibm-application-bnd.xmi.
    • Si el archivo EAR no contiene ya un archivo ibm-application-bnd.xm*, crear uno no es una tarea sencilla, por lo que es posible que prefiera añadir la configuración de autorización al archivo server.xml.
    • Si la configuración de autorización para el archivo EAR se define en un archivo ibm-application-bnd.xm* y también en el archivo server.xml, las dos tablas se fusionan. Si hay algún conflicto, se utiliza la información del archivo server.xml.
    • Si modifica el registro de usuarios, asegúrese de revisar en la tabla de autorizaciones los cambios necesarios. Por ejemplo, si está especificando un elemento access-id y cambia el nombre de reino del registro, también deberá cambiar el nombre de reino en el elemento access-id.
    • Si especifica el elemento application-bnd en el archivo server.xml, la aplicación no puede estar en la carpeta dropins. Si la deja en la carpeta dropins, debe inhabilitar la supervisión de aplicaciones estableciendo lo siguiente en el archivo server.xml:
      <applicationMonitor dropinsEnabled="false" />

    Un rol se puede correlacionar con un usuario, un grupo o un sujeto especial. Los dos tipos de sujetos especiales son EVERYONE y ALL_AUTHENTICATED_USERS. Cuando un rol está correlacionado con el sujeto especial EVERYONE, no hay seguridad porque se permite el acceso a todo el mundo y no se solicita que se especifiquen las credenciales. Cuando un rol está correlacionado con el sujeto especial ALL_AUTHENTICATED_USERS, cualquier usuario autenticado por el servidor de aplicaciones puede acceder al recurso protegido.

    A continuación se muestra un ejemplo de código para configurar la correlación de usuarios y grupos con roles en el archivo server.xml:
    <application type="war" id="myapp" name="myapp" location="${server.config.dir}/apps/myapp.war">
    	<application-bnd>
    		<security-role name="user">
    			<group name="students" />
    		</security-role>
    		<security-role name="admin">
    			<user name="gjones" />
                <group name="administrators" />
    		</security-role>
    		<security-role name="AllAuthenticated">
    			<special-subject type="ALL_AUTHENTICATED_USERS" />
    		</security-role>
    	</application-bnd>
    </application>

    En este ejemplo, el rol de admin se correlaciona con el ID de usuario gjones y con todos los usuarios del grupo administrators. AllAuthenticatedRole está correlacionado con el sujeto especial ALL_AUTHENTICATED_USERS, lo que significa que cualquier usuario tiene acceso siempre y cuando proporcionen credenciales válidas para la autenticación.

    Nota: Cuando se habilita la autorización SAF, no puede utilizar los sujetos especiales ALL_AUTHENTICATED_USERS y EVERYONE sujetos especiales.
    Si utiliza la autorización SAF, los roles se correlacionan con perfiles de recursos EJBROLE utilizando el correlacionador de roles SAF. El patrón del correlacionador de roles SAF se puede configurar utilizando el elemento safRoleMapper en el archivo server.xml. Consulte Liberty: Controlar cómo se correlacionan los roles con los perfiles SAF. De forma predeterminada, el rol se correlaciona con un perfil de recurso utilizando el patrón prefijo_perfil.recurso.rol, donde
    • prefijo_perfil se define mediante el atributo profilePrefix del elemento de configuración safCredentials. De forma predeterminada, el valor de profilePrefix es BBGZDFLT.
    • recurso es el nombre de recurso, por ejemplo, el nombre de aplicación.
    • rol es el nombre de rol.
    Para acceder al recurso protegido, el usuario debe tener acceso READ al perfil de recursos EJBROLE. Por ejemplo, para que el ID de usuario gjones pueda acceder a un recurso protegido bajo el rol admin para la aplicación myapp, el usuario gjones debe tener acceso READ al perfil de recurso BBGZDFLT.myapp.admin en la clase EJBROLE del producto SAF.
    Nota: Los perfiles de recursos EJBROLE distinguen entre mayúsculas y minúsculas.
    El siguiente ejemplo de código muestra un ejemplo de mandatos RACF para autorizar un usuario:
    rdef EJBROLE BBGZDFLT.myapp.admin uacc(none)
    permit BBGZDFLT.myapp.admin class(EJBROLE) access(read) id(gjones)
  5. Opcional: Configure una decisión de autorización cuando no existe información de enlace de la aplicación.
    Cuando no se proporciona la información de enlace de correlación de roles para una aplicación protegida, el motor de autorización predeterminado toma el nombre del rol que está protegiendo el recurso como el nombre de grupo asociado a dicho rol. Así, por ejemplo, si el nombre del rol es manager, un usuario que pertenece a un grupo de manager tiene acceso a dicho recurso. Esto sólo se aplica cuando no se especifica ninguna información de enlace de aplicación, en server.xml o el archivo de enlace de aplicación, para la aplicación: por ejemplo, al añadir este enlace se inhabilita el rol de seguridad para el enlace de grupo:
    <application type="war" id="myapp" name="myapp"
    location="${server.config.dir}/apps/myapp.war">
          <application-bnd>
    	     <security-role name="anyAppRoleName"/>
          </application-bnd>
    </application>
    Nota: Para que una autorización sea satisfactoria con un nombre de grupo en el registro de usuarios, el nombre de rol debe coincidir con el nombre completo o exclusivo del grupo en el registro que se ha configurado y no con el nombre abreviado. Por ejemplo, si el nombre abreviado del grupo es swGroup, pero el nombre completo o exclusivo en el registro de usuarios es CN=swGroup,o=company,c=us, debe especificar CN=swGroup,o=company,c=us como nombre de rol para que la autorización sea satisfactoria.

Icono que indica el tipo de tema Tema de tarea

Nombre de archivo: twlp_sec_rolebased.html