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 de Liberty extrae la información de correlación de usuarios y grupos de un registro de usuarios y luego consulta la configuración de autorización de la aplicación para determinar si a un usuario o grupo tiene asignado 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.

Procedimiento

  1. Habilite la característica de Liberty de appSecurity-2.0 en el archivo server.xml.
    Por ejemplo:
        <featureManager>
            <feature>appSecurity-2.0</feature>
        </featureManager>
  2. Configure un registro de usuarios para la autenticación en el servidor de Liberty.

    Consulte Autenticación de usuarios en Liberty.

  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.

  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 gestor, un usuario que pertenece a un grupo de gestores 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



Icono de indicación de fecha y hora Última actualización: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_sec_rolebased
Nombre de archivo:twlp_sec_rolebased.html